Mehdi Dogguy <me...@dogguy.org> writes: > Le 2014-05-04 15:04, Ansgar Burchardt a écrit : >> I think the buildds building stuff for the offical archive should only >> do that. This includes not building for other archives (ports) or >> daily >> images for d-i (no matter the source). > > IMHO, if we want to initiate a change there, we should at least say > why it is so important to separate those builds. From my POV, the only > difference between the content of the Debian archive and an alioth > repository is a GPG signature. Having that in mind, would it be > acceptable to require a GPG-signed tag to initiate a build from?
Sure: one problem is that repositories on Alioth should not be trusted. It's quite easy to get a shell account there, so it might get compromised at some time. This should not result in buildds being potentially compromised as well (by running code obtained from Alioth during a build). Signed tags would be an improvement[1], but still have issues: it's an extra entry point into the buildd network and certain attacks are still possible: assume a buggy version of d-i does unsafe things via network during the build, but has a signed tag. One would have to make sure an attacker cannot make the buildd network repeat the build for this old version. [1] Minus minor things like being effectively limited to SHA1 in Git. Uploading signed .changes would also address these problems, but I don't know if that would fit into the workflow the d-i team uses. > RedHat has been doing that for years and didn't hear about any major > issue with that. Besides, we can also require that buildds building > for d-i are configured with throwaway chroots (but i think this became > the default now?). Throwaway chroots don't help against processes breaking out of the chroot, see #661037. > The problem is not about running blindly code coming from > elsewhere. We are already doing that (DDs can upload anything to build > on buildds... they can also upload/test exploits). Sure, but those are at least signed by a developer's key. Those are hopefully better protected than a host more or less open to the general public. > So, we have to find better arguments > before changing > this workflow and propose a sustainable alternative plan to build d-i. > >> Maybe they could be built on dedicated buildds that are not building >> packages for the main archive? Though that would require more >> hardware. > > This doesn't seem doable for all architectures. For which architectures would it be a problem to get additional hardware/VMs? >> Or run the daily d-i build as a job on the porter boxes? > > Can we please define what porter boxes are for and stick to that? They > are not "available hardware to do any stuff". Well, the same question applies to buildds. As I said I would really like buildds building packages for the main archive to stick to just doing that. (And the list of things they do in addition to that seems to currently include at least two items: d-i images and building stuff for inofficial archives/ports.d.o. No idea if they do even more.) Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
