passwordsafe-devel — For developers of Password Safe

[Passwordsafe-devel] Topic 2: Tolerating Unknown Fields

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

*** *Tolerating Unknown Fields* ***

In my topic 2 I speak about tolerating unknown data elements in a PWS 
file. "Unknown data elements" are correctly implemented data fields, 
either within an entry record or in the file header field list, whose 
type identifiers are outside of the defined canon of a given file format 
definition.

The PWS file format is some achievment because it is very well apt to 
serve as a general encrypted data storage tool. Meanwhile there are 
several password applications using this format. It is possible, and it 
really happens, that their realms of used field types do not exactly 
match and some programs deal with proprietary extra fields. I'ld like to 
propagate tolerance of this behaviour as it makes sense and gives added 
functionallity where needed.

In JPWS I implemented preservation of all data fields which are 
identified as "non-canonical". These fields are kept outside of any 
visible or practical scope of the program, but are saved back to the 
persistent file when it comes to a save operation. This is not really 
difficult to implement, more or less you just need to store those fields 
into lists when loading a database.

This is a minimal step each PWS application can perform in respect of 
all other such applications. (It also gives added security when people 
perform mixed usage of different versions of the same program.) - I 
think it is a good idea and I would be happy if Password Safe would 
implement and moreover announce it as a recommended standard behaviour.

Cheers!
- Wolfgang Keller

[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

Re: [Passwordsafe-devel] 3.06 Writes Null-terminated Strings, breaks Compatibility

[Rony S. <ro...@gm...>]

Hi Frank,

Makes sense. I've implemented, tested and committed the change you've
suggested - thanks!

This could explain a lot of problems people have been reporting with
non-English textual data on the Windows version as well.

	Cheers,

		Rony

-----Original Message-----
From: Frank Pilhofer [mailto:fp...@fp...] 
Sent: Saturday, March 31, 2007 6:22 AM
To: Password Safe Development
Cc: Rony Shapiro
Subject: 3.06 Writes Null-terminated Strings, breaks Compatibility

Hi Rony,

I've had reports from some users that failed to load Password Safe
databases into Password Gorilla, when those databases were generated
with Password Safe 3.06 (and, as it turns out, 3.07).

Investigation shows that Password Safe 3.06 and later write an
additional NUL character at the end of each string.

The culprint seems to be a change to PWSfileV3::ToUTF8() in corelib/
PWSfileV3.cpp, near line 797.  The m_utf8Len variable ends up including
the terminating null character.  This length is then passed to WriteCBC().

NUL characters are an artifact of C strings; they are not necessary
in other programming languages, and they are not necessary in the file,
given each field's explicit length information.  And PWSFileV3::FromUTF8()
works fine in the absence of a NUL character also.

Can you please fix future versions of Password Safe?  A "m_utf8Len--;"
at the end of ToUTF8(), after the assert statement, should do it.  (I
haven't tested this; I don't have a VC8 installation at hand.)

Frank

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

[Passwordsafe-devel] 3.06 Writes Null-terminated Strings, breaks Compatibility

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

Hi Rony,

I've had reports from some users that failed to load Password Safe
databases into Password Gorilla, when those databases were generated
with Password Safe 3.06 (and, as it turns out, 3.07).

Investigation shows that Password Safe 3.06 and later write an
additional NUL character at the end of each string.

The culprint seems to be a change to PWSfileV3::ToUTF8() in corelib/
PWSfileV3.cpp, near line 797.  The m_utf8Len variable ends up including
the terminating null character.  This length is then passed to WriteCBC().

NUL characters are an artifact of C strings; they are not necessary
in other programming languages, and they are not necessary in the file,
given each field's explicit length information.  And PWSFileV3::FromUTF8()
works fine in the absence of a NUL character also.

Can you please fix future versions of Password Safe?  A "m_utf8Len--;"
at the end of ToUTF8(), after the assert statement, should do it.  (I
haven't tested this; I don't have a VC8 installation at hand.)

Frank

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

Re: [Passwordsafe-devel] PocketPC PWSafe

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

... Oops, this should have gone to the list instead of only to Robert. 
I've sent it already on 2007/03/28...

Hi,

Robert Altman wrote:
> I'm not sure what the best starting point is, but I would like to see
> if we can create:
> 1.  Developer list.

I suppose Rony is busy enough with developing the desktop version.
Does anyone else beside Robert and me volunteer? *listen for echo*

> 2.  Project plan - Goals & Division of labor

goals (proposals):

- have an (almost) identical codebase for Win32 and PPC version
(differences should be encapsulated in project configuration, i.e. PPC
version need not use all existing classes)
- let PPC version read format v1, v2, v3 files
- short-term: build with same GUI as v1.92c2
- long-term: reflect new capabilities in GUI
- support for PocketPC 2003 and newer --> we can use VS2005
- very-long-term: ActiveSync plugin to sync passwords

division of labor:
I would prefer to concentrate on support for v2 and v3 files and on
unifying the codebase. And I'd like to leave my fingers off the GUI, I'm
not so familiar with that :-)

> 3.  Prototype UI

deliberatly left blank ;-)

Cheers,

Steffen

Re: [Passwordsafe-devel] Code docu, parameter validation, CMyString

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

Hi,

