Re: [Passwordsafe-devel] Updates

[Frank P. <fp...@fp...>]

On Wed, 09 May 2007 18:52:32 -0400, dk <dk...@gm...> wrote:
>
> A. Wolfgang's *New Header Data Fields*
>
> I don't mind but why the length limitation?  What would we do with them?
>

Hi,

I agree; there is no need to limit a field's length.  Typical C  
programmer's
disease.  Implementations are free to truncate any field for display.

In my implementation, if any field length is larger than 65536, I print a
warning that the database may be corrupted, assuming that no valid field
will exceed that length.  You can argue that this is just another variant
of C programmer's disease, but here it's an implementation detail.  It has
no place in the format document.

>
> 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.
>

It is prudent to tolerate both unknown header and unknown record fields.
For example, it is necessary for forward compatibility, when a database is
opened with an older version of Password Safe that did not know about the
fields that were introduced later.

>
> The problem is how/where to save them between reading them in and writing
> them out!
>

I just keep unknown records as a "blob", storing the decrypted but  
otherwise
uninterpreted octet sequence.  When writing the file, I can easily  
re-encrypt
the blob and write it back into the file.

>
>            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?
>

Like I said in my other mail, applications shall not invent new header or
record fields without publishing them in the "standard" formatV3 document.
That leads to incompatibilities.  But if this approach is followed, the
scenario you describe can be avoided.

>
> 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).
>

Password Gorilla does not support this header file yet, so I wouldn't  
object
to changing the format to match the implementation.  However, that should  
be
the rare exception than the rule.  Are there any other implementations out
there that might have implemented this field already?

On the related topic, defining time_t to be optionally 4 or 8 bytes long  
works
for me.  Personally, I don't see the urgency.  We still have plenty of time
until 2106.

Frank

-- 
Frank Pilhofer, fp...@fp...