Hi Phil,
[ Note: re-reading, I find that my mail could be read as "heated", which
it wasn't meant to be. I'm firm in what I believe needs to be done, but
not angry :-) ]
On Mon, Mar 28, 2011 at 03:08:12PM +0200, Philipp Kern wrote:
> > 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.
You may remember from your wanna-build BOF during dc10 that I said
something along the lines of "yes, I know I said I was against it. I
changed my mind." :-)
> As Joerg said, we still have that problem because only gid=wbadm can
> change the ssh keys on grieg.
I wasn't aware of that; I was under the impression that I could update
ssh keys when and if I needed to.
You're not helping :-)
> 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.
Sure. There's always going to be some things I can't do, if we want the
machine to be running properly (that is, unless I become a member of the
appropriate teams, but given my current time constraints that isn't very
likely).
But I'd think that "making sure this buildd host can still do uploads in
a timely manner when the key expires" is pretty well inside the realm of
the buildd admin's responsibility.
> > 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?
Not currently.
However, I was not initially complaining about the request turnaround
time back when the wanna-build team consisted mostly of James and Ryan,
either. But eventually that changed, and I got very very very frustrated
with that[1]. When the buildd stuff was changed so that many more people
got involved, I was hoping that this kind of thing would never happen
again.
Now I'm not saying that every buildd admin should have full and
unlimited access to wanna-build.d.o, or that we should all be
responsible for maintaining the wanna-build software (i.e., I'm not
suggesting to make wbadm and the set of buildd admins be one and the
same group). But I do think that when you add a new responsibility, you
should figure out whether this responsibility is in the realm of the
buildd admin or not. I believe that this one is, and therefore I should
be able to do it myself without requiring outside intervention.
As said, usually the request turnaround time is very reasonable, and I
have no complaints there. But there have been times where it was
slightly longer than average, and adding more things on the heap of
stuff which only you guys can do isn't helping. And, really, when a key
rollover needs to be done, most of the work is "gpg --gen-key", and
scp'ing the public key to the right system. If I can do all that, but
need one of you to run "mv $key $targetloc", that's just adding needless
bureaucracy. I want to avoid that, because I don't believe it makes
sense.
If the fear is that people will add keys without following proper
procedure, then please document the procedure in a way which makes it
hard to miss, and by all means bitchslap those who fail to follow
procedure properly. The set of "buildd admins" is small enough that
this should be workable. But I don't think it makes sense to take an
already limited group of people (buildd admins) and limit them even
further for things that lie squarely in their area of responsibility.
I don't really care about SSH keys, because they don't change (unless
someone breaks in and steals them, but then I expect DSA to step in,
lock down the host, do forensics, reinstall, etc, and eventually
generate a new SSH key while they're at it). I wouldn't care about
signing keys if they didn't change, either, but they do, so I think it's
something I need to be able to fix if someone pops up on IRC and asks me
why $HOST (which I just happen to maintain) isn't uploading.
If tomorrow someone decides that buildd SSH keys need to be rotated too
(which would make sense, BTW), then I want the ability to change them on
the host where buildd needs to run wanna-build. As it is, I don't think
there's a need for that.
[1] Note that I'm not trying to complain here about Ryan's performance
in the end; as it turned out, he had very good reasons to refuse
adding hosts at that point in time, but that didn't change the fact
that it was frustrating.
> 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.
Makes sense, I guess.
> 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.
This suggests that you wouldn't object to it being changed so that
gid=wbadm isn't involved as such, provided there's a proper technical
method for doing so?
> The idea is that we could even do the key rotation bit for you, which
> means less work for the buildd admin.
What I wanted to say is that while you could basically do everything for
me, you don't necessarily have the time to do so. Yes, much of it is
automated, but it sucks if suddenly things break and you need to fix
everything everywhere. That's why we put a person in charge of a
particular buildd host and call him/her a "buildd admin".
So I think that things which need doing on a per-host and regular basis
for buildd stuff should be something that the buildd admin can do all by
himself. What you've just done is adding something that would need to be
done on a per-host and regular basis, without the ability of me doing it
all by myself. That's bad.
> > 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.
It wasn't meant as a threat, but it's certainly something I feel very
strongly about. I'm definitely willing to work with you and everyone
involved to find a solution that will satisfy everyone; but I'm not
willing to work within the confines of a system that unnecessarily
limits my ability to do my work properly. As such, if no solution is
found for this problem, I've no choice but to step down as buildd admin.
Regards,
--
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