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
development".
> 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: