KeePass 2 / Mono

[debfx]

As you might know KeePass 2 runs on Mono, so you can use it on Linux/Mac.
The question for the future of KeePassX is this:
Are we going to support the KeePass 2 database format in KeePassX or are we going to discontinue KeePassX and help the KeePass developer to integrate KeePass 2 on Linux / Mac OS?

Have you experience running KeePass 2 on Mono?
What are your thoughts about Mono in general?

[jusic]

Here are my random observations and views about KeePass 2 on a Mac, and the project future:

First, some notes about the KeePass 2 on Mac that I tested today (20090317):

* Don't take my word for it, see it yourself: An step-by-step guide how to get KeePass Portable (works for version 2.07 too) running on the latest Mono release.


Cons:

- In order to run KeePass 2 on Mac, you need to download and install the Mono Framework, which is quite big (download size ~100MB, install size ~300MB). This of course is not a problem if there is a lot of programs using the same framework (think Java) so eventually it may become a standard component everywhere.

- Mono for Mac OS X download page lists that Gtk# and System.Windows.Forms (essential GUI libraries) require X11 currently as a dependency, so the Mono's graphical system will not work without it.

I don't know if this is a problem, because quite a few programs use X11 on Mac, so by default it's usually installed (I'm not sure if it's even part of the default OS X install, someone can educate me on this).

However, they say that "We do not use X11 for anything but font rendering", so this dependency might even go away in the future, essentially making the problem disappear.

- Currently, the GUI has drawing/behaviour bugs, screen updates are noticeably slow and the components are non-native (one could even say ugly). Even the menu bar is in the window, not where 'it should be' in the Mac.

- Currently, even the clipboard copy-paste doesn't work, this might be a limitation in the current version of Mono on OS X.

This is of course the current situation, and it surely will improve in the future. As the KeePass author himself notes:

(...) As stated above already, KeePass 2.x was never intended to be run today. (...)

(This should not be taken too literally. KeePass 2.x is very good piece of software and useable on Windows environments right away, if you have .NET installed. I personally use it.)


Pros:

+ Portable code, same code runs everywhere.

+ .NET Framework seems to have good security classes for e.g. keeping the plain text in-memory data secure (if you can trust the implementation, and of course you can roll your own). (Btw, Java lacks this support completely.)

+ KeePass 2.07 seems to reasonably stable on Mac/Mono at least in normal casual use (open database, look for an entry).

+ Improvements made to Mono would help an increasing number of people create portable software on it.


My current conclusion:

I don't think that KeePassX project should be axed now, because it is a software that is intended to be used today, not tomorrow. This is true especially on Linux and Mac environments where it is, in my opinion, one of the best solutions available that just work (tm).

However, there are numerous pitfalls within keeping the project alive. I believe that the biggest problems are currently the code base and the lack of documentation. I think this seriously attacks the vital 'fun factor' of an open source project.

My suggestion is that we begin carefully dismantle, clean up and eventually replace the existing implementation in a bottom-up manner -- keeping the good bits and replacing the bad with better. This is not an easy task, but it must be done and it can be done in small steps so that it won't choke the project.

