Locking is not sufficient: it would need to overwrite the memory where passwords were decrypted to. With virtual memory, this becomes harder.

What's sufficient depends on your threat model.

Normal dude in a secure office? An auto-locking password manager would suffice.

Someone that should be concerned with passwords in-memory is someone who believes another has full physical access to their computer (and can, say, freeze RAM in nitrogen to extract passwords

My largest concern would be an adversary snatching my phone while my password manager was actively opened

Locking a password manager and your computer is certainly good enough in many cases. But gaining access to memory might not need the sophistication of using nitrogen (see eg https://en.m.wikipedia.org/wiki/DMA_attack).

> On Unix-like systems, KeePass 2.x uses ChaCha20, because Mono does not provide any effective memory protection method.

So only Windows seems to use secure memory protection.

Ok, we seem to be moving the goalposts a bit.

My point is that you need to read up on it to ensure the implementation of memory handling for your password manager is really safe. As you demonstrate yourself, KeePass has different clients with different memory protection profiles which also depends on the system.

But still not particularly hard. mmap has a MMAP_FIXED flag for this particular reason — overwrite the arena you’re decrypting to, and you should be set.