Yes we can degenerate into inordinate amounts of rabbit holes. For 1, you can audit the JS that runs on your browser, it's not hiding (so it's not strictly fair to say that just because you loaded a webpage in your browser from their server it can't be trusted). And anyway, generally, your argument holds for any software interaction ever. GH doesn't have to ship you the repo that you browsed on the web client. A malicious actor could have compromised their infra and be serving fake code in the web UI but have added all sorts of malware to the stuff you download. Apple app store doesn't eve ship you the exact binary the developer uploaded. Scary. At some point you have to decide which threat vectors you actually care about. Give me a scenario and I can tell you how someone can theoretically attack it and why you're not safe. The only thing you can be 100% sure about is manually auditing every single release at the source level and building it yourself.

Well even then you have to make sure your compiler isn’t playing tricks on you. So compile your compiler from source … oh wait. Then you have your cpu microcode, firmware, security coprocessors.

Trusting trust

If you run keepass in a cgroup with no networking (or blocking in/outbound traffic in windows firewall) or extra disk access, your attack vector shrinks considerably. That's not particularly difficult to do, while it is to audit js on every single bitwarden page load

They have a paper about their architecture.

Basically, your master password is never sent, and everything is encrypted and decrypted locally.

You can't audit the server side code, but you can audit the client (and compile it from source) to make sure that the encryption is local and the master password is not sent.

Hah, so I suppose the next step would be a browser extension that performs this auditing on every visit

But your data is encrypted client side. It shouldn't be too difficult to audit thay the client side code matches a build of their original sources.

Then host your own.