Sadly, I found a rather problematic error. When saving a password with § in it, the actions of copy to clipboard or showing the password when editing, turn it into Â§, which alters the password.
If someone could perhaps test it, to make sure that the issue is not solely on my system, that would be great.
Using pass on the console returns the correct password. Should there in fact be an issue with qtpass, it would be really helpful to get a list of characters, that exhibit this sort of problem, to verify all existing passwords against possible corruption.
The text was updated successfully, but these errors were encountered:
Thanks, I run the same (well, Arch, but KDE Plasma 5) on my main laptop, so that should make debugging this issue pretty easy.
The fact it also shows the password corrupted makes it even easier . .
Apparently the process that fetches the password already makes the encoding mistake.
Will try and look into this as soon as possible, thanks for finding and the clear description!
Will do some more testing (on Linux, Mac and Windows) tonight . .
Yesterday only had time to do a quick test on OSX and there it worked as-is (no encoding issues) . . so can easily do regression-testing..
Will probably have to check-out what the encoding of the shell-environment is and wrap accordingly etc.