[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Misc development news (#8)

On Sun, Jun 01, 2008 at 12:50:24AM +0200, Peter Palfrader wrote:
> > - d-d-a is the list that all developers are supposed to be subscribed to,
> >   which means that's the list where announcements of general interest
> >   *should* go.

> It's not development related tho.

Description of that list is:

  Announcements for developers

  Announcements of development issues like policy changes, important release
  issues &c.

I.e., it's "for developers", which is not the same thing as "about

> And most people really don't need to know it.

It's a policy change which should be communicated to the developer body.

> > This is information that does need to go
> > to /all/ developers, not just to the infrastructure-announce list

> Well, you can't please all of them.

Does this, in fact, please anyone other than you?  I've hardly seen a
clamour of voices demanding that infrastructure information not be posted to
d-d-a; AFAICS this was a unilateral change.

> Frankly, I think most of the posts to d-d-a have no place on that list in
> the first place.  If it's the list DD are required to subscribe to we
> should try to also send stuff there that they *read*.  I hardly read all
> of the posts sent there.

I don't see how that's an argument in favor of putting policy change
announcements that apply to all developers on a separate list that's of
/less/ general interest.

> What's the number of affected DDs here?  10?  20?

It's a policy change.  Policy changes affect all DDs, not just those who
currently have .ssh/authorized_keys files in place, and should be
communicated appropriately.

> >   The use of ~user/.ssh/authorized_keys files has been disabled since
> >   DSA1571 was announced.  While our initial plan was to allow them
> >   again eventually some bad experience with DDs' key handling has
> >   led us to reconsider that intent.

> > ... that means?  What bad key handling was seen that warrants such a policy
> > change?

> People submitting known bad keys to ldap and stuffing those in their
> authorized_keys files also.  What else did you think it meant?

I have no idea, because I don't understand why the above would warrant a
policy change wrt authorized_keys.  Surely, known bad keys could already be
dealt with using the blacklist support that was published as part of the
DSA, so why would we need to disable authorized_keys altogether when there's
support for handling this in the server itself?

Since you said "known bad keys", I assume that you are talking about the
blacklisted keys and not, say, DSS keys in general; for instance, as I noted
when we discussed my authorized_keys on gluck, the DSS key listed there has
been unused since before the OpenSSL vulnerability was introduced, so is
certainly not compromised by virtue of being a DSS key.  If you do actually
mean DSS keys, then, ok, it's an acknowledged bug in the openssh package
that one can't disable keys by type, so I can understand disabling arbitrary
authorized_keys as a workaround for this.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Reply to: