On Sat, 18 Feb 2012 15:59:38 +0200 Christoph Anton Mitterer <calestyo@scientia.net> wrote: > Am 18.02.2012 10:11, schrieb Teus Benschop: > > To put things in perspective, I just wonder how strong this > > 'fortress' > > really is, and whether this strength is only in our perception or > > whether it is real. Let me give just one example: A developer > > downloads > > a tarball from an upstream source, configures it, and does make > > install, > > yet has not even once checked whether this tarball is secure or is > > not a > > root kit. Detecting a root kit in downloaded source isn't trivial. If the package has completely changed and has been *replaced* with a toolkit, then any maintainer will notice that it doesn't build the files expected. A determined attack which tries to embed a root kit within an existing package/binary would be much more difficult for anyone to pick up, potentially even upstream. If a binary file built for the previous version of the upstream is a few Kb bigger in the next release, no maintainer is going to see that as anything more than entirely expected of a new upstream release. > This is true but... > a) this would be a general attack against all people, which are usually > a tiny bit harder to do, then the local sysadmin just hacking > colleagues.. So what is the point of the entire thread? Downloading upstream sources is a general thing for everyone using that package but it is done by one person (usually) and (usually) without any upstream checksums. It's a complete non-issue because there is 0% chance of getting every conceivable upstream team to implement anything like this. There may be other clues (file naming conventions, layout styles, weird compile messages appearing etc.) but none of those are reliable. > b) as everyone is affected then (all users of the package),... there is > a greater chance of notifying it But it is still down to chance. Overall, it's not something that I'm going to lose any sleep over. There's no way that I'll be asking my upstream teams to even consider it, nor would I implement it for my own upstream projects. I happen to use upstream sites which provide something like this but their security models aren't perfect. I used to provide detached GnuPG signatures alongside my uploaded source tarballs but nobody cared or even noticed if I inadvertently broke the signature. (This is for packages which regularly got downloaded for inclusion into Fedora, ArchLinux, Gentoo and numerous other distros other than Debian/Debian-based ones which get the source directly from me.) Honestly, nobody cares. > most important... > c) the ideal situation would of course be, that the maintainer has a > good relationship to upstream, perhaps even met them in person, > exchanged OpenPGP keys with them and uses those (or weaker means[0]) to > verify every single download. Completely unrealistic for most maintainers. Now, I could be really smug here and say that for some of my packages, I have absolute and airtight security between maintainer and upstream but that's only because I am sole maintainer and sole upstream.. (if you want better security than that, keep dreaming) .. but I also have other packages where upstream provide no checksums whatsoever. I've been lucky enough to meet one member of one of those upstream teams once (at a conference ~3 yrs ago which I haven't been able to attend since) but we had much more important stuff to discuss than signing / checksumming the download directory. Besides, meeting someone once with little chance of ever meeting them again is not a particularly strong indication that I should sign their GnuPG key (which is why I don't attend mass keysignings any longer). -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpAKp_n2ibdx.pgp
Description: PGP signature