passwordsafe-devel — For developers of Password Safe

Re: [Passwordsafe-devel] Compatibility of MIT License and ArtisticLicense

[ronys <ro...@gm...>]

Hi,

As I understand the MIT license it should be possible to incorporate this
project into the PasswordSafe source tree, providing:
1. The code is in a directory of it's own
2. PasswordSafe's README.txt file & credits.html states that the PPC version
incorporates code from this projext, along with the license terms
3. Files with modifications to the original be clearly marked as modified.

Of course, it would be best to get the project owner's explicit permission.

	Rony

-----Original Message-----
From: pas...@li...
[mailto:pas...@li...] On Behalf Of
Steffen Ryll
Sent: Saturday, May 19, 2007 3:04 PM
To: wce...@li...;
pas...@li...
Subject: [Passwordsafe-devel] Compatibility of MIT License and
ArtisticLicense

X-Post to wcelibcex-devel and passwordsafe-devel

Hi all,

I am currently in the process of porting Passwordsafe (which is under
Artistic License) to the PocketPC OS. I had to discover that MS didn't
implement a number standard C run-time functions, though they are declared
in the usual header files (time.h for instance).

After some googleing and surfing I found the wcelibcex project (which stands
under the MIT License) on Sourceforge which fills most severe gaps in MS's
implementation.

My question to both sides, in particular to the respective copyright
holders, is now whether both licenses are compatible.
Is it acceptable to distribute wcelibcex source code along with Passwordsafe
for PocketPC source code and to incorporate binaries of wcelibcex into
binary Passwordsafe releases?
In my understanding it is ok, but that shouldn't count here :-)

Both license texts can be found here:
http://www.opensource.org/licenses/artistic-license.php
http://www.opensource.org/licenses/mit-license.php

Interested readers can find sources for both projects here:
<http://passwordsafe.svn.sourceforge.net/viewvc/passwordsafe/branches/V1_92P
PC/pwsafe/pwsafe/>
<http://wcelibcex.svn.sourceforge.net/viewvc/wcelibcex/trunk/>

Regards,

Steffen

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

[Passwordsafe-devel] Compatibility of MIT License and Artistic License

[Steffen R. <ste...@st...>]

X-Post to wcelibcex-devel and passwordsafe-devel

Hi all,

I am currently in the process of porting Passwordsafe (which is under
Artistic License) to the PocketPC OS. I had to discover that MS didn't
implement a number standard C run-time functions, though they are
declared in the usual header files (time.h for instance).

After some googleing and surfing I found the wcelibcex project (which
stands under the MIT License) on Sourceforge which fills most severe
gaps in MS's implementation.

My question to both sides, in particular to the respective copyright
holders, is now whether both licenses are compatible.
Is it acceptable to distribute wcelibcex source code along with
Passwordsafe for PocketPC source code and to incorporate binaries of
wcelibcex into binary Passwordsafe releases?
In my understanding it is ok, but that shouldn't count here :-)

Both license texts can be found here:
http://www.opensource.org/licenses/artistic-license.php
http://www.opensource.org/licenses/mit-license.php

Interested readers can find sources for both projects here:
<http://passwordsafe.svn.sourceforge.net/viewvc/passwordsafe/branches/V1_92PPC/pwsafe/pwsafe/>
<http://wcelibcex.svn.sourceforge.net/viewvc/wcelibcex/trunk/>

Regards,

Steffen

Re: [Passwordsafe-devel] Format Tests

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

Oh and I forgot to mention...

I think the range (header and entry) 0x00-0x7f [and 0xff = end of record]
should be reserved for PWS.  Any not currently used should be "reserved for
future use".  PWS should maintain (but otherwise not modify) any in the
range 0x80-0xfe. It is the responsibility of any application that uses any
fields in this range to determine if it is theirs or another application's
and process accordingly.

The "Golden Source" for any field on PWS's range of 0x00-0x7f is the PWS
project (currently a document named "FormatVnn.txt").

David

-----Original Message-----
From: dk 
Sent: 18 May 2007 23:07
To: Wolfgang Keller; pas...@li...
Subject: RE: [Passwordsafe-devel] Format Tests

Wolfgang,

You knew that "d" would not get fixed until V3.02 - so it should be no
surprise that it is as said before = 8 hex digits.

Same goes for "e" since they are not in the V3.01 definition.

