authorized_keys2 directory idea

[Rob Hagopian]

On Mon, 4 Jun 2001 mouring at etoh.eviladmin.org wrote:

> 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.

So now security decisions are made via stats user stats and not on the
security merits? That's in direct contradiction to your reasoning for
excluding this patch.

> > 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.

True, portable shouldn't add universal features, and that's another good
reason not to put it in main portable diffs. I understand Theo's arguments
for not putting it in the main code base as well considering the extensive
auditing that OpenBSD gets. I don't understand the objections to contrib,
unless there's a desire to eventually cause a fork.

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

OK, that's 3:2, with the only objections coming from the developers
themselves. Way to listen to the users... isn't this exactly what happened
with gcc?

> > 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/."

So you can't use gnome-ask-pass under openbsd? And my assertion has been
all along that there aren't enough patches (chroot.diff) in contrib that
this should be a big deal anyways.

> > 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.

Excuse me? I NEVER said you should maintain the code snippet, only that
you should distribute it. Everything in every contrib is almost by
definition AYOR...

> 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.

That certainly doesn't apply to this patch, ssh.com has this feature. In
fact, by excluding it you also exclude the possibilty that openssh could
be a drop in replacement for ssh.com (keeping existing keys) which would
reduce headaches for people rolling the software out. (Note that I don't
necessarily support that idea as I suspect the changes would be quite
extensive.)

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

So why didn't you? If it doesn't have a hope of working in the current
version why not remove it until someone fixes it? I never said you should
keep known broken code in the tree.

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

So do it and let users deal with contrib patches... I already described a
version system (like apaches) that would make it clear to developers when
they are working on/debugging contrib patched versions. There should be
zero effort on your part to include this. Certainly less than it's taken
to make a stand against extending the software.
								-Rob