Rony Shapiro wrote:
> - Doxygen is cool, and adding comments so that they can be parsed by it
> would be great. If you (or anyone) cares to write a "template" .h and .cpp
> file showing how to do this, that would help a lot.

I have just commited a doxygen config file and such a template .h and 
.cpp file. I've also set an svn:ignore property, so that all generated 
documentation HTMl files aren't listed as unversioned by Subversion.

All you have to do is downloading doxygen from www.doxygen.org and point 
  it to Doxyfile. Be sure that your working directory is the project 
directory, otherwise it won't put the HTML where you expect it :-)

In the files DoxyTempl.{h,cpp} is a small intro to writing documentation 
for and with doxygen.

Please let me know if you have any questions

Cheers,

Steffen

[Passwordsafe-devel] Announcing PasswordSafe 3.07

[Rony S. <ro...@gm...>]

Hi,

This is to announce the release of PasswordSafe version 3.07.

This is a minor release - some annoying bugs have been fixed, some minor
features have been added or improved upon.  
Thanks to DK his work on this release, and to the folks who tested the
pre-release version.  
 
The U3 version will be available soon from 
http://software.u3.com/Product_Details.aspx?productId=294&Selection=7 

Bugs fixed in 3.07
=====================
[1684827, 1668493] No longer crashes after you specify to remember 0
databases
[1675716] <ESC> to close application now works
[1673028] Merge operation now fixed
[1673028] Similar problem in Compare operation fixed
[1660721] Autotype menu & shortcut no longer disabled if field is empty.
[1679461, 1612567] Text in Password field no longer truncated with large
texts.
[1682516] Menu display no longer trashed if accelerator pressed with an open
menu.
[1683060] Autotype now works again for all entries
[1678707] CapsLock temporarily turned off in Autotype
[1681366] Now stays on top during autotype
[1672770] Right-click->unlock on system tray icon now same as
double-clicking on locked system tray icon

New Features for 3.07
=====================
[] - Password expiration notice can now be given a few days prior to actual
expiration
[] - Exported/imported text format is now documented in online help
[1623802] Default Autotype string can be specified per database
[1686819] - PWS may configured not to minimize during Autotype
(Manage->Options->Misc). 'Always on Top' takes precedence.
[] If the PWS_PREFSDIR environment variable is defined, that's where the
pwsafe.cfg file will be read from, instead of the same directory as the
executable

Changes to Existing Features in 3.07
====================================
[] List view columns now selectable, entries sortable by any column,
settings are persistent.
[] List view may be configured to show Grid lines.
[] Tree view may be configured to show all groups first, instead of strict
alphabetic order.

The release may be downloaded from  
https://sourceforge.net/project/showfiles.php?group_id=41019&package_id=3316
9&release_id=497452 
(http://preview.tinyurl.com/3y6c59) 
 
SHA-1 checksums:  
5c4657a2bc8a435c53b74d772179d6321767e3f6 pwsafe-3.07.exe 
71c3ef2017f936e626287d40dea2e54dffc4ad21 pwsafe-3.07-bin.zip 
dde5efea52bade212a6b81baa9c245485e5025e5 pwsafe-3.07-src.zip 

Note that this release also includes PGP/GPG signature files of the
respective packages. These were signed with my SourceForge account key,
keyid FA175557, key fingerprint = FF77 379D D46D DAA6 6182   B452 1D79 5A91
FA17 5557, available from a PGP keyserver near you (such as
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFA175557).
 
         Enjoy,
 
                 Rony

[Passwordsafe-devel] PocketPC PWSafe

[Robert A. <ro...@Al...>]

Steffen, Rory:

I tend to agree with Rory, the "secure" versions provide some
worthwhile benefit.  I would like to get together a list of PocketPC
developers interested in creating the PPC PWSafe version.  I have been
trying to get back to this project myself, and have been, until
recently, pre-occupied with an extended illness in the family.

I'm not sure what the best starting point is, but I would like to see
if we can create:
1.  Developer list.
2.  Project plan - Goals & Division of labor
3.  Prototype UI

Robert Altman

[Passwordsafe-devel] PasswordSafe 3.07 pre-release

[Rony S. <ro...@gm...>]

Hi,

I've just uploaded a pre-release of the next version of PasswordSafe, =
and
would appreciate any inputs from the PasswordSafe user and developer
community, before I "officially" release it, hopefully in a few days. =
This
version has fixes and new features implemented by DK and myself.

Aside from the changes listed in the release notes (and detailed below),
I've made this version "statically linked". This should eliminate a =
whole
category of problems people have been reporting with incompatible dll
versions, no installation rights, etc.

3.07 (1316) may be downloaded from
http://passwordsafe.sf.net/tmp/pwsafe-3.07-bin.zip (zip file with =
executable
and related files)
or
http://passwordsafe.sf.net/tmp/pwsafe-3.07.exe (self-extracting
installation)

=E3
SHA1 hashes:
b75e59ac3db07d6ee1b0a96b6ac1b589f5ceb743  pwsafe-3.07-bin.zip
4e16367d117599b11475ea321cf9c0b63e4a80af  pwsafe-3.07.exe

(Note that the help file has NOT been updated yet)

Thanks for your help,

	Rony

Release Notes for 3.07 (1316):

