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

[Wolfgang K. <91...@gm...>]

Hello

Early this year I released JPasswords 0.4.0 
(http://sourceforge.net/projects/jpws) which kept track of the newer 
development of PWS file format. I am now working on the next release and 
would like to carry some of my observations and ideas to here in order 
to enhance fitness of the V3 file format for multi-application usage. It 
looks like I have 4 major topics which I will bring in as separate post 
for discussion.

*** *Format Bugs and Shortcomings* ***

I'll start with this one. The points here all concern the file header 
data including the header fields (referring to PWS 3.07).

A. Unfortunate usage

a) Field 02, the file-UUID, is recreated with every save operation of 
PWS. This in my view is against the genuine idea and purpose of an UUID, 
namely to identify a file over space and time. Looks like a bug to me 
and would be glad to see it improved. (The policy I have adopted in JPWS 
is that the original file and all of its backups keep the identical UUID 
value, while explicit copies (e.g. "save as") performed throught the 
program carry a new UUID.)

b) The setting of security loops ("ITER" in format description) is 
likewise replaced by the PWS standard value of 2048 with every save. 
This also looks unfortunate to me as other applications might choose to 
set up a special value which then is lost.

So my recommendation for these points is that the save process should 
impose new/standard values only if it doesn't find meaningful values 
already existing.

B. Errors

a) Header field 04 is obviousely falsely programmed. PWS generated a 
content value which is 9 bytes long, which is already non-conforming the 
format definition. According to definition this should be a 
bit-formatted integer value (of 4 or 8 bytes length). The factual value 
looks like a null-terminated string to me. So this should be corrected.

b) With the definition of header field 05 (user) it looks to me that 
once again the "naturalistic fallacy" of seeing text strings as 1-to-1 
symbol and encoding length might have struck. No encoding rule is 
provided (ASCII encoding seems too weak for international use!) and the 
length information has an unclear target (concerning encoded length or 
text length?). My suggestion is to replace the entire definition with 
just a normal text string; I don't see any urgent need for splitting it up.

c)  Interesting enough, a definition of the "Text" data type in 
FormatV3.txt has either never existed or disappeared (file revision 1216 
/ 17.01.2007). Can we fix it into something reliable like UTF-8 plain, 
without leading or trailing string or format or length tokens?

Until points are clearified I will stay with format V3.00 with JPWS.

Cheers!
- Wolfgang Keller