KMyMoney password doesn't work; can't open database

Did you recently upgrade your operating system?

Do you have KMyMoney 5.0 or above?

Did you try to open your kmymoney sqlite database and your password will not work (and you have no recollection of changing it, but maybe you did?!??)

Good news, you're not crazy. You're in the open source wild west.

KMyMoney uses sqlcipher for its encrypted sqlite databases. At some point it upgraded from sqlcipher 3 to sqlcipher 4, and the new version cannot open the old databases! They don't even tell you this, and neither does KMyMoney.

Luckily the fix is not hard.

1) Install the sqlcipher tool on your computer (eg, sudo apt install sqlcipher)

2) Open your database: sqlcipher path/to/mydb.sqlite

3) Run these commands:

After that, you should get a single row containing '0', indicating success (another number indicates failure). 

PRAGMA key = 'your_passphrase_here';

PRAGMA cipher_migrate;

you can .quit and uninstall sqlcipher if you choose.

Done. You should now be able to open your database with the latest KMyMoney. phew

Reference:  It's all made very clear in the second paragraph of the subsection on "File (SQLite/SQLCipher only)" in chapter 22 of the online manual

joe's own editor with ghostty

 There appears to be some incompatibility between the classic joe text editor and newer terminals such as Warp and ghostty which causes multi-line text which is pasted to the editor to lose the new-lines. In other words, all the lines in the pasted text appear on the same line.

This appears to be related to what is called "bracketed paste". This is a feature that allows multiple lines to be pasted at once, without the editor performing additional formatting that would happen if they were user-entered. In fact, joe seems to be the first piece of software to support this new feature of xterms back in the day.

Nowadays, most shell software supports bracketed paste, and that includes nano, pico, vi, and bash itself, as well as joe. But for some reason when joe's -brpaste config option is set to enable the feature (as is usually the default nowadays), the newlines are lost under ghostty.

The best workaround seems to be to disable bracketed paste support from joe, via the command line option --brpaste (note the second dash), or via the same in /etc/joe/joerc. This will cause pastes to appear correctly, but may cause ghostty to give a warning that such a paste may be dangerous. This warning can be disbled with ghostty's clipboard-paste-protection = false configuration option. If you're using bash or zsh, they also support bracketed paste, and as such should not execute the pasted commands until after you hit enter.

It's unclear why this happens in joe + ghostty. Bracketed paste to joe works in gnome-terminal. And bracketed paste from ghostty works in other software. Something similar was happening in nano/pico under macOS, and that was fixed. It appears that when gnome-terminal's vte uses bracketed paste, it sanitizes control characters before sending (pastify.cc:57-118). It also appears that joe has special handling for linefeeds (character 10) in bracketed pastes (main.c:152-153). So there may be unusual interactions showing up.