Who runs the buildds? (was: Rebuilding packages on *all* architectures)
[bcc'd to debian-admin] On Sun, 05 Sep 2004 18:07:43 +0200, Goswin von Brederlow asserted: And you are aware of the thread about that buildds are run partly by non DDs which can't be trusted and thus the archive is tainted by the autobuild debs? Is this still the case? Manoj madduck: only people trusted by the buildd admins have access to the infrastructure Manoj madduck: and the source for that information is me. Manoj madduck: you can quote me, but I am not authoritative here Are there any buildds run by non-DDs? Do any non-DDs have access to any buildds? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Who runs the buildds? (was: Rebuilding packages on *all* architectures)
* martin f krafft ([EMAIL PROTECTED]) wrote: On Sun, 05 Sep 2004 18:07:43 +0200, Goswin von Brederlow asserted: And you are aware of the thread about that buildds are run partly by non DDs which can't be trusted and thus the archive is tainted by the autobuild debs? Is this still the case? Manoj madduck: only people trusted by the buildd admins have access to the infrastructure Manoj madduck: and the source for that information is me. Manoj madduck: you can quote me, but I am not authoritative here Are there any buildds run by non-DDs? Do any non-DDs have access to any buildds? erm. Manoj's statements do not imply that those who are trusted by the buildd admins are DD's. It's certainly possible for the buildd admins to trust non-DD's. Stephen signature.asc Description: Digital signature
Re: Rebuilding packages on *all* architectures
also sprach Russell Coker [EMAIL PROTECTED] [2004.09.24.1653 +0200]: But what if the source is modified? Taking over a DD's machine and modifying the source tree that is used to make the .diff.gz shouldn't be impossible. We don't have any source auditing processes that could deal with this. Finding a security breach in the source is way easier than if it's just present in the binary but has been cleaned from the source subsequently. As I said, we won't manage to guard against all security issues. However, we should guard against those where the effort-effect ratio is low, and I think rebuilding binaries for all arches is rather low effort. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Rebuilding packages on *all* architectures
On Mon, 20 Sep 2004 06:15, martin f krafft [EMAIL PROTECTED] wrote: I want to add another point to this discussion. While we cannot prevent malicious maintainers from installing to the archives or poisoning the buildds, requiring all binaries to be remade on the buildds would rule out the possibility that an trojaned maintainer's machine would cause infected software to be distributed in the archives. Security it not absolute. But requiring all architectures to be rebuilt does add a significant amount of security, IMHO. Requiring all packages to be rebuilt will prevent the binary from not matching the source. But what if the source is modified? Taking over a DD's machine and modifying the source tree that is used to make the .diff.gz shouldn't be impossible. We don't have any source auditing processes that could deal with this. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding packages on *all* architectures
In article [EMAIL PROTECTED] you wrote: But what if the source is modified? This will be the next step tp solve. However I think not having a solution for that problem should not prevent us from having a sane bootstrap environment and use it. One idea could be to have an automatic way to check differences between .orig.tar.gz and upstream source, for example. Gruss Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding packages on *all* architectures
I want to add another point to this discussion. While we cannot prevent malicious maintainers from installing to the archives or poisoning the buildds, requiring all binaries to be remade on the buildds would rule out the possibility that an trojaned maintainer's machine would cause infected software to be distributed in the archives. Security it not absolute. But requiring all architectures to be rebuilt does add a significant amount of security, IMHO. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Rebuilding packages on *all* architectures
martin f krafft [EMAIL PROTECTED] writes: also sprach Goswin von Brederlow [EMAIL PROTECTED] [2004.09.05.1807 +0200]: The binary is needed because otherwise the -all packages would be missing and there would be no deb package in the archive holding the source in. I am not sure I understand that. Then the source should only propagate to unstable when the first buildd is done. Or at least, the buildd's DEB should replace the one in unstable. For source only uploads two things have to work: 1) Some build needs to build -all debs. 2) The archive software needs to not delete sources without debs in the archive if those source is the latest version (which could already be the case). Sure, the DD could insert some trojan into the binary. He could also insert a trojan into the source. And you are aware of the thread about that buildds are run partly by non DDs which can't be trusted and thus the archive is tainted by the autobuild debs? I was not aware of this, and I consider it a horrible state of affairs. Seriously, if this becomes public, Debian is in serious trouble, I think. A DD could also upload a binary recompile NMU with some flimsy excuse for package foo with a trojan, then upload source for package bar that Build-Depends: foo to get the trojan installed on the buildds and then upload a new foo source to remove the tainted foo and cover his tracks. The buildds would then be tainted and could insert trojans into every build package. Oh dear. I too think that the Debian autobuilders should compile the DEB files for *all* architectures. The should also compile the Arch: all packages. But security it the least of my worries. And it's among the greatest of mine. I think you misunderstood me there since it was realy unclear. Of course security is important. But I hardly consider security an argument for needing source only uploads. If you can't trust binary uploads from the maintainer then you can't trust the source without having every upload audited. There are other arguments for source only uploads like preventing mistakes and misbuilds due to the uncontrolled build environment of the DD. Lets face it, how many DDs build in a clean chroot? Looking at other security vulnerabilities between the source upload and the user installing the deb I think the binary upload is the (one of) strongest point. Previously, I considered Debian to be among the secure distros, partially because of its cleanliness, partially because of QA. Now I am beginning to see Debian as a real problem in terms of security. No clue what the state is with the other distros, but who cares? The point is that the current infrastructure and its consequences do *not* make Debian a viable choice when security is a factor. Something has to be done. I am pondering... If you want security then build from source. For the debs there are currently way to many open holes where someone can attack. Debian is getting more and more secure with apt-get/dpkg learning to actualy check signatures and signed debs becoming more common and so on. But for the last years Debian has run solely on trust between its members and supporters. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding packages on *all* architectures
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: [2] Actually, signing releases is not the correct way since auto-bulders run sid and sid is not a signed release. Apt 0.6 might support signed releases but I will not prevent some of the attacks Goswin described. All packages should be signed by the autobuilder itself with a buildd key. The changes file should also be signed before mailing. Other steps in the chain should then add signatures on top of that (is that possible for changes files?). With that I mean the buildd admin and katie. The buildd signature would say where the package was build and that it was not modified after that. The buildd admin signature is needed to have a human hand in it (otherwise a stolen key would collaps everything) and to validate the buildd. And last but not least the kati signature would validate the buildd and admin signatures and provide a quick way to check without needing the full up-to-date keyring. Currently we have the buildd admin signature in the changes files and katies signature in the Release file. But between the buildd and the admin there is a gap and between the admin and katie. Debian has some trust points but they are not quite chained together yet. Tools like the new apt or debsig-verify certainly go in the right direction. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding packages on *all* architectures
Michael Stone [EMAIL PROTECTED] writes: On Sun, Sep 05, 2004 at 06:07:43PM +0200, Goswin von Brederlow wrote: The binary is needed because otherwise the -all packages would be missing and there would be no deb package in the archive holding the source in. That's an implementation issue, not an absolute. An alternate implementation would be for all autobuilders to build -all packages, but for only the first to be accepted. Big waste of time we don't have. It should not be to hard to modify the buildd system to tell the first buildd to build a package to include -all debs. It is one of the features planed in the multibuild/buildd interface (which is still largely vapourware). Mike Stone MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding packages on *all* architectures
On Mon, 06 Sep 2004 at 04:13:12AM -0400, Javier Fern?ndez-Sanguino Pe?a wrote: BTW, one of the advantages of the releases freeze is that this kind of unexpected behaviour might be detected and fixed (given enought eyes and testers). Unless, of course, somebody coded a good-enough time bomb that knew when Debian was going to be released before we did, and was stealthy enough until a new version was released. Or a time bomb that tried to view a certain web site for certain content and blew up if such content was found. This type of bomb keeps the detonator in the hands of the intruder even after he has delivered the bomb. -- Phillip Hofmeister pgpvqSkqSutVT.pgp Description: PGP signature
Re: Rebuilding packages on *all* architectures
On Sun, Sep 05, 2004 at 06:17:36PM +0200, martin f krafft wrote: I was not aware of this, and I consider it a horrible state of affairs. Seriously, if this becomes public, Debian is in serious trouble, I think. ironic I always believed this to be a public list. /ironic Seriously though, all open-source projects have, in one way or another, different ways in which trusted parties can introduce trojans. The more they approach the bazaar model (vs. the cathedral model) the more the risks. It's a known risk of the bazaar model. Even an upstream author's trojaned system could introduce a trojan in the source code itself and that could be propagated to _all_ distributions including it if it was not caught in time [1]. Doesn't a saying go don't trust code you have not written yourself. You could improve the way Debian handles auto-builders [2] and the way developers prepare and submit new packages to reduce the risk, but there's no way you're going to remove it completely. BTW, one of the advantages of the releases freeze is that this kind of unexpected behaviour might be detected and fixed (given enought eyes and testers). Unless, of course, somebody coded a good-enough time bomb that knew when Debian was going to be released before we did, and was stealthy enough until a new version was released. Regards Javier [1] Those Trojans that we are aware of were detected in short notice after the mirror server or source was compromised. [2] Actually, signing releases is not the correct way since auto-bulders run sid and sid is not a signed release. Apt 0.6 might support signed releases but I will not prevent some of the attacks Goswin described. signature.asc Description: Digital signature
Re: Rebuilding packages on *all* architectures
On Mon, Sep 06, 2004 at 10:13:12AM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: Seriously though, all open-source projects have, in one way or another, different ways in which trusted parties can introduce trojans. The more they approach the bazaar model (vs. the cathedral model) the more the risks. It's a known risk of the bazaar model. Even an upstream author's trojaned system could introduce a trojan in the source code itself and that could be propagated to _all_ distributions including it if it was not caught in time [1]. Doesn't a saying go don't trust code you have not written yourself. I respectfully disagree, that open-source/bazaar models are more at risk for trojans, or any other kind of corruption for that matter. Cathedral/closed-source models are more at risk simply because they contain more and better hiding places. The only other conclusion that could be made is that Cathedral/closed-source participants are more morally and ethically inclined, if fact real world evidence points in the opposite direction. Don't trust those who are unwilling to show you the source. -- Doug Jensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding packages on *all* architectures
On Sun, Sep 05, 2004 at 06:07:43PM +0200, Goswin von Brederlow wrote: The binary is needed because otherwise the -all packages would be missing and there would be no deb package in the archive holding the source in. That's an implementation issue, not an absolute. An alternate implementation would be for all autobuilders to build -all packages, but for only the first to be accepted. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding packages on *all* architectures
On Mon, Sep 06, 2004 at 07:53:49PM +0200, Loic Minier wrote: doug jensen [EMAIL PROTECTED] - Mon, Sep 06, 2004: I respectfully disagree, that open-source/bazaar models are more at risk for trojans, or any other kind of corruption for that matter. Cathedral/closed-source models are more at risk simply because they contain more and better hiding places. The only other conclusion that could be made is that Cathedral/closed-source participants are more morally and ethically inclined, if fact real world evidence points in the opposite direction. Don't trust those who are unwilling to show you the source. I am not sure on how to understand this, but you use open-source/bazaar and Cathedral/closed-source, where I think the OP was refering to BSD, ie Cathedral/open-source. My apologies for misunderstanding. Thank you for the correction. -- Doug Jensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Rebuilding packages on *all* architectures
During the peripheral beer-drinking of the SUCON '04, a colleage of mine raised the concern that Debian stable includes binary code compiled on untrusted machines. I would like to herewith propose to change that for the future. An upload to Debian consists of a binary and source package. The binary is included primarily to ensure that the uploader verified the build. However, it is also used to take load of the autobuilders. Thus, for every upload, only 10 of the 11 architectures need to be built; the binary for the uploader's architecture is channeled to the archive without modification. This opens the possibility that the binary stems from a different source than the source package provides. Thus, a trojan could make it to the archive without being detected, and even though only one architecture would then be affected, it's a grave security problem. Even if the builder did not knowingly upload a trojan, his/her build environment could be contaminated. I think that the Debian autobuilders should compile the DEB files for *all* architectures. The binary upload should still be required for the aforementioned reasons, but it should not make it to the archive. Since I assume that most binaries accompanying a source upload are i386, this would possibly require us to stock up on the i386 autobuilder(s), which is the least of a problem. I would say this requires little changes and causes a great increase in the security and trustworthiness of the Debian archive. Or, put differently, if companies find out that the binaries they install were compiled on home-user PCs without special precautions, Debian won't exactly gain popularity. Comments welcome. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Rebuilding packages on *all* architectures
martin f krafft [EMAIL PROTECTED] writes: During the peripheral beer-drinking of the SUCON '04, a colleage of mine raised the concern that Debian stable includes binary code compiled on untrusted machines. I would like to herewith propose to change that for the future. An upload to Debian consists of a binary and source package. The binary is included primarily to ensure that the uploader verified the build. However, it is also used to take load of the autobuilders. Thus, for every upload, only 10 of the 11 architectures need to be built; the binary for the uploader's architecture is channeled to the archive without modification. The binary is needed because otherwise the -all packages would be missing and there would be no deb package in the archive holding the source in. This opens the possibility that the binary stems from a different source than the source package provides. Thus, a trojan could make it to the archive without being detected, and even though only one architecture would then be affected, it's a grave security problem. Even if the builder did not knowingly upload a trojan, his/her build environment could be contaminated. Sure, the DD could insert some trojan into the binary. He could also insert a trojan into the source. And you are aware of the thread about that buildds are run partly by non DDs which can't be trusted and thus the archive is tainted by the autobuild debs? A DD could also upload a binary recompile NMU with some flimsy excuse for package foo with a trojan, then upload source for package bar that Build-Depends: foo to get the trojan installed on the buildds and then upload a new foo source to remove the tainted foo and cover his tracks. The buildds would then be tainted and could insert trojans into every build package. Too obvious? And DDs wouldn't do that? How about just hacking a debian mirror from which a buildd dowloads from and swapping out package foo against a tainted one? apt-get doesn't validate the Release.gpg so you just need to recompute the md5sums for the Packages and Release file and noone will ever know. Scared yet? I think that the Debian autobuilders should compile the DEB files for *all* architectures. The binary upload should still be required for the aforementioned reasons, but it should not make it to the archive. Since I assume that most binaries accompanying a source upload are i386, this would possibly require us to stock up on the i386 autobuilder(s), which is the least of a problem. I too think that the Debian autobuilders should compile the DEB files for *all* architectures. The should also compile the Arch: all packages. But security it the least of my worries. Accidental miscompiled due to contaminated environments (as in older or newer libs than unstable has, more packages installed than Build-Depends suggests, ... and not tainted as in root-kits). I would say this requires little changes and causes a great increase in the security and trustworthiness of the Debian archive. Or, put differently, if companies find out that the binaries they install were compiled on home-user PCs without special precautions, Debian won't exactly gain popularity. Comments welcome. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding packages on *all* architectures
Goswin von Brederlow [EMAIL PROTECTED] writes: The binary is needed because otherwise the -all packages would be missing and there would be no deb package in the archive holding the source in. The first problem is solved by having one of the arch's autobuilders also be responsible for the Arch: all packages--presumably which ever keeps up the most with its queue would be the best choice. The second problem is solved by changing the way the archive management works. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
