Notices

That is great news! it will be great to be able to run the program on both desktop and N900 and still sync them (however that may be done: rsync, Unison, copy, etc).

May I add another suggestion?

Make it possible to do 3-way comparisons among pySafe databases. This feature should be triggered by the CLI. The 3 files to be compared are: base-file, file1-changed-from-base and file2-changed from base. This feature alone would revolutionize password programs. Here is the typical use case:

• The user adds some entries to her N900 pySafe db;
• The user makes some changes to her Desktop version of PySafe, forgetting to first copy the db from the N900;
• Some days later, the user uses Unison to synchronize many files between N900 and Desktop (example: music, pictures, videos, documents and the pySafe db).
• Unison notices that the pySafe db was edited on both places and so one version cannot overwrite the other without the user losing data.
• Because pySafe supports 3-way merge at the command line invocation, Unison calls "pySafe old-base-common.db desktop-db N900-db". Note: old-base-common is the last common version tracked by Unison that was equal on both devices.
• PySafe now asks for the passwords and displays a side by side comparison of differences between "desktop-db" and "N900-db". it can even merge things automatically, if there are no conflicting changes.
• The user taps the lists, indicating what changes are kept;
• PySafe then saves the results as the true merged file.
• Unison replicates the same new version on both devices
• The user lives happily forever, knowing that whatever and whenever she changes her pySafe db she will be sure that no changes will be lost.

Just wanted to say many thanks to Jaguilar for creating this program, it's excellent.

Can you release a technical document of the database format?

I was thinking of taking a shot to create a sync application for syncing between keepass and pySafe. I already did something simular for keyring (on Palmos): http://www.robvonk.com/projects-engl...passtokeyring/

I understand that you use blowfish and some compression but thats it. My Python skills are probably not good enough to figure out what you did.

@robbie

In the SCM section of the Garage you can checkout the sources and see how the file is read, in database.py file ("load" method).

But the file structure is very simple. To read, first you need to decompress, and after that decrypt. If the password is correct, the result will be a readable text:
1- the password is in the first line (for checking purposes only)
2- the second line is the version of the database (currently 2, but it will change soon)
3- third line is the MD5 checksum of the data
4- from the fourth line to the end is the data itself

Decompress is just gunzip i see. And my Delphi component knows how to handle blowfish so that shouldn't be a problem. I'll look into the file tomorrow.

thanks

I've managed to decrypt a small testfile but i see some strange things (see attached screenshot).

I have one group named 'Groep'
I have one item with two fields: Itemname, Pass
with the values Que and Quee

I see these items in the decrypted data but can't seem to make anything of the rest.

Any idea whats going on?

And again one step further. You're using pickle to save the data and Python adds these strange chars. I'm not sure if i can reproduce what they create.

What are your plans for version 3 of the data format? Any chance of change? And any chance of adding a last updated field per item? (so when you sync, you know what the last changed item is).

Yes....it's saved using pickle.

Unfortunately I have no intention of changing this, because Python does the data conversion (in other words: serialization) automatically. To change that I have to write a conversion routine, which would give a lot of work.

In the next version the only change for now, is the inclusion of one information on the details to say what should be the order of viewing them on screen.

There is no plan in changing this. My first priority is keep the program good enough to put it in the extras. After that I will start to think in synchronization.

And another step further. In the attachment you'll see the layout of the unencrypted data in hex format (length is decimal).

http://www.xs4all.nl/~gnista/dbformat.png

There are some things that i don't understand.

7D's are idents and 73 and 75's are unidents. Whats the difference? when to use which?

What are these 28's?

Anyone an idea?

Here is a Polish translation - PM me when more text strings translatoions required - happy to contribute to this great app (ex-Handy Safe user with KeepassX that is too limited for my needs)