Thread: [Passwordsafe-devel] Format 3.02 ?
Popular easy-to-use and secure password manager
Brought to you by:
ronys
From: Wolfgang K. <91...@gm...> - 2007-06-27 11:55:25
|
Hello Could we get done with the definition of format 3.02? At least I'ld like to have those points fixed which were brought up already, in particular the new header fields. I am preparing a next release of JPasswords and have to decide what format I am addressing and where to place the new header fields. Regards - Wolfgang |
From: ronys <ro...@gm...> - 2007-07-09 13:33:01
|
Hi, Please find in http://passwordsafe.svn.sourceforge.net/viewvc/passwordsafe/trunk/pwsafe/pws afe/docs/formatV3.txt?revision=1551&view=markup (http://tinyurl.com/38pckm) A new version of the file format description, based on discussions on this list. Main changes: - Introduction rewritten. - Clarification regarding field order (only constraint is that last field is of type END). - Clarification regarding Text representation (UTF-8 unless explicitly stated otherwise). - Note regarding misrepresentation of header timestamp as an 8 byte ASCII string. - Deprecation of header field "Who performed last save" (0x05), replaced by "last saved by user" and "last saved on host" (0x07, 0x08). - Addition of database name and database description header fields - Added a section on extensibility, (a) recommended handling of unknown fields, (b) defining application-specific range of type identifiers, guaranteed to be unassigned by the "official" format description. I believe I've addressed all the issues that have been discussed on this list regarding the format. Please let me know if you find any error, or if you see any major difficulty in implementing the format as specified. Cheers, Rony |
From: dk <dk...@gm...> - 2007-07-10 18:01:48
|
I have at least 2 problems with this: 1. The "Who performed last save" (0x05) and "Last saved by user" (0x07) + "Last saved on host" (0x08) Maintaining consistency between field 5 and fields 7 + 8 is impossible. Take this scenario: a. UserA/HostA creates and saves a database using 3.08 and format 0x0301. Only field 5 is in the header. b. UserB/HostB opens this database using 3.09 and saves it using format 0x0302. It writes fields 7 & 8 and could write field 5 should it want - assume it does. c. UserA/HostA re-opens and re-saves this database again using 3.08 and format 0x0301. It ignores, but re-writes, fields 7 & 8 as being "unknown" and only updates field 5 is in the header. Now field 5 = UserA/HostA; field 7 =UserB and field 8 = HostB. These are inconsistent and will be so when read using format 0x0302. 2. The "Timestamp of last save" (0x04) It is correct that PWS V3.08 and earlier do not conform to format 0x0301 in that they store this value as 8 hexadecimal characters rather than time_t (4 bytes). I hope it will be true that V3.09, and later, using format 0x0302 will process this field correctly - it ,suggested that this is based on the length field (8 or 4). My concern is what V3.08 and prior versions will do when they come across a time_t field which is too short. Will they be well behaved? It needs testing. It may not be a problem. Also, by using the length field for the decision on how to process, then this field cannot be migrated to 64-bit time sometime in the future without introducing 0x0400. David -----Original Message----- From: pas...@li... [mailto:pas...@li...] On Behalf Of ronys Sent: 09 July 2007 14:32 To: pas...@li... Subject: [Passwordsafe-devel] PasswordSafe format 0x0302 description Hi, Please find in http://passwordsafe.svn.sourceforge.net/viewvc/passwordsafe/trunk/pwsafe/pws afe/docs/formatV3.txt?revision=1551&view=markup (http://tinyurl.com/38pckm) A new version of the file format description, based on discussions on this list. Main changes: - Introduction rewritten. - Clarification regarding field order (only constraint is that last field is of type END). - Clarification regarding Text representation (UTF-8 unless explicitly stated otherwise). - Note regarding misrepresentation of header timestamp as an 8 byte ASCII string. - Deprecation of header field "Who performed last save" (0x05), replaced by "last saved by user" and "last saved on host" (0x07, 0x08). - Addition of database name and database description header fields - Added a section on extensibility, (a) recommended handling of unknown fields, (b) defining application-specific range of type identifiers, guaranteed to be unassigned by the "official" format description. I believe I've addressed all the issues that have been discussed on this list regarding the format. Please let me know if you find any error, or if you see any major difficulty in implementing the format as specified. Cheers, Rony ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Passwordsafe-devel mailing list Pas...@li... https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel |
From: Wolfgang K. <91...@gm...> - 2007-07-12 10:10:44
Attachments:
PWS Format V3 - B.txt
|
I have seen through 3.02 definition and made editions to some points which I offer in attachment. Please make use of it as you find worth (you may have to see it in a compare-text tool). dk wrote: > I have at least 2 problems with this: > > 1. The "Who performed last save" (0x05) and "Last saved by user" (0x07) + > "Last saved on host" (0x08) > > Maintaining consistency between field 5 and fields 7 + 8 is impossible. > Take this scenario: > > I agree and have edited some changes. Basically the requirement to maintain the old field should be dropped for the new format (and recommended for format 3.01). Instead, the new format should erase this field on encounter. > 2. The "Timestamp of last save" (0x04) > > [...] My concern is what V3.08 and prior versions will do > when they come across a time_t field which is too short. Will they be well > behaved? It needs testing. It may not be a problem. Also, by using the > length field for the decision on how to process, then this field cannot be > migrated to 64-bit time sometime in the future without introducing 0x0400. > > The very correct procedure would be to deprecate this field as well, but I don't suggest it. - Instead my word is: Ignore the problem! This is because this field can be expected to be purely informative and has no bearing on algorithms. Second, any application has to be prepared for invalid field contents without going berserk or crashing. Given that, the worst outcome is a false time value in this place. I could live with it (actually my programs never used format 3.01). Regards - Wolfgang > > > > |