Bugs fixed in 3.07
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
[1684827, 1668493] No longer crashes after you specify to remember 0
databases
[1675716] <ESC> to close application now works
[1673028] Merge operation now fixed
[1673028] Similar problem in Compare operation fixed
[1660721] Autotype menu & shortcut no longer disabled if field is empty.
[1679461, 1612567] Text in Password field no longer truncated with large
texts.
[1682516] Menu display no longer trashed if accelerator pressed with an =
open
menu.
[1683060] Autotype now works again for all entries
[1678707] CapsLock temporarily turned off in Autotype
[1681366] Now stays on top during autotype
[1672770] Right-click->unlock on system tray icon now same as
double-clicking on locked system tray icon

New Features for 3.07
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
[] - Password expiration notice can now be given a few days prior to =
actual
expiration
[] - Exported/imported text format is now documented in online help
[1623802] Default Autotype string can be specified per database
[1686819] - PWS may configured not to minimize during Autotype
(Manage->Options->Misc). 'Always on Top' takes precedence.
[] If the PWS_PREFSDIR environment variable is defined, that's where the
pwsafe.cfg file will be read from, instead of the same directory as the
executable

Changes to Existing Features in 3.07
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
[] List view columns now selectable, entries sortable by any column,
settings are persistent.
[] List view may be configured to show Grid lines.
[] Tree view may be configured to show all groups first, instead of =
strict
alphabetic order.

Re: [Passwordsafe-devel] Code docu, parameter validation, CMyString

[Rony S. <ro...@gm...>]

 Hi,

Good questions, all. Here are my replies:

- Doxygen is cool, and adding comments so that they can be parsed by it
would be great. If you (or anyone) cares to write a "template" .h and .cpp
file showing how to do this, that would help a lot.

- Regarding parameter validation:
The approach I like is that parameters that can be wrong due to programming
errors should be checked by "ASSERT" statements. This is especially true for
pointers that should never be NULL. parameters that can be bad due to user
input or runtime errors (such as a file that failed ot open) should be
checked in the non-debug version as well. In the example you described, I
consider having CXMLprefs::Load() called with an invalid filename a
programming error, which should be detected & prevented by higher levels.

- CMyString started out as a wrapper/replacement for CString, with the main
difference in that the destructor "wipes" the text that the object held, so
as not to leave potentially sensitive data floating around in memory. The
current convention is for CString to be used for insensitve data, and
CMyString to be used otherwise. If I were to code the project from scratch
today, I'd probably use std::string instead of CString, and define a
SecureString class for sensitive text...

	Cheers,

		Rony

-----Original Message-----
From: pas...@li...
[mailto:pas...@li...] On Behalf Of
Steffen Ryll
Sent: Tuesday, March 13, 2007 1:16 AM
To: pas...@li...
Subject: [Passwordsafe-devel] Code docu, parameter validation, CMyString

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

a few question for which I couldn't find answers:

