Entry attribute references are case sensitive and break compatibility with KeePass

[UsefulVid]

Problem is that I migrated from KeePass to KeePassXC and now all auto type references are broken due to the case sensitivity
Creating 2 different entries in advanced works in KeepassXC:

In KeePass it is blocked:

Works:

Does not work:

[famx-droid]

So the task is making the additional attributes case insensitiv to be compatible with keepass imports? This can lead some new issues with existing auto-type entrys, if used like in the picture above (e.g. IP, ip).

[UsefulVid]

This can lead some new issues with existing auto-type entrys, if used like in the picture above

I can't follow you. In the picture above the issue is the case sensitivity. Can you please explain in which circumstances it produces issues? And are these issues so serious that its worth breaking compatibility with keepass?

[famx-droid]

If keepassxc users have attributes that are case sensitive (such as IP and ip), problems could arise.
My personal opinion is that the compatibility with keepass outweighs. I don't want to decide which weight is more important, hence my question.

[droidmonkey]

There is no easy solution to this problem. I suspect that there are a very small minority of people who have attributes that differ by case only. However, when that occurs the transition from case-sensitive to non sensitive will be tricky. We will have to ask users which attribute they want to keep.

[UsefulVid]

Why should anybody use this? I can not imagine a use case for that. Would an easy solution be to set it to case insensitive for newly created databases and for already existing ones set it to sensitive. In my case I would just had to change the option to insensitive and users who use it can leave it as it is.

[droidmonkey]

Not sure what you mean. If we want to follow what KeePass is doing, ie being case insensitive, then we would have to transition databases. It is inefficient and confusing to support two different modes of operation. The example you provided sums it up perfectly and what I am going off of.

[UsefulVid]

Transition the database? Are you sure? I am coming from KeePass and while opening the database from KeePass into KeePassxc I discovered the issue. Does not look like a different database formating. It looks like a different treatment in KeePassxc. My suggestion was to change the treatment not the database format.

[droidmonkey]

What I meant was: if we no longer allow case sensitive attributes (like KeePass) then we will have to merge all existing attributes that had the same name but different case. Don't worry about the details, that is what we are here for.

[math-alpha]

Hello @droidmonkey
I am interested in working on this issue. From the chats, it wasn't clear which strategy to use. Could you or anyone please enlighten me more?
Thanks

[pepa65]

It's good to keep compatibility with KeePass going forward, no longer allowing entries that only differ in case.

But for existing databases in KeePassXC where there is a case of double entries, I don't think plain merging is the solution. You either just leave the pairs (or triplets, or...) in case they are there, and then that particular database is incompatible with KeePass (possibly not a big issue for that user). Or, you go fixing 'invalid' databases by renaming any item that already has an entry, perhaps by adding a character (perhaps underscore?) to the name until that name is unique.

[droidmonkey]

The problem is KeePass KDBX does not prescribe a "standard" for this and the only prevention was GUI-based (ie, find same name ignoring case, don't allow addition). I like the idea of just adding the GUI-based protection for new and renamed attributes and leaving everything else as-is.