On Sat, Nov 17, 2007 at 02:36:25PM +0100, Mario Iseli wrote:
> on the #debian-newmaint there was just a (quite long) discussion started by
> Enrico Zini who had the idea to fix the DAM by adding 2, 3 more people via a GR. I
> think that this would be a good idea. There were also discussions about several
> (small) techincal problems, for example that if you have write access to the
> LDAP that you can add yourself to the "adm" group aka DSA.
As per [0] there are currently a bunch of different roles that're required
to work together for new DDs:
1. DAM -- does the actual review of work so far to decide whether the
person should be a DD
2. keyring-maint -- adds/removes/updates keys in the keyring
3. DSA -- maintains the LDAP database which provides access to
.d.o machines and general information about DDs
4. ftpmaster -- uses keyring-maint's keyring and DSA's ldap to
authenticate uploads for the archive
DAM (and FD, and AMs and nm.debian.org) is a policy position -- it's about
deciding who's allowed to do what, rather than a technical position that
involves keeping some software/hardware working; it's very subjective
and that's about it. Adding more DAMs (or AMs or FD members etc)
is straightforward.
keyring-maint is a technical position that occassionally overlaps with
the policy stuff that DAM usually handles. The technical part is just
managing a keyring securely, which is the same task as maintaining the
debian-maintainers package/keyring. Having that be managed by one person
(ie James Troup) who's had a lot of experience managing the keyring has
had the benefit that the keyring's been securely maintained, and the
drawback that change requests have often taken longer than people would
like. Managing the keyring by many people (as we're trying with the DM
keyring) is hopefully more scalable and efficient, but the security and
reliability of it is yet to be very well demonstrated.
DSA is likewise primarily a technical position involving keeping a bunch
of systems running. The main reason it's relevant here is that only a
limited number of changes to LDAP can be done by non-DSA members -- it's
possible for a DD to change their address or IRC nickname, eg, but if a
Debian team with an associated LDAP group (like ftpmaster and debadmin
and ftpteam; or the web team and webwml; etc) wants to add someone to
the group, a DSA member has to take the actual action, just as a DSA
member has to manually add or remove new developers approved by DAM. That
gives DSA an effective veto over a bunch of policy decisions, though I'm
personally not all that convinced it's a big problem. For this particular
case, the difficult is in adding keys to the keyring -- LDAP gets done at
the same time by James, and there's no point anyone else in DSA doing it
because without the keyring update, the new developer can't do anything.
> My Idea would be to give Joerg Jaspert full access to the LDAP and to the
> keyring, exactly as James Troup has now.
To my mind that at best fixes a current symptom while reinforcing the
underlying systematic problem.
The "DAM gets full access to everything" philosophy was pretty
straightforward back when Joey Schulze and James were both the entire
new-maintainer team and members of DSA. And that worked fine, right up
until James and Joey decided they were overworked and stopped until a
better method could be worked out, and then continued in an okay way
until James ended up being the only one doing DAM work, and made it
very difficult to get any sort of help because that would mean either
finding someone to trust with absolute power over the project (add/remove
developers, all authentication within the project, and full control of
all Debian machines), or reinventing the system.
Moving the project's absolute trust from James to Joerg might fix the
problems we have now (delays in account creation, delays in keyring
updates), or at least swap it for a different set of problems that
at least makes for an interesting change, but it keeps the exact same
system: the project's faced with the choice of letting Joerg do whatever
he wants, or removing him from a host of crucial roles and trying to
deal with the fallout that results.
For concreteness, I think a better *structural* solution to the problem
would be:
(a) make keyring-maint maintained by multiple people and not include
any policy decisions. ie, the maintainers should be able to
be anyone who understands gpg, and can follow a simple set of
procedures, not necessarily people we trust to decide who's in
or out of the project, or to keep a bunch of high-visibility
machines secure and operational
(b) enhance the mail interface to LDAP to allow non-DSA members
to make other changes, eg let particular DDs add other DDs to
groups they're in charge of automatically, and let DAMs add or
disable DD accounts
(c) limit the number of overlapping roles people have -- ie, require
folks to not be in more than two of DAM, DSA, ftpmaster,
tech-ctte, policy, etc at any one time -- so that we stop creating
these dependencies, particular for policy roles
I think jetring (used for the DM keyring), or a similar system is the way
to go for (a) in the long term, but if we're desperate for something in
the short term, we could just have someone else who we trust to maintain a
keyring maintain a seperate one, and have both DSA and ftpmaster use both
keyrings. That would preserve the security of the keyring by having the
master copies maintained exclusively on secure, non-networked machines by
people who're good with gpg, and once we're comfortable with maintaining
the DD keyring by some other means, we can just merge the keyrings.
I'd strongly suggest reading [0], from the paragraph beginning "The
primary reason why there's only one keyring-maint..." and [1] as
well before proposing changes in this area. Trading off security and
confidence in our keyring for quicker updates is something we *really*
want to avoid...
Cheers,
aj
[0] http://lists.debian.org/debian-project/2007/02/msg00204.html
[1] http://lists.debian.org/debian-project/2007/02/msg00226.html
Attachment:
signature.asc
Description: Digital signature