It is my view that in V3.02 (when/if it is released):
a. Header 05 (currently nnnnu....uh....h) becomes only u....u (standard text
format) b. Header 07 becomes the h....h from current 05 (standard text
format) c. Either 04 gets re-used as binary time_t or it is ignored and
Header 08 become time_t d. Your "07" and "08" then get implemented as
"08/09" or "09/0a" (hex)

I have suggested to Rony that a draft specification is released for
discussion.  There is no urgency to change the format this minute.  A full
discussion should be had and those interested in the format given a
reasonable period to respond.

Regards,

David


-----Original Message-----
From: pas...@li...
[mailto:pas...@li...] On Behalf Of
Wolfgang Keller
Sent: 18 May 2007 10:50
To: pas...@li...
Subject: [Passwordsafe-devel] Format Tests

Hello

I have tested Rony's 03.07.03 test file of 15 May  and found:
(Not tested header 05 (user) as I'm not supporting it.)

a) text format ok
b) UUID preservation ok
c) ITER preservation ok
-->> d) header 04 (save time) still not as binary integer!
-->> e) header 07 and 08 not supported (preserved)

What is more, I have posted a file into "Support Requests" created by JPWS
in the intended format version 3.02. You might find it useful for testing.
The password to open it is "123456" (excellent!).

- Wolfgang



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

Re: [Passwordsafe-devel] Format Tests

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

Wolfgang,

You knew that "d" would not get fixed until V3.02 - so it should be no
surprise that it is as said before = 8 hex digits.

Same goes for "e" since they are not in the V3.01 definition.

It is my view that in V3.02 (when/if it is released):
a. Header 05 (currently nnnnu....uh....h) becomes only u....u (standard text
format)
b. Header 07 becomes the h....h from current 05 (standard text format)
c. Either 04 gets re-used as binary time_t or it is ignored and Header 08
become time_t
d. Your "07" and "08" then get implemented as "08/09" or "09/0a" (hex)

I have suggested to Rony that a draft specification is released for
discussion.  There is no urgency to change the format this minute.  A full
discussion should be had and those interested in the format given a
reasonable period to respond.

Regards,

David


-----Original Message-----
From: pas...@li...
[mailto:pas...@li...] On Behalf Of
Wolfgang Keller
Sent: 18 May 2007 10:50
To: pas...@li...
Subject: [Passwordsafe-devel] Format Tests

Hello

I have tested Rony's 03.07.03 test file of 15 May  and found:
(Not tested header 05 (user) as I'm not supporting it.)

a) text format ok
b) UUID preservation ok
c) ITER preservation ok
-->> d) header 04 (save time) still not as binary integer!
-->> e) header 07 and 08 not supported (preserved)

What is more, I have posted a file into "Support Requests" created by JPWS
in the intended format version 3.02. You might find it useful for testing.
The password to open it is "123456" (excellent!).

- Wolfgang



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

[Passwordsafe-devel] Format Tests

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

Hello

I have tested Rony's 03.07.03 test file of 15 May  and found:
(Not tested header 05 (user) as I'm not supporting it.)

a) text format ok
b) UUID preservation ok
c) ITER preservation ok
-->> d) header 04 (save time) still not as binary integer!
-->> e) header 07 and 08 not supported (preserved)

What is more, I have posted a file into "Support Requests" created by 
JPWS in the intended format version 3.02. You might find it useful for 
testing. The password to open it is "123456" (excellent!).

- Wolfgang

[Passwordsafe-devel] Proper unicode support - 3.07.03

[ronys <ro...@gm...>]

Hi,

As some of you may know, recent versions of passwordsafe have had issues
with non-English text in databases.

After some work, I've finally gotten passwordsafe to store/retreive data in
utf-8 encoding in the database (again), and have built the application with
unicode support (text is represented in wchar_t rather than chars, linked
against unicode version of MFC). The result is a version that should fully
support non-English text in a portable manner.

I'd appreciate it if readers of this list would download and try
http://passwordsafe.sf.net:/tmp/pwsafe-3.07.03-bin.zip

Note that this should work fine with new databases, and be able to read
existeng databases PROVIDED that they have only ASCII (English) text.
Databases with non-English text written by this version may be read
incorrectly by previous versions.
Bottom line: Please use this for testing only - NOT for real data!

Please drop me a line letting me know if you've tested this, even
(especially?) if the test succeeded.

	Thanks,

		Rony