- - do you have any conventions for code documentation (e.g. descriptions
what methods do and what their parameters mean)? Possibly an approach,
that allows to generate HTML or similar out out comments strinkled over
the code..
If not, what about using doxygen (http://www.stack.nl/~dimitri/doxygen)?
It can generate HTML, PDF etc. from specially marked code comments,
comparable to javadoc. If haven't chosen such a tool yet, I will write a
 config file for doxygen


- - do you have any conventions/ a rule of thumb, where parameters should
be validated and where we trust they are correct?
I made some enhancements to the unit tests (not in svn yet) during the
weekend and asked myself whether it makes sense to add validations.
For instance, if you instantiate CXMLprefs with an empty or non-existent
file name, the first Load() call asserts. Is this worth fixing or do we
rely on parameter validation in higher-level classes?

- - Is it correct that CMyString is intended as a wrapper around MFC's
CString, in order to improve portability?
This confuses me a little bit, because CString is used so often in other
classes (I looked only into corelib).


Cheers,

Steffen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF9d9FCAP6QscD9IERAth2AKCoMZC3JriAAA9IfUbZx6kTrBzSvgCglWAm
8rxjvTb7SV44zDl6YbUHPGc=
=w0Rp
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Passwordsafe-devel mailing list
Pas...@li...
https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel

[Passwordsafe-devel] Code docu, parameter validation, CMyString

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

a few question for which I couldn't find answers:

- - do you have any conventions for code documentation (e.g. descriptions
what methods do and what their parameters mean)? Possibly an approach,
that allows to generate HTML or similar out out comments strinkled over
the code..
If not, what about using doxygen (http://www.stack.nl/~dimitri/doxygen)?
It can generate HTML, PDF etc. from specially marked code comments,
comparable to javadoc. If haven't chosen such a tool yet, I will write a
 config file for doxygen


- - do you have any conventions/ a rule of thumb, where parameters should
be validated and where we trust they are correct?
I made some enhancements to the unit tests (not in svn yet) during the
weekend and asked myself whether it makes sense to add validations.
For instance, if you instantiate CXMLprefs with an empty or non-existent
file name, the first Load() call asserts. Is this worth fixing or do we
rely on parameter validation in higher-level classes?

- - Is it correct that CMyString is intended as a wrapper around MFC's
CString, in order to improve portability?
This confuses me a little bit, because CString is used so often in other
classes (I looked only into corelib).


Cheers,

Steffen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF9d9FCAP6QscD9IERAth2AKCoMZC3JriAAA9IfUbZx6kTrBzSvgCglWAm
8rxjvTb7SV44zDl6YbUHPGc=
=w0Rp
-----END PGP SIGNATURE-----

Re: [Passwordsafe-devel] PocketPC / Windows Mobile development

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

Hi,

James wrote on 18/07/2006:
> Robert Altmann wrote on 17/07/2006:
>> I would like to come up with a plan of attack here. I think we need to:
>> 
>> (1) Determine our starting point. I have already started on getting
>> the current code compiled with Visual Studio 2005, although there are some
>> errors. Has anyone else started working on any other parts?

I also started this effort in the corelib project. Currently it results 
in 99 compile errors (not yet committed to svn).
Most problems are in PWScore.cpp, IIRC ~80 compile errors. The reason 
seems to be in most cases that UNICODE breaks strings conversions.

AFAIK, UNICODE must be defined in all PocketPC projects, no way out...

>> (2) Pick the environment; .NET 1.1 (Visual Studio 2003) or .NET 2.0
>> (Visual Studio 2005). My vote is for VS2005 and .NET 2.0; there is
>> additional PocketPC emulation support and I believe the task will be easier.

First, I think we should evaluate which platforms shall be supported. 
According to what I read in MSDN, PocketPC 2003 was the first version 
that shipped with .NET CF. For PocketPC 2000 & 2002, the compact 
framework is only an add-on that every device manufacturer must 
incorporate into its ROM images.
I can't imagine that .NET CF is really wide-spread on these old devices, 
but I'm also not sure whether these devices are still so often used that 
they deserve pwsafe support.

Personally, I need only support for PocketPC 2003 (not SE) and maybe 
newer. Does Sourceforge offer an opinion poll function, that we can find 
out whether PocketPC 2000/02 are required as well?
I hope not, otherwise we need go back to embedded Visual C++ 4 which 
doesn't run under WinXP SP2.

However, I think we should stick to .NET CF 1.x or even native C++.
Native C++ promises best backwards compatibility, I suppose.

>> (3) Come up with a plan and divide the tasks. I believe there are
>> four significant areas: WinMobile UI; WinMobile program; C# /C++ interface;
>> and install. I'm certain we can refine/improve this list, but at least we
>> have a starting point.

corelib (is this what you called WinMobile program?) should be kept in 
C++, to reduce development effort and maintain compatibility with 
desktop version.

The WinMobile UI can be written either in C++ or .NET (C#). C# is 
easier, but we have to reinvent the wheel and we must deal with the 
hassles of a C#/ C++ interface.
With C++, we can take advantage of the existing desktop implementation 
and take ideas from the v1.92 PPC implementation.

If this C#/C++ interface is required, my proposal would be to that (in 
terms of the MVC pattern) the model with all the crypto and file 
routines is C++ and controller and view are C#

Installing is done with a simple cab file, right? AFAIR, VS2005 comes 
with support for PPC installer projects.

> Another thing to consider is how it interacts with ActiveSync.
> Will it rely of just copying the .psafe3 file, or will it have it's own sync
> module to merge the files. The latter would require either entering the
> password on every sync (annoying), storing the password (bad), or changing
> the format to allow a merge with decrypting (which I suggested before, but
> was shot down)

For starting, we will have to live with the simple copy mechanism, I 
suppose.
I think the file format allows to detect changes, so an ActiveSync 
plugin could ask for the passphrase in these cases in perform a sync and 
otherwise remain silent.

> As for your plan of attack, you seem to be glossing over a few
> details. Is C++/MFC is option? Before we discuss the C# / C++ interface we
> need to discuss the C# / C++ divide.

As stated above already, I'm also more in favour of the C++/MFC approach.


I will continue work on corelib, because I think that won't be affected 
by this discussion :-) I will send some patches soon.

Cheers,

Steffen

Re: [Passwordsafe-devel] Concerns with use of security enhanced string functions

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

Hi,

Rony Shapiro wrote:
> Using the _s versions of library functions seems to me a Good Thing, [...]
> 
> Therefore, I think they should be used where possible. It would be nice to
> have some wrappers around them, though, to eliminate the #ifdefs sprinkled
> throughout the code...
> 

agreed, I think I can implement this soon. For now, I took the easy way 
and corrected the #ifdefs only.
Would PWSUtil be a suitable place for these wrappers?

Thanks for your comments,

Steffen

> -----Original Message-----
> From: pas...@li...
> [mailto:pas...@li...] On Behalf Of
> Steffen Ryll
> Sent: Friday, February 23, 2007 12:17 AM
> To: pas...@li...
> Subject: [Passwordsafe-devel] Concerns with use of security enhanced
> stringfunctions
> 
> Hi,
> 
> recently I decided to dedicate myself to helping with porting pwsafe to
> PocketPC.
> So far, I managed to configure the build environment correctly (at least
> I hope it is) for PocketPC compilation. The trouble is now, that only in
> the corelib project 244 compile errors are raised, much of them
> referring to security enhanced string functions introduced with CRT 8.0/
> VS2005 (e.g. _stprintf_s is used instead of _stprintf earlier).
> Though these function calls are in #ifdef blocks testing for VS2005 or
> newer, this doesn't seem to be good enough. I suppose, these new
> functions are available only in the native Win32 C library, not in the
> PocketPC versions.
> 
> Additionally, there seem to be backwards compatibility issues with some
> of these functions. According to, for instance
> http://msdn2.microsoft.com/en-us/library/ce3zzk1k(VS.80).aspx ,
> _stprintf_s is identical to swprintf_s, but this is not supported by Win9x.
> 
> Thus, I want to raise the question, whether it is a good idea to make
> use of these security enhanced functions, in our opinion.
> I can see two possible solutions for that:
> 
> 1. Leave these new functions aside and stick to ANSI C string operations.
> 
> 2. Use the new functions where ever possible. To improve code then, the
> differentiation between old and new functions should be encapsulated in
> one class. On the other hand, this wouldn't solve backwards
> compatibility issues.
> 
> I'm personally more in favour of the first approach, because it makes
> porting to other platforms and OSs easier.
> 
> 
> One point concerning the port the PocketPC: Don't expect so much
> progress soon, as I'm not so much familiar with C++ and with pwsafe's
> source code. This forces to read a lot first :-)
> However, I'm planning to post a few questions and ideas soon, continuing
> the discussion Robert Altmann kicked off last year. But I'm not ready
> with these yet.
> 
> 
> Any comments?
> 
> Cheers,
> 
> Steffen
> 

