Re: Misc development news (#8)
On Sat, 31 May 2008, Steve Langasek wrote:
> I.e., it's "for developers", which is not the same thing as "about
> development".
Funnily it got posted in a mail that is named "Misc _development_ news".
:-)
> It's a policy change which should be communicated to the developer body.
[...]
> 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.
I agree with vorlon here. I thought we created d-i-a for things which
affect our development/mirroring infrastructure but which were not
important enough to bother everybody on d-d-a. For example
"ftp.au.debian.org will have an hardware upgrade on 2008-XX-YY, sorry for
the short interruption".
Anything that concerns potentially the whole developer body should be sent
to d-d-a directly.
> > 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?
DSA has their own blacklists and they use them to filter keys directly
before installing them on the LDAP.
IOW, they never decided to rely on the blacklists of the current package.
It was probably the right decision at the beginning when there was no
openssh-extra package and that the coverage offered was not as a wide as
it is now.
> 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.
He probably didn't refer to this in his mail, but it's probably part
of his reasoning. I have such an automated key to upload symbols files to
merkel and he was reluctant to install a DSS key for this task (and I
switched to a RSA one later on). DSA has a nagios check for bad
ssh keys and any DSS key will generate a warning (while compromised keys
will create a full alert).
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: