Lately I've been increasingly worried about corrupted payloads of even open source password managers. Password managers are among the world's biggest honeypots. Maybe you trust the coders of the password manager. Maybe it's Open Source. But do you trust all of its upstream dependencies? And all their CI build processes? And each of their developers' security?
That's part of why I won't use an Electron-based password manager like BitWarden: there's no Electron app with a minimal dependency graph. Even Electron itself could easily fall victim if someone important in the development pipeline is compromised... And besides, Electron sucks anyway.
So, one way I can mitigate against the possibility of a malicious payload being delivered on password manager update is to not put all my eggs in one basket. For example, where I can, I authenticate with a Yubikey (if only by TOTP on Yubico Authenticator). Then my password isn't enough. But where do I store the recovery codes? Ugh: in the password manager.
I've been thinking on this for a while, and I haven't really found a perfect solution that provides me a way to store secrets without also being too reliant on one party's software. If I rely heavily on the password manager, that puts too much trust in it. If I rely more on a hardware token, that's too risky in case of loss of theft.
What's a security-aware nerd to do?
That's the whole point of QubesOS : you don't have to trust any specific software if they each run in their own VM.
It's a bit more complicated than that, since you probably want to be able to use a given file with different software (for instance, download a document from your browser, edit it with LibreOffice, and send it as an attachement with a mail client). It's the usual security vs usability tradeoff. You never completely get rid of it, but QubesOS has a lot of neat features that make is easier to understand and decide which software you trust with which data