Re: [Passwordsafe-devel] Concerns with use of security enhanced stringfunctions

[Rony S. <ro...@gm...>]

 Hi,

Using the _s versions of library functions seems to me a Good Thing, not so
much because they're inherenly more secure (in the  PasswordSafe's threat
model, buffer overflows, say, in strcpy, aren't really a vulnerability so
much as a bug) - rather, they help eliminate classes of bugs by changing the
interface.

Therefore, I think they should be used where possible. It would be nice to
have some wrappers around them, though, to eliminate the #ifdefs sprinkled
throughout the code...

   Cheers,

          Rony

-----Original Message-----
From: pas...@li...
[mailto:pas...@li...] On Behalf Of
Steffen Ryll
Sent: Friday, February 23, 2007 12:17 AM
To: pas...@li...
Subject: [Passwordsafe-devel] Concerns with use of security enhanced
stringfunctions

Hi,

recently I decided to dedicate myself to helping with porting pwsafe to
PocketPC.
So far, I managed to configure the build environment correctly (at least
I hope it is) for PocketPC compilation. The trouble is now, that only in
the corelib project 244 compile errors are raised, much of them
referring to security enhanced string functions introduced with CRT 8.0/
VS2005 (e.g. _stprintf_s is used instead of _stprintf earlier).
Though these function calls are in #ifdef blocks testing for VS2005 or
newer, this doesn't seem to be good enough. I suppose, these new
functions are available only in the native Win32 C library, not in the
PocketPC versions.

Additionally, there seem to be backwards compatibility issues with some
of these functions. According to, for instance
http://msdn2.microsoft.com/en-us/library/ce3zzk1k(VS.80).aspx ,
_stprintf_s is identical to swprintf_s, but this is not supported by Win9x.

Thus, I want to raise the question, whether it is a good idea to make
use of these security enhanced functions, in our opinion.
I can see two possible solutions for that:

1. Leave these new functions aside and stick to ANSI C string operations.

2. Use the new functions where ever possible. To improve code then, the
differentiation between old and new functions should be encapsulated in
one class. On the other hand, this wouldn't solve backwards
compatibility issues.

I'm personally more in favour of the first approach, because it makes
porting to other platforms and OSs easier.


One point concerning the port the PocketPC: Don't expect so much
progress soon, as I'm not so much familiar with C++ and with pwsafe's
source code. This forces to read a lot first :-)
However, I'm planning to post a few questions and ideas soon, continuing
the discussion Robert Altmann kicked off last year. But I'm not ready
with these yet.


Any comments?

Cheers,

Steffen

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Passwordsafe-devel mailing list
Pas...@li...
https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel

[Passwordsafe-devel] Concerns with use of security enhanced string functions

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

Hi,

recently I decided to dedicate myself to helping with porting pwsafe to
PocketPC.
So far, I managed to configure the build environment correctly (at least
I hope it is) for PocketPC compilation. The trouble is now, that only in
the corelib project 244 compile errors are raised, much of them
referring to security enhanced string functions introduced with CRT 8.0/
VS2005 (e.g. _stprintf_s is used instead of _stprintf earlier).
Though these function calls are in #ifdef blocks testing for VS2005 or
newer, this doesn't seem to be good enough. I suppose, these new
functions are available only in the native Win32 C library, not in the
PocketPC versions.

Additionally, there seem to be backwards compatibility issues with some
of these functions. According to, for instance
http://msdn2.microsoft.com/en-us/library/ce3zzk1k(VS.80).aspx ,
_stprintf_s is identical to swprintf_s, but this is not supported by Win9x.

Thus, I want to raise the question, whether it is a good idea to make
use of these security enhanced functions, in our opinion.
I can see two possible solutions for that:

1. Leave these new functions aside and stick to ANSI C string operations.

2. Use the new functions where ever possible. To improve code then, the
differentiation between old and new functions should be encapsulated in
one class. On the other hand, this wouldn't solve backwards
compatibility issues.

