Development Status FAQ

First of all I apologize for all the confusion created by KeePass 2.x. Perhaps I should not have released 2.x so early. It was never intended that people rush to the 2.x tree. Maybe I should have distributed this development version to only a select set of users, rather than making it generally available. I thought it would be good to make 2.x public very early, so testers could suggest useful features and help to fix bugs.

This page is intended to clarify my intentions, to avoid future misunderstandings.

• Is KeePass 1.x a dead end?
• Why is KeePass 2.x being developed?
• Will KeePass 1.x continue to be enhanced with new features?
• Why has .NET been chosen as a framework for KeePass 2.x?
  • Security and Integration
  • Productivity
  • Portable and Cross-Platform
• Will there be a KeePass 2.x version that won't require the .NET framework?
• Should I switch to KeePass 2.x now?
• Should I switch to KeePass 2.x when it becomes production level?
• What are KeePass Classic and KeePass Professional?

  Is KeePass 1.x a dead end?

No. KeePass 1.x will continue to be supported indefinitely.

If you are using KeePass 1.x on an older system where KeePass 2.x doesn't run, simply continue using it. KeePass 1.x will still be supported for a long time.

  Why is KeePass 2.x being developed?

Looking at the user feature requests, it becomes obvious very soon that a complete rewrite of KeePass 1.x is required in order to implement the suggested things.

For example, the complete core of KeePass 1.x is based on the fixed fields as seen in the 'Edit Entry' window. Implementing custom strings fields in 1.x would require such a lot of work that you can also rewrite it completely from scratch. Other examples are support for real synchronization, improved auto-type system, real entry history, supporting more key sources for building the composite master key, multiple attachments per entry, database compression, better plugin system, etc.

  Will KeePass 1.x continue to be enhanced with new features?

Yes. However, KeePass 1.x will not support all the features that 2.x supports. The reason 2.x was created is that there simply are features that can't be implemented into 1.x with a reasonable amount of work (see above). For example, password generator improvements will be made in 1.x, but the entry history will only appear in 2.x.

  Why has .NET been chosen as a framework for KeePass 2.x?

When it was clear that a complete rewrite is required, we carefully thought about what language and framework to use. We chose .NET because of security and integration features, productivity, and portability.

  How does .NET improve security and integration?

While these seem to be achievable with all languages at first glance (in all modern programming languages you can implement AES/Rijndael), it turns out to be a real criteria. It for example is pretty hard to implement things like memory protection, auto-type, system-wide hot keys, etc. in Java. Of course, it is possible, but Java just isn't designed for that. Also, you'd need to install the Java runtime. There should be as few dependencies as possible (see portability).

.NET supports security features that simply are not available in other frameworks. For example, Code Access Security (CAS) allows protection of resources and operations on a level that currently can't be found in any other framework; in corporate environments, assembly signing allows trusting official KeePass versions only; etc.

  How does .NET improve productivity?

Up to the point of writing this document, there were 15 patches posted to the 'Patches' tracker since the start of the project on 2003-11-15, although the project was open source since the very first start. Additionally, some people sent me patches directly, making about 30 patches in total. 30 small patches in 3.5 years isn't that much. Basically I'm the only one working on the KeePass source code (this is just a fact, I'm not complaining about it). Therefore productivity definitively is a criteria.

What means productivity? Productivity means that you can implement features / fix bugs faster, while producing similar or even higher code quality. Let's have a look at an example: adding compression functionality. If you want to do this using unmanaged C++, you'd first need to search for a library to do that. After finding the very stable ZLib, you'll need to learn it. You'll write some wrapper class for it, handling all the raw buffer processing. In contrast, you can compress a stream in .NET using one line of code. Of course this doesn't mean that you can do "more" in .NET than you can in unmanaged non-.NET code (in terms of functionality). You could also write KeePass in pure assembler.

  How does .NET improve portability?

Yes, I dare to speak about portability. I know that in today's corporate environments .NET isn't available. I know that today you can't carry KeePass 2.x on USB sticks around and expect it to run everywhere... As stated above already, KeePass 2.x was never intended to be run today.

.NET isn't just another framework. It's the latest Windows programming technology in the Win32 => COM => .NET chain. Today there aren't that many .NET applications except in the business sector, but in 2-3 years when Windows Vista is the standard operating system, most new (!) applications will be written in .NET. Even in corporate environments .NET will be available (reason 1: .NET actually provides more security, see above; reason 2: if every second application doesn't run, you consequently think about installing .NET).

The portable / cross-platform future of .NET is very bright. It allows the same codebase to be used on completely unrelated systems, like Windows PCs, Smart Devices (PocketPC, Smartphone, see the KeePassSD project, which uses the current 2.x codebase already — and works!), and even other operating systems like Linux, Solaris and Mac OS X through open .NET runtimes like Mono. The Mono project is progressing very well and there's absolutely no doubt that it will soon support all functions required by KeePass 2.x. For most Linux systems, Mono is offered as a package; it's even already included in the GNOME ≥ 2.16 desktop.

  Will there be a KeePass 2.x version that won't require the .NET framework?

No. KeePass 2.x is written completely in C# using the .NET framework. No chance to make it independent of .NET.

  Should I switch to KeePass 2.x now?

No! KeePass 2.x is in Alpha phase. This means that it is unstable and not intended for daily usage.

Use the 1.x version.

  Should I switch to KeePass 2.x when it becomes production level?

If you'd like to take advantage of the unique features of 2.x, and if all your systems support .NET, then yes. Otherwise, just stay with 1.x.

  What are KeePass Classic and KeePass Professional?

During the whole development of 2.x (i.e. while there was no public alpha version available), it was called "KeePass Professional". The current 1.x version should be renamed to "KeePass Classic". This naming should emphasize that 2.x isn't simply the successor of 1.x. Shortly before the first alpha version was released, there were long discussions about the naming and we finally decided to call the new version "2.x".

This was done particularly with regard to future development. The naming was changed, but the intention remains the same: 2.x isn't the successor of 1.x and 1.x isn't dead.