Re: [Passwordsafe-devel] Format Tests
Popular easy-to-use and secure password manager
Brought to you by:
ronys
From: Wolfgang K. <91...@gm...> - 2007-05-21 19:23:49
|
David, from some of your recent posts I have been wondering whether you are causing unnecessary obstacles, but then again I'm not sure. Let me say that if you don't like the idea of cooperation, just say a word and I'm backing off. - I regard my contributions here as offers to the benefit of the PWS file format. I'm not doing this to please the PWS project or its people but for the sake of a community, whether big or small, who might be using this file format under various applications and possibly various purposes. - It is my believe that all users and all PWS applications will benefit from an open and effective file format regulation, providing the means for as little loss/friction as possible when files are cross-used among several PWS applications or various historical software versions. It is my believe, hence, that the format definition should be a) as simple as possible, b) as tolerant as possible. In this light I'ld comment on some of your recent points: i) (Simplicity I) no sequence prescriptions in any field arrays! The format definition should make it explicit that both header field list and record field list must be fully apprehended in random type sequence of its fields. Any ordering prescriptions might cause problems in applications and is a superfluous source of errors. There is no algorithmic necessity for any ordering (with the exception of the list terminating field 0xff). ii) (Simplicity II) no complex field structures where possible; so I support suggestion to create 2 fields for "Last operator" and "Last host (computer)" iii) (Tolerance I) the most simple and effective rule here is that a PWS application should preserve unknown fields when saving a file, regardless of their place and value, i.e. no two-class support depending on type ranges or the record/header distiction. Anything else I regard as over-protective (protect what exactly?) and again forseeably - but hopefully not deliberately - causing problems. iv) (Tolerance II) as a compensation for openness there must exist a regulation to devide usage of field types. The simple 0x7f boundary does the job as already described and secures a wide range of fields for the world of PWS only. I personally have seen a second boundary at 0x3f; above it and below 0x7f could be a range for "approved PWS applications" (well, I don't like the word "clones" any more because mutual feature copy is already in full swing). Specific type values would be given out to these application once they need them. This has the advantage that these approved applications share a protected zone and could refer to the "rest of the world" as "using above 0x7f types". I walk from the assumption here that 64 field types will provide for many more decades of development of the (native) PWS program. - (The second boundary is an add-on and the system also works without it.) That's how I've seen it, - Wolfgang dk wrote: > Wolfgang, > > I have replied to your Support Request as I had some difficulties with the > time fields in the records and header. > > However, on further tracing, I see that the order in which you write the > header records seems to be in the inverse of their type value. There is > nothing in the "FormatVn.txt" file to say this is wrong. However, I would > like the format changed to mandate that the version number (record type > 0x00) is *always* the first field in the header. > > Regards, > > David > > > > |