I'm personally more in favour of the first approach, because it makes
porting to other platforms and OSs easier.


One point concerning the port the PocketPC: Don't expect so much
progress soon, as I'm not so much familiar with C++ and with pwsafe's
source code. This forces to read a lot first :-)
However, I'm planning to post a few questions and ideas soon, continuing
the discussion Robert Altmann kicked off last year. But I'm not ready
with these yet.


Any comments?

Cheers,

Steffen

Re: [Passwordsafe-devel] PKCS11 Smartcard Support

[Rony S. <ro...@gm...>]

Hm,

Interesting project.

Having a separate file seems the most elegant way to go. The existence of
the file could be the hint for pwsafe to use the token for authentication,
instead of deriving the key from the passphrase & salt. Alternately, a
"special" salt value could be the trigger to look for such a file...

In terms of the formatv3.txt document, the smartcard's private key would
decrypt P'. Once the application has a value for P', processing should
continue as before (calculate H(P') to verify the key's correctness, decrypt
K and L, etc.).
In the corelib code, I think the best approach would be to create and
overloaded version of PWSfileV3::CheckPassword() that takes the relevant
parameters and calculates P'. Note that the GUI code that accepts passwords
also needs to be modified. Of course, the issue of generating the file with
the encrypted key also needs to be addressed.

I'd like to see this in a branch off the main code trunk, to start with.
Once it's working, we can consider how to merge it into the main project.

	Rony

-----Original Message-----
From: pas...@li...
[mailto:pas...@li...] On Behalf Of John
Conneely
Sent: Sunday, February 18, 2007 1:14 AM
To: pas...@li...
Subject: Re: [Passwordsafe-devel] PKCS11 Smartcard Support

Doh!  GMail sent my mail before I was done.  As I was saying, if we
were to build PKCS#11 support into the password safe GUI, I think it
would require storing the following additional data elements with the
password file:

1) A reference to the PKCS#11 DLL you want to use.
2) Information on locating the private key on the smartcard.
3) The symmetric encryption key encrypted with the public key that
corresponded to the one on the smartcard.

Alternatively I could store these in a separate file so as to not
touch the file format of the existing document.  This might simplify
development because it would allow the user to modify the document
themselves instead of having a GUI to manage entry of that
information.

I'm also interested in where you guys think the proper place is for me
to patch the app for smart card support.  I'm currently looking in the
PWSFile.cpp to see if there's a central place I might be able to hook
in my code with as little changes to the existing functionality as
possible.

Thanks!

John


On 2/17/07, John Conneely <jo...@gm...> wrote:
> I've got an EToken NG flash that I'm using opensc with, and I'd love
> to use a private key on the token to decrypt my password file.  This
> device is a smartcard and a USB flash drive in one device.  I'd love
> to put password safe and my password file on it in such a way that it
> would be difficult for someone to use a key logger to gain access to
> my encryption key.
>
> So, unless someone else has plans to do it (which would make me very,
> very happy) I'd like to implement PKCS#11 support for password safe.
> If I do this, is there interest in including it in your product?
>
> If so (and even if there is no interest) where do you think the best
> architecture to use?  When using PKCS#11, I would want password safe
> to ask for the smartcard's PIN, and store that in memory.  I would set
> the timeouts for locking the app to be somewhat aggressive, but
> unlocking the app would be transparent provided the smartcard was
> still present.  When using a smart card, the encryption key would be
> chosen randomly and then encrypted with the public key of a
> certificate stored on the smart card and storred with the database.
>
> If we were to build PKCS#11 support into the password safe GUI, it
> would require storing the following additional data elements with the
> password file:
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Passwordsafe-devel mailing list
Pas...@li...
https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel

Re: [Passwordsafe-devel] PKCS11 Smartcard Support

[John C. <jo...@gm...>]

Doh!  GMail sent my mail before I was done.  As I was saying, if we
were to build PKCS#11 support into the password safe GUI, I think it
would require storing the following additional data elements with the
password file:

1) A reference to the PKCS#11 DLL you want to use.
2) Information on locating the private key on the smartcard.
3) The symmetric encryption key encrypted with the public key that
corresponded to the one on the smartcard.

Alternatively I could store these in a separate file so as to not
touch the file format of the existing document.  This might simplify
development because it would allow the user to modify the document
themselves instead of having a GUI to manage entry of that
information.

I'm also interested in where you guys think the proper place is for me
to patch the app for smart card support.  I'm currently looking in the
PWSFile.cpp to see if there's a central place I might be able to hook
in my code with as little changes to the existing functionality as
possible.

Thanks!

John


On 2/17/07, John Conneely <jo...@gm...> wrote:
> I've got an EToken NG flash that I'm using opensc with, and I'd love
> to use a private key on the token to decrypt my password file.  This
> device is a smartcard and a USB flash drive in one device.  I'd love
> to put password safe and my password file on it in such a way that it
> would be difficult for someone to use a key logger to gain access to
> my encryption key.
>
> So, unless someone else has plans to do it (which would make me very,
> very happy) I'd like to implement PKCS#11 support for password safe.
> If I do this, is there interest in including it in your product?
>
> If so (and even if there is no interest) where do you think the best
> architecture to use?  When using PKCS#11, I would want password safe
> to ask for the smartcard's PIN, and store that in memory.  I would set
> the timeouts for locking the app to be somewhat aggressive, but
> unlocking the app would be transparent provided the smartcard was
> still present.  When using a smart card, the encryption key would be
> chosen randomly and then encrypted with the public key of a
> certificate stored on the smart card and storred with the database.
>
> If we were to build PKCS#11 support into the password safe GUI, it
> would require storing the following additional data elements with the
> password file:
>