Ultimately I suggest planning the rewrite in a manner that facilitates a) ~frequent releases b) small feature additions during the rewrite c) big new features in the end of the rewrite (like my pet wish, reliable synchronization of databases between multiple computers, cross-platform). I also dare to suggest that, despite the KeePass-name, we could design and implement (of course reuse knowledge/code as much as reasonably possible) a database format that would be reusable, flexible, facilitate new features more easily and that could be implemented in small functional steps (in the case KeePass 2.x format isn't like this). (Maybe some wild ideas: Sqllite with encrypted content?)

Good thing is, that there are (currently) two brave souls that are keeping the gears going and there is continuing interest for the software so far. In addition, there have been several developers in the past that have been able to pass on the development responsibility and making of course their excellent contribution to the project.

Now I would love to hear others' views and feedback about this.

Thanks if you really read the conclusion part this far. Appreciate it.
--jussi

Btw, there has been already some discussion earlier in this Thoughts on KeePass 2.0 topic.

[Boris_Brodski]

Hello!

If I may express my opinion, I wouldn't trust .NET technology in the security matter so much. Pure C++ implementation of such sensitive things as 'Password Safe' is very important. So I think, we should continue developing KeePassX and I am willing to help.

I would suggest following priorities:
- Additional support for KeePass 2.0 database format, so you can open both database formats.
- Split the package in 'keepassx' and 'keepassx-dev', so we can offer other projects access to databases through C++ interface.

[debfx]

- Additional support for KeePass 2.0 database format, so you can open both database formats.

We can't support both database formats at the same time. We can only switch to KeePass2 and provide import/export methods for KeePass1 databases.

- Split the package in 'keepassx' and 'keepassx-dev', so we can offer other projects access to databases through C++ interface.

Yeah we could do that, but the c++ interface would still require Qt. So I'm not sure if it's that useful.

+ .NET Framework seems to have good security classes for e.g. keeping the plain text in-memory data secure (if you can trust the implementation, and of course you can roll your own). (Btw, Java lacks this support completely.)

Afaik that's only implemented on Windows >= 2000.

[Boris_Brodski]

We can't support both database formats at the same time. We can only switch to KeePass2 and provide import/export methods for KeePass1 databases.

Ok, so we will provide support for both KeePassX 1.x and KeePassX 2.x? I can imagine, that many people will continue to use KeePass 1.X (think about mobile versions of KeePass. They support mostly KeePass 1.x database format)

- Split the package in 'keepassx' and 'keepassx-dev', so we can offer other projects access to databases through C++ interface.

Yeah we could do that, but the c++ interface would still require Qt. So I'm not sure if it's that useful.

I think, we could offer a clean c++ library to access KeePass 2.x database and than wrap it with Qt for our purposes.
- Many developers could use our library to write KeePass clients for mobile devices, such as PocketPC or iPhone.
- Other open source software could support KeePass databases to pick up authentication information: Putty, Firefox, ...
- We could offer bindings (wrapper for keepassx-dev library) for other languages, like java, ruby, ...

What do you think?

[jusic]

I think, we could offer a clean c++ library to access KeePass 2.x database and than wrap it with Qt for our purposes.
- Many developers could use our library to write KeePass clients for mobile devices, such as PocketPC or iPhone.
- Other open source software could support KeePass databases to pick up authentication information: Putty, Firefox, ...
- We could offer bindings (wrapper for keepassx-dev library) for other languages, like java, ruby, ...

What do you think?

I find the idea of separate, clean database libraries very good and interesting. That would emphasize the separation between the GUI stuff and the database engine stuff, and would facilitate reuse of the GUI (which I find to be very good from the user point of view). And of course, that would also facilitate reuse of the database code by others.

Could we start the effort with current KeePass 1.x database code (although it is quite messy) and try to wrap it into a library?

In my vision, after that we could have something like:
- KeePassX - the user interface and OS integration code.
- libKeePass1DB - the database code for KeePass 1.x. (I changed the naming of keepassx-dev to something more descriptive)

And then we could start:
- libKeePass2DB - a new project for supporting KeePass 2.x databases.

(Of course, if the 1.x and 2.x databases are similar enough, one common library could suffice, but that would mean that we should rewrite the 1.x database code too.)

We could gain knowledge for the database library API from the KeePass 1.x library port and build the KeePass 2.x support by relying on that knowledge (and improve the API where we see it fit).

The initial KeePass 1.x database code library port would allow us to keep using it in 'production releases' until the KeePass 2.x support is good enough for the common usage. Furthermore, a clean DB API would nicely play along with a unit testing framework.

SniperBeamer, what is your view on this?

(update) PS. As you may have noted, I'm not too interested in the KeePass 2.x format support, as it seems to be too similar to the 1.x format (difficult to synchronize and interface). Here is a format to think about: https://kb.agile.ws/wiki/agile/AgileKeychainDesign (Used by commercial Mac software called 1Password). It plays quite nicely with file system level synchronization utilities and is quite simple to understand and implement.

[Boris_Brodski]

Here is a part of viewtopic.php?f=2&t=1732 post:

I found the AgileKeychainDesign is very interesting! Very nice Design

I thought, perhaps we could develop a library, that support many different password store formats (like plugins). The idea is to design an interface in a such way, that we can provide access to many different password store formats. We could provide interface methods to discover current format features, for example:

bool supportAttachements();
bool supportCustomProperties();
bool supportKeyFile();
bool supportManyKeyFiles();
...

Then we can write a Qt-GUI, that first checks, if a feature supported by current format, and only then add it to popup menu or task bar.
(I hope you know, was i mean )

I would suggest to use plain c++ (with cryptolib or openssl dependency only) using GNU Build Tools (autoconf/automake) ?
Also I would avoid usage of direct I/O to allow using this library to open a database directly from (S)FTP, Network, Memory FS ....

What do you think about that?

PS
Shouldn't we start a new thread for this discussion?

[pano]

I beg you, to not start "supporting" mono on linux but focus on "your" Verison.
Apart from Mono being evil I wouldn't want to install such a big "thing" just for one app, even if the app is really great

thanks

[russ]

I would be interested in helping develop keepassX. Where should I start?

[macmacken]

I found the AgileKeychainDesign is very interesting! Very nice Design

Great design with a major flaw – not all data is encrypted, only data considered confidential. A major advantage of KeePassX is the full encryption of all data.

Martin

[fabianp]

Hi everyone,

I just registered in the forum just to leave my opinion on this issue

I think portability is the most important attribute of an application like KeePassX and that's the main reason why I use it.

Although most of the time I use Linux, very often I also need to access my passwords from Windows and sometimes also from a Mac.

I understand that .NET may be rather common in most modern Windows PCs, but that's not the case with Linux and I doubt it will, but that's beside the point (I've been using Linux for over 15 years and I have absolutely no plans to install Mono).

Everyday I deal with Windows and Linux systems without .NET/Mono and I just can not (and sometimes do not have the necessary permissions to) download and install a huge framework just to run a small program from my USB stick.

I think the spirit of KeePass is to be and remain a simple and small cross-platform program that allows its users to safely access their passwords from anywhere, without depending on any additional software. We do not need the latest in database technologies or application frameworks for such a simple utility program.

If KeePassX is discontinued in favor of KeePassX-2, unfortunately I will have to stick to the older version or step back and return to use PasswordSafe/Password Gorilla.

My two cents. Thank you,

[Tommy_B]

well put fabianp. Reading your post reminded me of one of the main reasons I switched over to KeePassX, aside from cross-platform compatibility, and that's its simplicity which shows not only in the user interface but also in it's memory consumption relative to other password managers. I was on a G5 PPC with stock 512mb of RAM and every other password program at the time would grind my machine to a crawl, some of them hogging up a shameful 80-90 mb of RAM. With KeePassX in it's current iteration, on my Mac it sips a humble 20 mb or so (I just looked at System Monitor in LinuxMint - 11mb there, very nice).

Why fix what isn't broken?

[wilroz]

I just registered to ask, because I can't find any updated information on this matter:

What is the current status on kdbx support on KeePassX? Is this something that is worked on or have you simply decided not to support it?

From what I can tell in this thread, people seem pretty united in that they don't want to have to install Mono just to run KeePass and would rather see native support for 2.x databases in KeePassX.

Any response from an admin or someone who is updated on the subject would be cool.

/wilroz

[jamosmith]

I am also interested in finding out the status of kdbx support. How difficult is it to implement? Is this a feature that needs to be sponsored?

[debfx]

I'm working on a complete rewrite of KeePassX that will support kdbx.
Don't expect a release soon as I just started it.