P.S. - The next formal release of pwsafe (3.08) will have some more
features, plus (hopefully) some or all of the database changes that have
been discussed on this list.

Re: [Passwordsafe-devel] Updates

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

On Fri, 11 May 2007 15:59:39 -0400, dk <dk...@gm...> wrote:
>
> Re: "blobs", I would like more clarification.....
> Do you mean "unknown fields" in a record as a blob and you display,  
> process or otherwise use the fields you know about?
>

Hi David,

take, for example the recently introduced "password history" field.  I have
not implemented that field.  So when reading a record that contains a  
password
history, Password Gorilla stores the association <type=15,data=...> in  
memory,
along with the "known" information about the record.  The field is not  
shown
or otherwise indicated to the user.

Some implementation detail: my "password safe database" backend class just
stores, for each record, a mapping of field types to data, without  
interpreting
either.  It is the front-end that interprets the fields it knows about.

When writing the database, I just write the same field type and data back
into the database, and Password Safe users will find their password history
unchanged.

Password Gorilla therefore does not respect the password history, and does
not update the password history when the password itself is changed.  But
I find that the lesser evil compared to just discarding the password  
history.

>
> What if these unknown fields have dependencies on the fields that you do
> know and maybe change?
>

I don't know, I think the risk of that happening is very low, especially if
all fields are properly documented.

But it's an implementation choice, so feel free to think and do  
differently.

Frank


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

Re: [Passwordsafe-devel] Updates

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

I agree re: lengths.  It is up to the implementation to decide what to
display and where etc.

Re: "blobs", I would like more clarification.....

You say '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.'

Do you mean "unknown fields" in a record as a blob and you display, process
or otherwise use the fields you know about?

What if these unknown fields have dependencies on the fields that you do
know and maybe change?

I still think that if there are unknown header or record fields then PWS
should:
a. be tolerant of them (i.e. no program failures),
b. ignore them, and
c. force the database into read-only mode so that there is no danger of it
corrupting connections it does not know about.

David


-----Original Message-----
From: Frank Pilhofer [mailto:fp...@fp...] 
Sent: 11 May 2007 03:50
To: dk; pas...@li...
Subject: Re: [Passwordsafe-devel] Updates

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

Re: [Passwordsafe-devel] Updates

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

Whilst H-Field 05 change is purely a documentation update, changes to
H-Field 04 and adding H-Field 07 and H-Field 08 require "programming
changes".

My view would to be to:
a. Update the documentation of H-Field 05 to be correct as implemented in
format version 0x0301
b. When the next format version (0x0302/0x0400s?) is decided, then correct
H-Field 04 to be time_t, add H-Field 07 and H-Field 08 and maybe split
H-Field 05 into separate user and host fields without the need for the extra
'nnnn' length prefix.

David

PS. As of revision 1422, PWS no longer changes the database UUID or reset
the number of hash iterations to 2048 every time it saves a database.  New
versions of the database UUID are created on 'SaveAs' and 'New' where the
number of hash iterations defaults to 2048.



-----Original Message-----
From: pas...@li...
[mailto:pas...@li...] On Behalf Of
Wolfgang Keller
Sent: 11 May 2007 17:54
To: pas...@li...
Subject: Re: [Passwordsafe-devel] Updates

H-Field 04
Suggest to stay with the definition as a time_t. By this all time fields can
be treated in the same manner and issues like number of bytes etc. 
apply to all.

H-Field 05
The definition in format3.txt is still demanding.  It should be improved by
something like the following:

Text (representation as in 3.1.2) saved in the format:: nnnnu..uh..h, where:

    nnnn = 4 hexadecimal digits giving the length of the user name (u)
    u..u = user name
    h..h = host computer name


H-Fields 07 + 08
I can live with the description field to be unlimited, but I want the name
field limited. It is meant as a single line expression of not oversizing
length. Not every text field has to be a free text field!

- Wolfgang



>   

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

Re: [Passwordsafe-devel] Updates

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

H-Field 04
Suggest to stay with the definition as a time_t. By this all time fields 
can be treated in the same manner and issues like number of bytes etc. 
apply to all.

H-Field 05
The definition in format3.txt is still demanding.  It should be improved 
by something like the following:

Text (representation as in 3.1.2) saved in the format:: nnnnu..uh..h, where: 
    nnnn = 4 hexadecimal digits giving the length of the user name (u)
    u..u = user name
    h..h = host computer name


