The concern here is accidentally vulnerable code, not malicious code.

Intentionally malicious or accidentally vulnerable, vulnerable code is vulnerable code.

Disabling compile flags on functionality doesn't necessarily guarantee you're any more secure, especially if the software isn't regularly tested without those flags.

Sure it does.

If the software (1) only ever used on trusted data (2) never makes network requests, then even with most vulnerable libraries, it simply cannot be exploited. But features like "fetch favicon from untrusted websites" open huge security holes in case there are ever bugs in http or image libraries.

(note that in case of local compromise, it does not matter if keepass is secure or not - the attacker can install keylogger, inject code into process or replace it altogether)

> If the software (1) only ever used on trusted data (2) never makes network requests, then even with most vulnerable libraries, it simply cannot be exploited.

You're assuming the flags remove all of the whats-deemed-as-risky behavior.

Trusting the flags from the lens of wanting to trim down a package size? Reasonable.

Trusting the flags from the lens of wanting to boost security? Eh... Crafting a security policy based on compile flags requires a lot of trust towards the developer of the code or spending a lot of time auditing these compile flags.

I just don't see the logic in wanting to simultaneously avoid trusting the code while also placing an enormous amount of new trust in the code's post-compile behavior.

> But features like "fetch favicon from untrusted websites" open huge security holes in case there are ever bugs in http or image libraries.

Image support is still built in, though. You're still susceptible to the vulnerable image library. Just because you're now pulling the images by hand doesn't make it any more secure.

With these concerns users should be considering some form of sandboxing. Whether it's tossing the package in a network-restricted container, VM, or separate device. This is very close to dogmatic security theater.

I am not worried about xz-style intentional backdoors.

I am worried about unintentional bugs which end up being remotely exploitable.

So while making sure the image library is bug-free is practically impossible, it is pretty easy to check for compile-time feature flags. Build it once, then ldd to make sure the http library is not linked. Or check debug messages. Or objdump and make sure method is missing. Tons of very simple methods.

From this standpoint, disabling favicon fetching is a 100% effective mitigation for all remote attacks. I've never bothered uploading favicons by hand, and I've never needed any images in my notes.

No security theater, just a pragmatic view.

Yet how many people are checking what libraries are being linked on every compilation?

CMakefiles are susceptible to bugs too. KeepassXC could also very well remove these build flags and people would be none the wiser.

As I said, concerned users should look at other ways to isolate the application’s behavior here instead of relying on the build process.

Run it in an isolated network namespace if network connectivity is the prevailing concern.