On Mon, Mar 28, 2011 at 11:25:13AM +0200, Wouter Verhelst wrote: > On Sun, Mar 27, 2011 at 10:56:28AM +0200, Joerg Jaspert wrote: > > - 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. > > 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.
AFAIR you were against autosigning on your buildds. So nothing will change for you anyway, unless you allow it. As Joerg said, we still have that problem because only gid=wbadm can change the ssh keys on grieg. And only gid=ftp-master can change the list for the hosts allowed to access incoming. (To be fair: DSA now exports a list of d.o buildds to ftp-master to automatically allow access to ftp-master's incoming directory and to security-master.) And you need the machine installed with the buildd profile by DSA in the first place. > Please fix this by doing one of > - Adding me (and other buildd admins) to the wbadm group, > - 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 > - 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) > - Finding someone else to maintain praetorius and voltaire The purpose of the wbadm group is the maintainance of the central wanna-build host. We also control who accesses our infrastructure and how. That's already the case since years. Do you have any complaint about the request turnaround time there? The builddadm group is a group that's allowed to log in to all buildds and thus is root-equivalent for quite some machines. Thus the two groups are separated. The whole key management thing isn't really limited to gid=wbadm by design, it's just that you need to be able to access ftp-master and have the key signing key in the admin keyring. The idea is that we could even do the key rotation bit for you, which means less work for the buildd admin. > 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. I'm not sure why it's more of a problem than it used to be. I'd be sad to lose you as a buildd admin. I'm not actually sure why you threaten us with it, though. Kind regards Philipp Kern
signature.asc
Description: Digital signature
