Michael Stone: > On Sun, Aug 04, 2013 at 10:12:40AM +0200, Heimo Stranner wrote: >> I think the real issue is about if the malicious patch is not part of >> the source package > > Why? It certainly makes your argument simpler if you arbitrarily > restrict the problem set, but it isn't obvious that it makes sense. If I > was going to backdoor something, I'd just make an innocent-looking > coding error that would enable a successful exploit; I certainly > wouldn't put in a commented section of code that says "backdoor here". > With sufficient effort it wouldn't be hard to inject such a > vulnerability that would go unnoticed for years--and
> I'm not sure why > that's less of an issue than someone making a one-time build with a > malicious patch that is not part of the source package. An innocent-looking coding error requires a malicious maintainer. A malicious patch not part of the source code can be done by any adversary who compromised the build server. I think the latter is more simple, risk free and anonymous. Getting rid of possibilities for intentional innocent-looking coding error is possible as well. First of all, how much security is the goal vs required effort? Is pragmatic security, as in "no random script kiddy can take down any Debian powered systems" sufficient or is it "we don't want all the three letter agencies around the globe being always able to remotely access any Debian system". As far I know, only lower level programming languages such as assembler, C and C++ open up for sophisticated intentional innocent-looking coding errors, right? Bugs possibly leading to remote code execution are much more obvious to spot in higher level languages such as python? If that case and more than pragmatic security is the goal, the use of lower level languages should be restricted to cases where other solutions aren't possible (bootloader etc.). And frozen. So that the code is 100% stable and vulnerability free after some time. It should be possible in theory if our machines get more performance over time? I think that would be quite painful to rewrite so many tools. Are there any better solutions to the trusting trust issue? Or will the fight against backdoors be lost at some point? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51fec610.1080...@riseup.net
