this first draft seems fairly complete, though i do have some questions and
points to make.
1. magic number. should we extend this to the file encryption functionality
besides just the password DB?
2. the way i understand it, this will turn everyone's pass word/phrase into
a 20 byte hash. does this reduce your security if your pass phrase is
longer than 20 characters? as an alternative, can we use the pass phrase
to still encrypt the file, but just use the hash for in-memory
encryption/decryption (CItemData)? i was thinking we could use the
password's hash to encrypt the password and CItemData, then when the DB is
committed, the password could be decrypted temporarily. i'm just not sure
about the security implications of only using the hash to encrypt the DB.
(echoing those earlier: i'm no cryptographer)
3. network byte order is good.
4. file version. do we have any plans on allowing the file format to be
backward compatible after 2.0? say a field is added for 2.1, should 2.0 be
able to read that file? if no, that just makes our job easier.
5. time_t. do we have to worry about 2038?
Group - the separator character (period '.' as proposed) would need to be
escaped "\." if the user has a period in their entry for whatever reason.
("G.Conklin" -> "G\.Conklin")
i also saw a request for a last used time stamp (RFE 576942), and a URL
field (RFE 564172). the url field was to be used to launch a URL, though,
we could also grab the first URL in the notes field to accomplish the same
7. i agree.