H-Fields 07 + 08
I can live with the description field to be unlimited, but I want the 
name field limited. It is meant as a single line expression of not 
oversizing length. Not every text field has to be a free text field!

- Wolfgang



>   

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

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

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

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

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

_


_

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

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

dk wrote:
> Actually...
>
> On most systems, time_32t is a signed 32-bit integer with a max. of 03:14:07
> UTC on Tuesday, January 19, 2038, and only if made "unsigned" does it go on
> to 2106.
>
> time_64t on most systems is a signed 64-bit integer.  If treated as
> "unsigned", it would have a max. on December 4, 292,277,026,596.
>
> I doubt very much that I (or PasswordSafe) will be here for the second date
> (290+ billion years time) and I think it is unlikely that I will really care
> about it on the first!
>
> David
>
>
>   

Are you saying that you are developing Password Safe for your own 
purposes? - Indeed in this case these considerations are irrelevant, but 
also your contradiction is!

Allowing a 64-bit value as *alternative* does not cause problems but 
brings benefits, so why not admit it? - It does not cost more storage 
and all readers who are not interested in 8 bytes have to do is just 
read the first 4 bytes, which they probably are doing already anyway.

- Wolfgang

[Passwordsafe-devel] Updates

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

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

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

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

Actually.....

On most systems, time_32t is a signed 32-bit integer with a max. of 03:14:07
UTC on Tuesday, January 19, 2038, and only if made "unsigned" does it go on
to 2106.

time_64t on most systems is a signed 64-bit integer.  If treated as
"unsigned", it would have a max. on December 4, 292,277,026,596.

I doubt very much that I (or PasswordSafe) will be here for the second date
(290+ billion years time) and I think it is unlikely that I will really care
about it on the first!

David


-----Original Message-----
From: pas...@li...
[mailto:pas...@li...] On Behalf Of
Wolfgang Keller
Sent: 09 May 2007 16:11
To: pas...@li...
Subject: Re: [Passwordsafe-devel] Enhancement Topics (Format and Usage Bugs)

Looks good to me.

I have one point with the *time_t* format. - FYI, the 32-bit integer value
has a final date of  2106-02-07 07:28:15 CEST. People, this is less than 100
years from now! :) - I'ld strongly suggest to declare the 64-bit value as a
valid alternative for time_t. Note that this does not conflict existing
32-bit values in little endian orientation. Readers just may detect the
length of a value; also readers who only read the first 4 bytes still gain
the correct values (until 2106).

- Wolfgang


ronys wrote:
> Hi folks,
>
> Good discussion. I agree that the format description is one of the 
> more important parts of the project (probably what will outlive the 
> application itself, not to mention myself).
>
> I've updated the document a bit, adding an explicit 'representation' 
> section
> 3.1:
> http://passwordsafe.svn.sourceforge.net/viewvc/passwordsafe/trunk/pwsa
> fe/pws
> afe/docs/formatV3.txt?view=markup
>
> Constructive comments, as usual, are welcome. Other comments > /dev/null.
>
> 	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
>
>   

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

Re: [Passwordsafe-devel] Topic 3: Foreign Usage Convention

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

On Tue, 08 May 2007 02:10:51 -0400, Wolfgang Keller <91...@gm...> wrote:
>
> The most crucial point here is a convention on the usage of field types
> for applications. In the Java library KSE-PWSLIB (which I offer along
> with JPasswords) I recommend users to respect a reserved field range of
> 0x00 up to 0x7F. My suggestion is to declare this range as under the
> "legislation" of the Password Safe project (including close friends) and
> allow the range above as "free use". - FYI, in JPWS I "claim" a range of
> 0x40 to 0x4F for specific use.
>

Hi,

I disagree that any field types should be reserved for particular
applications.  Once you start doing that, every application will be
reserving their own values, and interoperability will be greatly
impacted.

If applications want to use your library for data storage, they are
welcome to use any field types they want, but then the resulting file
will not be a Password Safe (-compatible) password database.

>
>                                Possibly a document could be created
> where reserved field ranges (of major or closely related projects) would
> be stated.
>

There should be a document that states the specific format for each and
every possible field type in a Password Safe (-compatible) database --
and that document is formatV3.txt in the Password Safe repository.

I'm sure that the project admins here will not mind adding field types
if they hear a good idea.

Frank


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

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

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

