authorized_keys2 directory idea

[mouring at etoh.eviladmin.org]

On Mon, 4 Jun 2001, Rob Hagopian wrote:

> On Mon, 4 Jun 2001, Markus Friedl wrote:
>
[..]


> Why even cater to those people? Even the FreeBSD security notices
> specificly mention that ssh v1 has inherent security problems. I don't
> even see why it's turned on by default for a distribution that
> superficially appears so security concious.
>

Lets do a small reality check.  OpenSSH has had a complete v2 compatibity
for how long now?  8 months?  No.. 6 months? no.. 5 months?  no.. Try
about a month.

Lets do another reality check.  How many people are still using v1?
Still over 5x the user base of v2.


THIS IS TOTALLY STUPID.  <sigh>  v2 is default for all transactions as of
v2.9.  Which means OpenSSH will only step down if  (a) the users tells the
software to, (b) the v2 keys don't exist, and (c) If the remote side can
not speak v2.  IMNSHO this is the correct behavior for at least another
year.  Maybe by that time we can look at the v2 and v1 stats and consider
disabling v1.

Migration paths are required evils.  Thus is the reason Markus has taken
painful amount writing all that compatibility code for v1.  And thus is
the reason why ssh.com is a pain in the ass.


> > > My suggestion was only to put it into /contrib... is that OK then?
> >
> > depends on the size of the patch. but if we have it in contrib,
> > then ppl will start to expect this from core-openssh.
>
> I won't claim that that's completely untrue, I notice a lot of emails from
> people who want stuff from the portable code base to migrate back into
> core. But I don't think it's fair, or even wise, to reject what three

What portable code?  OpenSSH portable should implement no 'new' features
outside what is required to get <Insert OS Name> to compile and run.

We attempt to bring in 'universal' changes back to the OpenBSD tree when
we feel it is right, but I see no reason why (Example) IRIX's overly
complex authetication code needs to be put into the clean OpenBSD tree.

> users want (with the only objections coming from committers who don't want
> it in the core code base) to leave it out of contrib...
>

I'll step up and state "No I do not feel that it's any easier to
track a single file vs multiple little files.  Therefor I do not wish
to see such code added to the core tree."

If that makes any difference.  I'm mainly on the Portable side of the
development (even if extremely busy and quietly lately).


> And a number of files in contrib are actually required to build all the
> packages for at least redhat. Since portable openssh distributes binaries
> of these packages aren't those basicly required to work?
>

You are trying to extend logic that is not correct.  All but a few cases
in contrib/, the files are there to support the portable version
directly.  You directly need contrib/redhat/  or else you have
authentication issues if you wish to use pam.  This is nothing like "I
wan't feature XYZ, but no one wants to commit it therefor I demand it be
in contrib/."

> Finally, if you don't want it in the code dists, what about a webpage with
> contrib patches? That would even give you an indication of popularity of
> these patches. Shutting out contributed code like this can only hurt the
> project in the long run...
> 								-Rob

Requiring people like myself who help keep the OpenSSH portable tree alive
to maintain all those code snipets will hurt the project even more.
Because in the end it's the OpenBSD and OpenSSH Portable group stuck with
dragging this contrib code forward to each new release.  Not the original
author who has long since left the mailinglist and potentially their job
and no longer cares about the patch they submitted.

I look at contrib/ diff files as yet another thing a user will bitch about
if it does not apply cleaningly.  A 'feature' they would have never even
dreamed of had the *.diff file not existed.  And one more headache to have
to worry about during crunch time in the release process.

Hell, at time I've almost removed contrib/chroot.diff because it was not
kept up.


Anyways, I've had enough of this.=) I have real work that needs to be
done.

- Ben