Umlauts (UTF-8) characters in group and password names do not work

[hny-gd]

When trying to open a group that contains keys or subgroups with special characters in their names (e.g. '&', 'ü', 'ß'), keepass-mode shows the error message "Cannot display group xxx".

This error message disappears when the special characters are removed, keepass-mode can then open the group.

Using keepass-mode-20210110.630 from MELPA.

Thank you very much for the otherwise excellent tool!

[ifosch]

I guess that should be easy to reproduce, add test, and fix. I'm very time limited right now, but I'll try to fix this problem asap.

[ifosch]

I've tried with this same version, and it works well for me. Can you please include keepassxc-cli version?

[ifosch]

In my case:

❯ keepassxc-cli -v
2.6.2

[hny-gd]

$ keepassxc-cli -v
2.6.4

Nonetheless, I tested a bit further, and it seems more complicated than I initially thought. It does not seem to be related to UTF-8 as I thought but to something different. When I change into the group a second or third time, keepass-mode can open the group most of the times, even when I do not change anything in the file.

Maybe it is related to the size of the file (it is about 10M because it contains some attachments and emacs asks whether it should open the file in literal mode, which I never allow though).

I will test further and update when I find out something. I suggest I will open a new bug then?

[ifosch]

I don't see any need to open a new bug. I'd suggest you to keep this issue updated with your findings. In the meantime, I'll look for a way to test with this version of keepassxc-cli.

It might be useful to have a kdbx file with the same issue as a fixture. Could you provide me with a file with the same issue?

[ifosch]

I just tried to make a copy of my test Kdbx file bigger than 10M (I added a 55M file as an attachment to an entry.) When I added the attachment using KeepasXC, I got a warning about possible performance issues because of the file size.

Then I tried to open the entry using keepass-mode. This was slow but working fine..

[hny-gd]

Thanks a lot @ifosch for all the work, I will try to create a file with which this can be reproduced (don't know if I can as I have no idea what exactly is the problem yet...)

[ifosch]

I wonder if your database file is a compatible version and a valid cipher. Can you try the following command using the path for your database file, please?

❯ keepassxc-cli db-info tests/fixtures/test.kdbx 
Enter password to unlock tests/fixtures/test.kdbx: 
UUID: {f541ab2a-d619-3ba4-d48c-8b30c18e2d97}
Name: 
Description: 
Cipher: AES 256-bit
KDF: AES (100000 rounds)
Recycle bin is enabled.

[hny-gd]

If it wasn't, it would not work at all, right? Not only does it work fine in most cases, I can also usually simply work around the problem by going back and reopening the group.

In any case:

$ keepassxc-cli db-info database.kdbx Enter password to unlock database.kdbx: UUID: {78912fec-0986-499b-868f-417d1356f17f} Name: Datenbank Description: Cipher: AES 256-bit KDF: AES (60000 rounds) Recycle bin is enabled.

[hny-gd]

I can reliably (always when doing this for the first time after opening the file, but only in about 50% of the cases when going there the second or third time) reproduce the problem with attached file:

• C-x C-f Passwörter.kdbx
• Confirm opening big file with y
• Enter password "Testtesttest"
• Do NOT open in literal mode (n)
• Navigate to Untergruppe
• Navigate to Untergruppe (inside Untergruppe)
• Backspace (once)
• Navigate to Zweite Gruppe (inside Untergruppe)
• Error is happening: "Cannot find group UntergruppeZweite Gruppe/."

After Backspace keepass-mode is in root again. The second time, navigating there sometimes but not always works. P.zip

[hny-gd]

P.S. I just noticed that packaging the file with zip mangled the Umlaut in the file name (which wasn't too wise anyway). The problem also occurs in a file with a simple ASCII non-Umlaut file name, so you should be able to simply rename the file.

[hny-gd]

One more thing I noticed but which I can not pin down: To me it seems like navigating quickly into subgroups leads to this error. Maybe it is a race condition if the command line tool is not quick enough?

[juergenhoetzel]

I can confirm this issue.

As shown in the output from @hny-gd invalid paths (missing "/") are created when navigating forward-back-forward:

"UntergruppeZweite Gruppe"

This is fixed by Keep trailing "/" in group path when navigating back #16

[ifosch]

Thank you @juergenhoetzel! I just CR'd your PR. I've asked you to look into providing some test to validate this bug is not appearing further. I'm actually not sure how to make this. Maybe setting the path globally and making sure it changes as expected. If this is impossible or too hard, I still would accept the contribution and move on.