Re: Misc development news (#8)
On Mon, Jun 02, 2008 at 09:02:50AM +0100, Philip Hands wrote: > On Mon, Jun 02, 2008 at 01:48:29AM +0200, Joerg Jaspert wrote: > > On 11403 March 1977, Steve Langasek wrote: > > > So tagging a key as belonging to a particular host is insufficient - we > > > need > > > the full authorized_keys semantics for setting key options (from=, > > > command=, > > > no-port-forwarding, no-X11-forwarding, at least). > > And? You have that already, just add that in front of your key as you > > would normally do. ud-ldap passes it. It really "only" needs the > > "host=gluck,merkel,whatever" addition to also limit it to target hosts > > and then all is there. > Actually, it occurs to me that one can already do a poor-man's version > of the host restriction by making the command option something like: >command="hostname | grep -q '^\(gluck\|merkel\|whatever\)$' && > ~/d-i/d-i-unpack-helper ..." > Then, once the host= feature is available it will be possible to upgrade > to using that in a moment (rather than having to go round tidying up > on each host) -- in fact, if people are consistent in using the above > incantation, we could even tweak them all in LDAP when the feature is added. > Steve, does that address your concerns? Yes, it does - thanks, I wasn't aware that ud-ldap supported the full semantics for ssh key options, I don't remember this ever having been made clear in the documentation. Actually, what https://db.debian.org/doc-mail.html currently says is: Part of the replicated dataset is a virtual .ssh/authorized_keys file for each user. The change address is the simplest way to set the RSA key(s) you intend to use. Simply place a key on a line by itself, the full SSH key format specification is supported, see sshd(8). Perhaps this could be clarified as: Part of the replicated dataset is a virtual .ssh/authorized_keys file for each user. The change address is the simplest way to set the RSA key(s) you intend to use. The full authorized_keys file format is supported; see sshd(8) for details. ? (and as long as someone's editing, s/enterity/entirety/ a couple of lines down :) Cheers, -- 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 Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Misc development news (#8)
On Wed, 11 Jun 2008, Tollef Fog Heen wrote: > * Philip Hands > > | While this is initially for our (DSA's) benefit, in that it makes applying > | global changes easier, it's also for user's benefit. -- compare the > | effort required to ensure that there are no copies of a key (that was > | on a stolen laptop, say), on every debian host you _might_ have copied > | it to, to the effort of sending a single mail and knowing you're done. > > That's one way to look at it. For some of us, it means debian SSH > keys have to be handled specifically and not through $RCS update > through cron so it comes out as more, not less, work. Oh yes. I was particularly fond of people who automatically restored compromised authorized_keys after I had moved them away. It made my life so much more interesting. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Misc development news (#8)
* Philip Hands | While this is initially for our (DSA's) benefit, in that it makes applying | global changes easier, it's also for user's benefit. -- compare the | effort required to ensure that there are no copies of a key (that was | on a stolen laptop, say), on every debian host you _might_ have copied | it to, to the effort of sending a single mail and knowing you're done. That's one way to look at it. For some of us, it means debian SSH keys have to be handled specifically and not through $RCS update through cron so it comes out as more, not less, work. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Misc development news (#8)
On Mon, Jun 02, 2008 at 01:48:29AM +0200, Joerg Jaspert wrote: > On 11403 March 1977, Steve Langasek wrote: > > > So tagging a key as belonging to a particular host is insufficient - we need > > the full authorized_keys semantics for setting key options (from=, command=, > > no-port-forwarding, no-X11-forwarding, at least). > > And? You have that already, just add that in front of your key as you > would normally do. ud-ldap passes it. It really "only" needs the > "host=gluck,merkel,whatever" addition to also limit it to target hosts > and then all is there. Actually, it occurs to me that one can already do a poor-man's version of the host restriction by making the command option something like: command="hostname | grep -q '^\(gluck\|merkel\|whatever\)$' && ~/d-i/d-i-unpack-helper ..." Then, once the host= feature is available it will be possible to upgrade to using that in a moment (rather than having to go round tidying up on each host) -- in fact, if people are consistent in using the above incantation, we could even tweak them all in LDAP when the feature is added. Steve, does that address your concerns? Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Misc development news (#8)
On 11403 March 1977, Steve Langasek wrote: > So tagging a key as belonging to a particular host is insufficient - we need > the full authorized_keys semantics for setting key options (from=, command=, > no-port-forwarding, no-X11-forwarding, at least). And? You have that already, just add that in front of your key as you would normally do. ud-ldap passes it. It really "only" needs the "host=gluck,merkel,whatever" addition to also limit it to target hosts and then all is there. > There is a workaround available in the form of "ping weasel, get a symlink > that lets you do your mirroring thing on gluck", but it's still > unsatisfactory in that it remains easier for users to do the wrong thing by > giving their single-use keys global rights via LDAP than to coordinate with > DSA. Wrong. Basically the only technical restriction keys have to pass is that ssh-keygen -l -f $tmpfile has to be able to parse the lines. And it can parse those options fine. -- bye, Joerg #debian.de @ OFTC (01:38) hui, hier wird sonntags gechattet :) (01:39) ja, aber nur zwischen 1:35 und 1:45, wenn der Sonntag der 1. im Monat ist :) (01:39) wasn hier los? activity :) pgpKQeNeHn0kM.pgp Description: PGP signature
Re: Misc development news (#8)
On Sun, Jun 01, 2008 at 09:47:30AM -0700, Steve Langasek wrote: > Ideally, I would hope that at some future date the openssh packages gain > support for disabling DSS user keys via the config and the debian.org > machines could use that, bringing the behavior back closer into line with > the stock OpenSSH. IIRC, DSS is mandatory part of ssh protocol 2. RSA is only optional. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Misc development news (#8)
On Sun, Jun 01, 2008 at 11:10:42AM +0100, Philip Hands wrote: > While this is initially for our (DSA's) benefit, in that it makes applying > global changes easier, it's also for user's benefit. Er, "we're taking away your options for your own good"? :) > -- compare the effort required to ensure that there are no copies of a key > (that was on a stolen laptop, say), on every debian host you _might_ have > copied it to, to the effort of sending a single mail and knowing you're > done. > If there's some reason that you want specific keys to only give access > to specific hosts, and if the reason justifies the effort, I suppose it > would be possible to come up with a way of tagging which hosts any > particular key should give access to in LDAP -- is that why you're > worried about the loss of this feature? The particular use case, which Peter is familiar with already since he's been having to field requests from the d-i porters, is that daily builds of the installer images run as unattended jobs and are rsync'ed to gluck using passphraseless keys. Those of us who are security-conscious don't want those keys to be usable for anything aside from the single task of running an rsync server on a single system. So tagging a key as belonging to a particular host is insufficient - we need the full authorized_keys semantics for setting key options (from=, command=, no-port-forwarding, no-X11-forwarding, at least). There is a workaround available in the form of "ping weasel, get a symlink that lets you do your mirroring thing on gluck", but it's still unsatisfactory in that it remains easier for users to do the wrong thing by giving their single-use keys global rights via LDAP than to coordinate with DSA. -- 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 Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Misc development news (#8)
On Sun, Jun 01, 2008 at 09:15:19AM +0200, Peter Palfrader wrote: > On Sat, 31 May 2008, Steve Langasek wrote: > > > 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? > Those blacklists are hardly exhaustive. Hardly anybody seems to get > that their old DSS keys, if ever used once on a broken libssl are now > all bad. The blacklists for each RSA keysize/wordsize/endianness are exhaustive, or we have a big bug there that should be addressed. The set of compromised DSS keys is indeterminate; which means that DSS keys are not "known bad", they're "potentially bad" and should be disabled as a preventative measure. Anyway, that clarifies for me, thank you. Ideally, I would hope that at some future date the openssh packages gain support for disabling DSS user keys via the config and the debian.org machines could use that, bringing the behavior back closer into line with the stock OpenSSH. -- 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 Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Misc development news (#8)
On Sun, 01 Jun 2008, Philip Hands wrote: > If there's some reason that you want specific keys to only give access > to specific hosts, and if the reason justifies the effort, I suppose it > would be possible to come up with a way of tagging which hosts any > particular key should give access to in LDAP -- is that why you're > worried about the loss of this feature? Actually, that's already on the TODO list. Something like adding 'host="samosa,gluck,merkel" in front of your key and having that key only exported to the named hosts. Probably ok for interactive keys, for stuff that's command locked however the symlink[1] approach we currently use is probably easier on the user. That way they can edit their own file and can immediately test stuff. 1. (See /ssh-keys on gluck and tail -n2 /etc/ssh/sshd_config) -- weasel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Misc development news (#8)
On Sun, Jun 01, 2008 at 09:15:19AM +0200, Peter Palfrader wrote: > On Sat, 31 May 2008, Steve Langasek wrote: > > > > 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? > > Those blacklists are hardly exhaustive. Hardly anybody seems to get > that their old DSS keys, if ever used once on a broken libssl are now > all bad. > > Also note that until recently we didn't run debian's sshd at all, so > blacklist support is not something we could rely on. While this is initially for our (DSA's) benefit, in that it makes applying global changes easier, it's also for user's benefit. -- compare the effort required to ensure that there are no copies of a key (that was on a stolen laptop, say), on every debian host you _might_ have copied it to, to the effort of sending a single mail and knowing you're done. If there's some reason that you want specific keys to only give access to specific hosts, and if the reason justifies the effort, I suppose it would be possible to come up with a way of tagging which hosts any particular key should give access to in LDAP -- is that why you're worried about the loss of this feature? In short, having had our hand forced into turning authorized_keys off, we find that that is a better state to be in, so we're leaving it that way. (in fact disabling authorized_keys had been suggested before but we had no compelling reason to do it, if we had done so the post-SSL cleanup would have been significantly less effort). Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Misc development news (#8)
On Sun, 01 Jun 2008, Mohammed Adnène Trojette wrote: > On Sun, Jun 01, 2008, Peter Palfrader wrote: > > (hint: how would you place that file there in the first place?) > > Ask for a password change. Send your key with ssh-copy-id. Don't change > your password and lose it. And then try to login with your SSH key. > > OK, one has to be a bit thick to do that. And you can always recover a new password with your GPG key and thus login to all debian.org machines that you have access to. So there's no real problem here. :) Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Misc development news (#8)
On Sun, Jun 01, 2008, Peter Palfrader wrote: > (hint: how would you place that file there in the first place?) Ask for a password change. Send your key with ssh-copy-id. Don't change your password and lose it. And then try to login with your SSH key. OK, one has to be a bit thick to do that. -- Mohammed Adnène Trojette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Misc development news (#8)
On Sun, 01 Jun 2008, Mohammed Adnène Trojette wrote: > On Sun, Jun 01, 2008, Peter Palfrader wrote: > > know it. I suppose etc/motd will eventually be updated to point to it > > also. > > What's the use if you can't manage to login? Is this just to show that you have no idea what this is about, or that you didn't read the email I did send to d-d-a three weeks ago? (hint: how would you place that file there in the first place?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Misc development news (#8)
On Sat, 31 May 2008, Steve Langasek wrote: > > 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? Those blacklists are hardly exhaustive. Hardly anybody seems to get that their old DSS keys, if ever used once on a broken libssl are now all bad. Also note that until recently we didn't run debian's sshd at all, so blacklist support is not something we could rely on. -- weasel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Misc development news (#8)
On Sun, Jun 01, 2008, Peter Palfrader wrote: > It's not development related tho. And most people really don't need to It is developers related. And http://lists.debian.org/devel.html reads: debian-devel-announce: Announcements for developers > know it. I suppose etc/motd will eventually be updated to point to it > also. What's the use if you can't manage to login? > Well, you can't please all of them. 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. This is not a high traffic list. There is no spam on it. I personnally do read at least the first lines. > What's the number of affected DDs here? 10? 20? Deleting or marking an email as read is easier than knowing that a useful information has been sent on another mailing-list. And CC-ing dda should do no serious harm, I guess. > I think dia was the appropriate for that mail. The pointer in buxy's > mail was also fine, tho I wouldn't have placed it quite as prominently. dia was appropriate, for sure. But I would have appreciated to be informed on dda. Anyway, please keep up the great work as DSA. That is what really matters ;-) -- Mohammed Adnène Trojette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Misc development news (#8)
[EMAIL PROTECTED] dropped] On Sat, 31 May 2008, Steve Langasek wrote: > I think this is a great example of why announcements like this should be > sent to debian-devel-announce in the first place, instead of being relegated > to the debian-infrastructure-announce list that most developers aren't > subscribed to. > - 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. And most people really don't need to know it. I suppose etc/motd will eventually be updated to point to it also. > 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. 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. What's the number of affected DDs here? 10? 20? I think dia was the appropriate for that mail. The pointer in buxy's mail was also fine, tho I wouldn't have placed it quite as prominently. > 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? -- weasel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Misc development news (#8)
> Mail-Followup-To: [EMAIL PROTECTED] (Heh, eew) On Fri, May 30, 2008 at 08:52:02PM +0200, Raphael Hertzog wrote: > The news are collected on http://wiki.debian.org/DeveloperNews > Feel free to contribute. > ~/.ssh/authorized_keys will remain disabled by default > -- > Peter Palfrader announced on debian-infrastructure-announce[1] that DSA > will not reenable the usage of ~/.ssh/authorized_keys. One should use the > official LDAP infrastructure[2] to setup key-based SSH connection to > debian.org machines. There's an exception however, quoting Peter: > > Should you need keys only on specific hosts for automated tasks like > > updating stuff or syncing files between project machines or similar > > we can enable a user editable authorized_keys file for specific users > > on specific hosts. Usually we would expect those keys to be limited > > to use only from certain hosts (using from="") and limited to > > allow execution of only certain commands (using command=" > Contact DSA if you have such a case. I think this is a great example of why announcements like this should be sent to debian-devel-announce in the first place, instead of being relegated to the debian-infrastructure-announce list that most developers aren't subscribed to. - it's going to end up on d-d-a anyway because it's of sufficiently general concern that someone will forward it there - 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. Peter, please don't fragment our news feeds in this manner. At least provide this kind of information on *both* announcement lists, instead of hiding it only on the infrastructure-announce list among other messages that don't generally affect developers. This is information that does need to go to /all/ developers, not just to the infrastructure-announce list, because it's not just a maintenance notification - it's a policy change that affects how all developers interact with the project resources. Also, could someone please elaborate on what: 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? -- 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 Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
