Trusted Code (re. XZ backdoor) #10544
-
In light of the recent backdoor discovered in XZ; What are some of the precautions taken by authors here to prevent backdoors from sneaking into KeepassXC and, what are the things that we as users can do to potentially spot things like that entering the code-base? I use Keepass daily with a fairly large database. Hence my concerns. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Unfortunately, there is very little we can do about supply chain attacks. In case we were made aware of such an attack, we would publish a new release asap. But in general, we have to trust the dependencies we use are safe. The largest bunch of dependencies comes from Qt. For everything else, we try to limit third-party dependencies to what's really necessary. To prevent malicious code entering our repository directly, we have a team of multiple maintainers and we do mandatory code reviews (though two of us have admin access to the organisation, unavoidably). Code review isn't a guarantee, but it reduces the chances of merging malicious code by a lot. A heavily obfuscated configure / CMake script or unchecked binary files would very likely be spotted and rejected. |
Beta Was this translation helpful? Give feedback.
Unfortunately, there is very little we can do about supply chain attacks. In case we were made aware of such an attack, we would publish a new release asap. But in general, we have to trust the dependencies we use are safe. The largest bunch of dependencies comes from Qt. For everything else, we try to limit third-party dependencies to what's really necessary.
To prevent malicious code entering our repository directly, we have a team of multiple maintainers and we do mandatory code reviews (though two of us have admin access to the organisation, unavoidably). Code review isn't a guarantee, but it reduces the chances of merging malicious code by a lot. A heavily obfuscated configure / CMak…