[Passwordsafe-devel] PKCS11 Smartcard Support

[John C. <jo...@gm...>]

I've got an EToken NG flash that I'm using opensc with, and I'd love
to use a private key on the token to decrypt my password file.  This
device is a smartcard and a USB flash drive in one device.  I'd love
to put password safe and my password file on it in such a way that it
would be difficult for someone to use a key logger to gain access to
my encryption key.

So, unless someone else has plans to do it (which would make me very,
very happy) I'd like to implement PKCS#11 support for password safe.
If I do this, is there interest in including it in your product?

If so (and even if there is no interest) where do you think the best
architecture to use?  When using PKCS#11, I would want password safe
to ask for the smartcard's PIN, and store that in memory.  I would set
the timeouts for locking the app to be somewhat aggressive, but
unlocking the app would be transparent provided the smartcard was
still present.  When using a smart card, the encryption key would be
chosen randomly and then encrypted with the public key of a
certificate stored on the smart card and storred with the database.

If we were to build PKCS#11 support into the password safe GUI, it
would require storing the following additional data elements with the
password file:

[Passwordsafe-devel] Announcing PasswordSafe 3.06

[Rony S. <ro...@gm...>]

Hi,

This is to announce the release of PasswordSafe version 3.06.

Version 3.06 is a minor release - some annoying bugs have been fixed, some
features have been improved upon.
Thanks to DK and Arjun for their work on this release, as well as to the
brave U3 beta testers: Jan, Juergen, Larry and Sid (apologies if I left
anyone out).

The U3 version will be available soon from http://software.u3.com.

New Features for 3.06
=====================
Support for U3 (disk-on-key).

Changes to Existing Features in 3.06
====================================
[] Opening dialog now shows recently opened databases in dropdown list.
[] File opened in initial dialog now added to recent files list.
[1634251] Password expiration date can now be specified relatively, e.g.,
"45 days from now".
[] All dates and times are now displayed in the local format.

Bugs fixed in 3.06
==================
[1625557] No longer crashes when invoking help after using Hot-Key.
[1633516] No longer crashes upon Find with an empty group.
[] Configuration handled correctly with non-English user or host names.
[] No longer crashes when password history policy changes records.
[] Non-English data issues resolved.


The release may be downloaded from 
https://sourceforge.net/project/showfiles.php?group_id=41019&package_id=3316
9&release_id=486669
http://preview.tinyurl.com/2ee5qb

SHA-1 checksums:  
b003a0801d247794beb17960799ba90b2ea71163 pwsafe-3.06.exe
f39450e1d85fee453f208f4fd1312074c2862e40 pwsafe-3.06-bin.zip
6c8ed71c28d518d615507e16a4124e09a101f15f pwsafe-3.06-src.zip

Note that this release also includes PGP/GPG signature files of the
respective packages. These were signed with my SourceForge account key,
keyid FA175557, key fingerprint = FF77 379D D46D DAA6 6182   B452 1D79 5A91
FA17 5557, available from a PGP keyserver near you (such as
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFA175557).
 
         Enjoy,
 
                 Rony

[Passwordsafe-devel] Java PasswordSafeSWT 0.6 Released

[Rony S. <ro...@gm...>]

Hi,

Glen and guys on the Java port are pleased to present PasswordSafeSWT 0.6
for download. While still needing to catchup some important UI changes, this
significant release adds v3.0 file format support, Mac Universal binary
support, and much broader support for various Linux display managers. 
Many thanks to Neil Greenwood for some nice work on the Tree layout, and to
Jim Kalafut for providing lots of testing assistance for the new v3 file
format.

