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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