Actually...

On most systems, time_32t is a signed 32-bit integer with a max. of 03:14:07
UTC on Tuesday, January 19, 2038, and only if made "unsigned" does it go on
to 2106.

time_64t on most systems is a signed 64-bit integer.  If treated as
"unsigned", it would have a max. on December 4, 292,277,026,596.

I doubt very much that I (or PasswordSafe) will be here for the second date
(290+ billion years time) and I think it is unlikely that I will really care
about it on the first!

David


-----Original Message-----
From: pas...@li...
[mailto:pas...@li...] On Behalf Of
Wolfgang Keller
Sent: 09 May 2007 16:11
To: pas...@li...
Subject: Re: [Passwordsafe-devel] Enhancement Topics (Format and Usage Bugs)

Looks good to me.

I have one point with the *time_t* format. - FYI, the 32-bit integer value
has a final date of  2106-02-07 07:28:15 CEST. People, this is less than 100
years from now! :) - I'ld strongly suggest to declare the 64-bit value as a
valid alternative for time_t. Note that this does not conflict existing
32-bit values in little endian orientation. Readers just may detect the
length of a value; also readers who only read the first 4 bytes still gain
the correct values (until 2106).

- Wolfgang


ronys wrote:
> Hi folks,
>
> Good discussion. I agree that the format description is one of the 
> more important parts of the project (probably what will outlive the 
> application itself, not to mention myself).
>
> I've updated the document a bit, adding an explicit 'representation' 
> section
> 3.1:
> http://passwordsafe.svn.sourceforge.net/viewvc/passwordsafe/trunk/pwsa
> fe/pws
> afe/docs/formatV3.txt?view=markup
>
> Constructive comments, as usual, are welcome. Other comments > /dev/null.
>
> 	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
>
>   

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

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

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

Looks good to me.

I have one point with the *time_t* format. - FYI, the 32-bit integer 
value has a final date of  2106-02-07 07:28:15 CEST. People, this is 
less than 100 years from now! :) - I'ld strongly suggest to declare the 
64-bit value as a valid alternative for time_t. Note that this does not 
conflict existing 32-bit values in little endian orientation. Readers 
just may detect the length of a value; also readers who only read the 
first 4 bytes still gain the correct values (until 2106).

- Wolfgang


ronys wrote:
> Hi folks,
>
> Good discussion. I agree that the format description is one of the more
> important parts of the project (probably what will outlive the application
> itself, not to mention myself).
>
> I've updated the document a bit, adding an explicit 'representation' section
> 3.1:
> http://passwordsafe.svn.sourceforge.net/viewvc/passwordsafe/trunk/pwsafe/pws
> afe/docs/formatV3.txt?view=markup
>
> Constructive comments, as usual, are welcome. Other comments > /dev/null.
>
> 	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
>
>   

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

[ronys <ro...@gm...>]

Hi folks,

Good discussion. I agree that the format description is one of the more
important parts of the project (probably what will outlive the application
itself, not to mention myself).

I've updated the document a bit, adding an explicit 'representation' section
3.1:
http://passwordsafe.svn.sourceforge.net/viewvc/passwordsafe/trunk/pwsafe/pws
afe/docs/formatV3.txt?view=markup

Constructive comments, as usual, are welcome. Other comments > /dev/null.

	Cheers,

		Rony

[Passwordsafe-devel] Topic 3: Foreign Usage Convention

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

*** *Foreign Usage Convention* ***

I like the idea of fully enabling the PWS file format as a 
multi-application and potential multi-purpose storage tool. If you like 
to follow me here, I'ld recommend to introduce certain regulations 
concerning multi-usage in order to prevent errors based on bad coordination.

A. Range of Field types
The most crucial point here is a convention on the usage of field types 
for applications. In the Java library KSE-PWSLIB (which I offer along 
with JPasswords) I recommend users to respect a reserved field range of 
0x00 up to 0x7F. My suggestion is to declare this range as under the 
"legislation" of the Password Safe project (including close friends) and 
allow the range above as "free use". - FYI, in JPWS I "claim" a range of 
0x40 to 0x4F for specific use. Possibly a document could be created 
where reserved field ranges (of major or closely related projects) would 
be stated.

B. Field Access Rules
For the "free use" field range additional rules, like e.g. data marking, 
could be recommended to prevent false data reading.

Cheers!
- Wolfgang Keller