You can download it from
https://sourceforge.net/project/showfiles.php?group_id=41019&package_id=1649
07&release_id=478850
(http://preview.tinyurl.com/ykr55q)

Note: The Java port is still beta, and mainly of interest to developers and
people who want to try PasswordSafe on non-Windows platforms. 

	Cheers,

		Rony

[Passwordsafe-devel] Announcing PasswordSafe 3.05.02

[Rony S. <ro...@gm...>]

Hi,

This is to announce the release of PasswordSafe version 3.05.02.

Version 3.05.02 is a maintenance release - some annoying bugs have been
fixed, no new features have been added.  

Bugs fixed in 3.05.02
=====================
[1606265, 1609291] No longer terminates after edit when username and/or
hostname starts with a digit.
[1609759] "Show Password in display list & tree" setting now persistent
across application exit.
[1608191] Tree view's state is now preserved across timed lock and when
starting with '-s' flag.
[1612881, 1577505] Notes now appear consistently.

The release may be downloaded from  
https://sourceforge.net/project/showfiles.php?group_id=41019&package_id=3316
9&release_id=472870  
(http://preview.tinyurl.com/y9awsk)  
 
SHA-1 checksums:  
75b2797157124089de4ce1cd1ac8e4bdd1ef4e85 pwsafe-3.05.02.exe 
b5581048cfdf03af3c16621c23ba878007516bca pwsafe-3.05.02-bin.zip 
780a86c901e4b89c370172ba4e7f73c6c7994728 pwsafe-3.05.02-src.zip 
Note that this release also includes PGP/GPG signature files of the
respective packages. These were signed with my SourceForge account key,
keyid FA175557, key fingerprint = FF77 379D D46D DAA6 6182   B452 1D79 5A91
FA17 5557, available from a PGP keyserver near you (such as
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFA175557).
 
         Enjoy,
 
                 Rony

[Passwordsafe-devel] PasswordSafe 3.05.02 pre-release

[Rony S. <ro...@gm...>]

Hi,

Since the last couple of releases had a few annoying problems, I've decided
to pre-release new versions to subscribers of the passwordsafe-users mailing
list. If you're not interested in trying out pre-releases, just unsubscribe
from this mailing list.
(passwordsafe-announce is the list where formal releases are announced.)

PasswordSafe 3.05.02 fixes some of the problems that came up with 3.05,
specifically:

[1606265, 1609291] No longer terminates after edit when username and/or
hostname starts with a digit.
[1609759] "Show Password in display list & tree" setting now persistent
across application exit.
[1608191] Tree view's state is now preserved across timed lock and when
starting with '-s' flag.
[1612881, 1577505] Notes now appear consistently.

No new features have been added.

If you wish to try this release, you may find it in:
http://passwordsafe.sf.net/tmp/pwsafe-3.05.02-bin.zip (zipped executables)
or
http://passwordsafe.sf.net/tmp/pwsafe-3.05.02.exe (installer)

sha1 hash values are:
75b2797157124089de4ce1cd1ac8e4bdd1ef4e85 pwsafe-3.05.02.exe
b5581048cfdf03af3c16621c23ba878007516bca pwsafe-3.05.02-bin.zip

Please drop me a note if you've any problem with this release. If all goes
well, I'll release it "formally" in a few days.

	Cheers,

		Rony

[Passwordsafe-devel] PasswordSafe 3.05 re-release

[Rony S. <ro...@gm...>]

Hi,

PasswordSafe 3.05 was the first release built with a new development
environment. As such, there were a couple of mistakes that were made that
caused the installation to fail for some users.

This re-release of PasswordSafe 3.05 fixes those mistakes, and a couple of
other minor bugs that have crept in. No new functionality has been added.

Specifically, the bugs fixed in this re-release are:
[1606026] Missing manifest files added, application no longer requires
vcredist_x86.exe
[1606237, 1606232] View preferences now work correctly
[1605389] Read-only flag now updated correctly

Thanks to all the users who have reported the bugs in a constructive manner,
and helped track down the causes rather quickly.
HUGE thanks to DK, who has put in long hours searching for workarounds,
fixes, and general moral support.

In order to try to avoid repeating re-releasing, I'm going to change the
release procedure a bit: Starting with the next release, I will pre-announce
the release on the passwordsafe-users mailing list. Folks who are interested
in testing the release are encouraged to do so. Once the release has been
pre-tested, I'll make it into a "formal" release and announce it on
passwordsafe-announce as well.

The release may be downloaded from:
https://sourceforge.net/project/showfiles.php?group_id=41019&package_id=3316
9&release_id=467694
(http://preview.tinyurl.com/yzgcvq)

SHA-1 checksums:
789d57dbd87d32f7f5f9700c94cdb30572416d8e pwsafe-3.05.exe
2a80979383243e5b28c34890e4724599815f33d7 pwsafe-3.05-bin.zip
f2c99469722375db05ffc24af135e7c7937129d8 pwsafe-3.05-src.zip

Note that this release also includes PGP/GPG signature files of the
respective packages. These were signed with my SourceForge account key,
keyid FA175557, key fingerprint = FF77 379D D46D DAA6 6182   B452 1D79 5A91
FA17 5557, available from a PGP keyserver near you (such as
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFA175557).
 
         Enjoy,
 
                 Rony

[Passwordsafe-devel] PasswordSafe 3.05

[Rony S. <ro...@gm...>]

Hi,

It seems that some folks are having trouble running PasswordSafe 3.05.

The reason is that we switched to a newer version of Microsoft's development
environment, and apparently didn't set up the runtime redistributables
correctly.

Until we fix this, you can workaround this by downloading (for free) and
installing Microsoft's latest runtime environment from
http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-
9C99-220B62A191EE&displaylang=en
(http://preview.tinyurl.com/odssp)

Sorry about the inconvenience.

	Rony

Re: [Passwordsafe-devel] Announcing PasswordSafe 3.05

[Jeff G. <jef...@gm...>]

Hi Rony,

I'm not sure if you are going to have lots of users contacting you but
I can't get the latest 3.05 build of PasswordSafe to run on my WinXP
SP2 machine.  I originally tried the .ZIP file but when I run the
pwsafe.exe I get the "This application has failed to start because the
application configuration is incorrect.  Reinstalling the application
may fix this problem."

So at first I thought it might be because the new VS2005 DLLs were not
registered but if I use the 2.05 .exe version that installs the
software for either a "Regular" or  "Green" system I get the same
thing, the executable won't run.

I haven't been able to find a way to get it to run on my system at all.

Jeff.