Re: [Passwordsafe-devel] Enhancement Topics (Format and Usage Bugs)

[dk <dk...@gm...>]

>From the code, the current implementation for the user field 0x05 is a text
string that identifies the user who made the last save and the host the user
was logged on to at the time.
 
The exact format is:
 
User field length:    4 bytes (hexadecimal representation of the length of
the username) - used to determine the start of the host name text field.
User name:           text
Host name:           text
 
Total length of this field is: 4 + length of username + length of host name
 
David

  _____  

From: pas...@li...
[mailto:pas...@li...] On Behalf Of
Wolfgang Keller
Sent: 10 May 2007 07:50
To: pas...@li...
Subject: Re: [Passwordsafe-devel] Enhancement Topics (Format and Usage Bugs)




A. Wolfgang's *New Header Data Fields* 

Field 07: (type "Text" maximum length 128) Database name. A logical name for
a database which can be used by applications in place of the possibly
lengthy filepath notion.

Field 08: (type "Text" maximum length 256) Database Description. A purely
informative description concerning the purpose or other practical use of the
database.

I don't mind but why the length limitation?  What would we do with them?
How would they be entered and where would they be displayed (apart from in
the Database Property dialog "File Menu->Properties")?

B. Wolfgang's *Tolerating Unknown Fields* 

I was going to agree that we should copy "unknown" header fields found in
the header on opening a database back into the header when saving it rather
than just ignoring them.  I was not so sure that we should do this for
unknown record fields.

The problem is how/where to save them between reading them in and writing
them out!  As we do not know their structure, they may have a dependence on
other fields that we do not know.  Changing "our" PWS fields may cause the
other application to fail or corrupt data.  What about overlaps (someone
somewhere unknown to PWS developers using field X currently not used by PWS)
but then PWS starts to use it?

So I changed my mind - best to ignore unknown fields.  If they are there,
the user should open the database in read-only mode to protect them.  In
fact, maybe PWS should insist a database is read-only if it detects unknown
fields?

C. Wolfgang's *Format Bugs and Shortcomings* 

I agree that header field 02, the file-UUID, should not be recreated with
every save operation of PWS and I will try to get this in V3.08.

I agree that the value of ITER should be at least 2048 but if an existing
database uses a greater value, then it should be retained.  Again, I will
try to get this in V3.08.

I agree that header field 04 is 'falsely programmed'. It is 8 hexadecimal
characters long (format %08x) representation of a time_t 32-bit long integer
rather than the raw "time_t" value.  Two possible solutions: a) change the
file "formatV3.txt" to say its current format b) change to write it out in
raw 'time_t' format and program around the data being in one or other form
(I suppose based on the field length of 4 or 8).

Regards, 

David 

* Fields 07 and 08:

The length limitation is to prevent abuse and to give a reasonable frame for
usage. The name clearly needs a limitation. The description might be argued
to be longer but I prefer it 256 max. (Compare it with project descriptions
in SF.) This way the user is forced to stay with the essential, which is its
genuine purpose, second you can display it as a label without cutting
considerations. - If and how you use these fields is up to you.

* Format Bugs *

Please remember that point B.b) with header field 05 (user) is still open to
clearify.

- Wolfgang