[Passwordsafe-devel] Topic 4: New Header Data Fields

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

*** *New Header Data Fields* ***

Last but not least I'ld like to recommend additional header data fields 
to integrate into the PWS canon.

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.


With the next release of JPWS I will make use of these fields. Currently 
an open question is which types I will assign to them. If you find them 
useful too, we could place them into the PWS canon, otherwise I would 
name them in the JPWS canon.

What do you think of it?

Some repair appears to be due on (factually implemented) format version 
3.01 anyway, so there is a chance to create the new version 3.02 which 
also reflects my suggestions.

Cheers!
- Wolfgang Keller

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

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

On Tue, 08 May 2007 02:53:27 -0400, Wolfgang Keller <91...@gm...> wrote:
>
> The definition is still to weak or misleading. Without being an expert
> in this, I know that UTF-8 may come with something they call "BOM" as a
> prefix token. Moreover, UTF-8 encoding is a bit-format, not a text
> format and I would not expect that null bytes are to be excluded from
> being a valid part of it. So I suggest the following text as definition
> for "Text":
>

Hi Wolfgang and all,

BOMs ("Byte Order Marks") may be used with UTF-16 or UTF-32 to indicate
that a code unit sequence is serialized in either big or little endian
order.  UTF-8 is byte oriented, and has no need for BOMs.

Let's just delegate the responsibility to the appropriate party, with the
appropriate references.

    Text fields are stored using the UTF-8 encoding scheme (see definition
    D-39 of the Unicode Standard 4.0 at
    http://www.unicode.org/versions/Unicode4.0.0/ch03.pdf).  Note that a
    Unicode string (D-29a) does not contain any terminating NUL character
    that might exist in a C language implementation; consequently, no
    NUL character is stored or counted as part of the field length.  I.e.,
    the ASCII string "Hello World" is stored as a single block, with the
    field length set to 11.

We could strike the second sentence, because it is implicit from the first,
but given that I have been recently bitten by an incompatibility involving
the null character recently, I'd like to see it included.

Frank

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

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

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

>
> Frank Pilhofer wrote:
>   
> Indeed.  I seem to remember that we finalized on using UTF-8, with no null
> byte at the end.  Yet I can find no record of that decision in the current
> formatV3.txt document.  Rony, can you please add a note to the formatV3.txt
> file to that effect, e.g.,
>
>    Text fields are stored using the UTF-8 character encoding.  No null
>    character is stored in the record data or counted as part of the field
>    length.  I.e., the ASCII string "Hello World" is stored as a single
>    block, with the field length set to 11.
The definition is still to weak or misleading. Without being an expert 
in this, I know that UTF-8 may come with something they call "BOM" as a 
prefix token. Moreover, UTF-8 encoding is a bit-format, not a text 
format and I would not expect that null bytes are to be excluded from 
being a valid part of it. So I suggest the following text as definition 
for "Text":

   Text fields are stored using the plain UTF-8 character encoding without
   use of encoding signatures (BOM) or leading or trailing data length markers. 
   I.e., the ASCII string "Hello World" is stored as a single
   block, with the field length set to 11.


- Wolfgang

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

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

On Mon, 07 May 2007 12:02:03 -0400, Wolfgang Keller <91...@gm...> wrote:
>
> looks like I have 4 major topics which I will bring in as separate post
> for discussion.
>

Hi Wolfgang,

just wanted to point out that these are implementation issues rather
than format issues.  The formatV3.txt document should be definitive,
and implementations ("Password Safe Clones") should conform to that
document.

If Password Safe or any other implementation does not comply with the
format document, the implementation should be fixed rather than the
document.  Once some clones begin copying other implementations'
issues and bugs, we lose interoperability.

The formatV3.txt shall be concise enough that no incompatible
interpretations can exist.

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

Just FYI, my implementation retains the number of iterations across save
operations, and prints a warning when a value less than 2048 is used.
Again, this is an implementation detail.

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

Indeed.  I seem to remember that we finalized on using UTF-8, with no null
byte at the end.  Yet I can find no record of that decision in the current
formatV3.txt document.  Rony, can you please add a note to the formatV3.txt
file to that effect, e.g.,

   Text fields are stored using the UTF-8 character encoding.  No null
   character is stored in the record data or counted as part of the field
   length.  I.e., the ASCII string "Hello World" is stored as a single
   block, with the field length set to 11.

Frank


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