On Mon, Mar 28, 2011 at 01:26:02PM +0200, Joerg Jaspert wrote: > Hi > > >> - The long standing project of enabling autosigning for the buildds also > >> got finished. That means that packages successfully built can now be > >> uploaded automatically, without waiting for the buildd admin to wake > >> up/come back from holiday/whatever. The rules for this are simple > >> * the buildd host must be maintained by DSA and have restricted > >> access > >> * the key must have a size of 4096 or higher and the private part > >> must never leave the buildd > >> * the key expires within 120 days > >> * there are not more than 2 keys per buildd (so they can do a key > >> rollover) > >> * no network access during build time/for the build part > >> We maintain a set of keyrings, one per architecture, together with a > >> shell script which allows the wanna-build admins to add and remove > >> keys as necessary. > > So, AIUI, only members of the wbadm GID can change keys, not any random > > buildd admin. > > Correct. > > > If I'm supposed to be maintaining a buildd host, I should be able to > > update the key allowed for signing, or I can't do my job properly. We've > > had a situation where only a limited group of people could activate > > buildd machines in the past, and it was broken; I have no desire to get > > back to that situation. > > You can do your job properly and you can activate buildd machines. > What you can not get is an added feature on top slightly easing the > workload. I don't think this can seriously be called "unable to do the > job properly". Many improvements in Debian start out as an "added feature on top slightly easing the workload". Wanna-build started out as a way to not have to run quinn-diff manually. Buildd started out as a way to not have to run sbuild manually. Sbuild started out as a way to not have to run dpkg-buildpackage... well, you get the idea. It's not required today, that much is true. In two years' time, people will have mostly forgotten about these manually-maintained buildd hosts, and will complain when their pet package isn't uploaded into the archive yet, five minutes after build. (heck, they do so now, occasionally, even without autosigning) > Now, this feature does require a whole set of people to do work before > (for example DSA to have the machine DSA maintained and secured up, > getting the ssh keys and w-b access for the buildd, getting access to > incoming to build stuff from there), and so I really fail to see where > "When asking for ssh/incoming/w-b access, get them to prepare the > autosign key" is much of added trouble? That in itself isn't, no. But the key rollover bit (which is senseble, btw; I'm not suggesting you remove that requirement) does make it a problem. > > Please fix this by doing one of > > - Adding me (and other buildd admins) to the wbadm group, > > None of ftpteams call. Sure. > > - Creating a new GID to which all buildd admins are added (I'd suggest > > 'builddadm' for that, but apparently that's already taken and is 100% > > the same as wbadm; if that isn't used, however, it could make sense) > > which would limit who can update keys > > Also none of ftpteams call, we dont change other peoples groups. I'm not asking to change other people's groups, here, just that "some other group" is used. If builddadm is used for something else and that can't be rolled into wbadm (which seems to be the case), then something else should be used. The point is that a buildd admin should be able to update the necessary bits for his buildd to function properly, if the bits are broken. Otherwise you don't need a buildd admin. > > - Changing the GID to "Debian", rather than anything else (I don't think > > you lose much by doing that, but I guess there might be reasons not > > to, and it's not my call anyway) > > Now this won't happen. fair enough. > > - Finding someone else to maintain praetorius and voltaire > > Not my call either, even though I do think that putting it onto this single > feature is a bit over the top. That's your choice, but I do have my reasons. > Basically this is something the people on the buildd site have to fight out > between. What we on the ftp side want is a *limited* set of people who can do > keychanges, that isn't changing too often. This makes sense. > wbadm does seem to be a perfect fit for this. This I disagree with. > > For clarity, the last option is *not* my preference. However, if none of > > the other three are done, I'm no longer interested in spending my time > > doing something I can't do properly anyway. I've been forced to work > > around not being able to fix issues with connectivity between my buildd > > host and the rest of the Debian infrastructure in the past, and I won't > > stand for it anymore. > > See above. This is an *additional* thing, any buildd will be able to run even > without this (and someone mentioned you don't like this feature anyways?), I wasn't a fan of it originally, no. However, I changed my mind, and provided it's implemented properly I do understand the benefits. > and so you can do your work as properly as you have been able until > now, so suddenly going this high up seems a bit heavy to me. Porting to another architecture is possible without buildd, too, it just isn't done. If I continue to manually sign logs even though everyone else switches to autosigning, people will point to me and say "he's slacking". They'd be right. > (Especially since any serious buildd does need more other bits added > and allowed before) I'm more interested in "during". > Anyways, as written above, this is mainly an issue for a team I have > nothing in, deal with them. What ftpmaster wants to have we have > stated. How we want the keys submitted is a technical issue already > dealt with too, so the rest seems to be a social issue that should be > solveable in whatever way. Sure, that's why I didn't send the mail to you only. But I do think the current situation isn't good enough and needs fixing. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html
Attachment:
signature.asc
Description: Digital signature