3.0.0-SNAPSHOT Major refactor and simplification

[jorabin]

Hot on the heels of 2.2.3-SNAPSHOT comes this release, 3.0.0-SNAPSHOT given the breaking changes to the API.
(In an earlier version of this announcement I called it 2.2.3-SNAPSHOT)

There's a saying in London You wait ages for a bus then two come along at once, and it seems that as a Londoner I am honouring our bus scheduling with KeePassJava2 releases.

The source is on branch v3 (sic) and Snapshot releases at Sonatype.

There were several objectives for this release.

1. Get rid of the complicated generics on the main Database classes. These once had a point but don't any longer.
2. Remove the Simple, JAXB and DOM implementations. As previously discussed they have served their time.
3. Refactor through to make extension easier. Removing the generics seems like a good time to make other breaking changes.

The API is not backwards compatible with 2.2 so refactoring will be needed to use it.

I'm thinking about what else to put in this release:

1. Tidying of tests and improved examples
2. Move to Java 11 baseline
3. Adopt JUnit 5
4. The world is your Oyster?

I'm looking for feedback on this and would welcome hearing from you in this discussion.

Many thanks

[giusvale-dev]

Hi Jo!
Thanks for the announcement!

The objectives 1 and 3 are not clear, and I think we can help you if you write some practical examples.

Objective 2 is a comprehensive choice. I agree with you.

I do not agree about java 11 because it is very old, new projects start with the newest java versions therefore I think the effort to migrate from the current java version to the newest version could be the same, and I think this is the better way, in this mode for few years you have the API compatible with the most recently java versions.

I think that you need to add some features that are present in KeePass but missing here (e.g., password generation).

For security features, I don't see the current version of KeePass, but the companies, projects and research begin to use the TPM to store confidential information like passwords, and I think it could be a good period to think an integration with the TPM (for supported hosts). It is a very challenging feature, but the way for security applications is clear.

For cryptographic algorithms used, we need to wait for the KeePass decision because this is a particular period. The NIST has started the standardization for post quantum cryptography (Kyber) that is not used in the KeePass project (we use only symmetric encryption), but we can't ignore this signal, and we need to look forward.

For now, these are my suggestions, and I'm waiting for clarifications about objectives 1 and 3.

Giuseppe

[jorabin]

Hi Giuseppe

Thanks for your comments.

Clarification:

1. In 2.x.x the Database interface looks like this, which is so complicated "even its mother could not love it":
   

   KeePassJava2/database/src/main/java/org/linguafranca/pwdb/Database.java

   Line 52 in 2c47bd7

   public interface Database <D extends Database<D, G, E, I>, G extends Group<D, G, E, I>, E extends Entry<D,G,E,I>, I extends Icon> {

That level of complexity is gone in version 3 for the more rational (and lovable, and pluggable ...):

KeePassJava2/database/src/main/java/org/linguafranca/pwdb/Database.java

Line 52 in 86ecc28

public interface Database {

3. It would be good to allow for simple provision of conforming implementations via SPI. e.g. you could implement a LastPass database interface.

Interesting point about Java 11. Between Java 11 and Java 17 there are some cool language features, but not many that I can see would make the KeePassJava2 code simpler, faster etc. Surely better to keep language compatibility with Java 11 and distribute JARs at that level, and if you want to compile for later versions, then be my guest?

Password generation: sure, that would be nice. Would love to review some proposal.

Re other security feature, TPM and so on. When KeePass adopted Argon2 it took a while for there to be Java implementations, and as we know Java is not great at being a language where you can hide secrets well. So, my thinking is that you probably would not choose Java in the first place if you were highly security conscious, and that the project should follow the lead of KeePass itself, and follow Java and so on regarding access to TPM and more comprehensive security,

As ever thanks for your thoughtful input. Please disagree!

Jo

[giusvale-dev]

Objectives 1 and 3 now are clear.

While for 1, I agree, this is not the same for objective 3.

I think adding SPI increases only the development difficulty.

Example:
JDBC -> There are several DB implementations, and at runtime, you need to choose the implementation used for your database and make sense using SPI.

Our situation is not the same, but we have a more static and simple situation, and in case anyone needs to update the database implementation, it could develop the interface implementation directly.

For java versions, you're right. Should not be problems.

For security considerations, I don't agree. Java can be used in a security context (think the Java Card), but you need to know the vulnerabilities to write the better implementation.

I hope you can find useful this feedback for the new version.

Have a great day,
Giuseppe