Date: Sat, 1 Jan 2000 16:29:32 -0500 (EST) From: Brian Fundakowski Feldman <green@FreeBSD.org> To: Keith Stevenson <k.stevenson@louisville.edu> Cc: security@FreeBSD.org Subject: Re: OpenSSH protocol 1.6 proposal Message-ID: <Pine.BSF.4.10.10001011619460.1082-100000@green.dyndns.org> In-Reply-To: <20000101143951.A4719@osaka.louisville.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 1 Jan 2000, Keith Stevenson wrote: > On Sat, Jan 01, 2000 at 01:49:22PM -0500, Brian Fundakowski Feldman wrote: > > > > P.S.: I realize other people may have proposed something very similar. > > Indeed, markus's proposal may be something like this. However, > > since it's impossible to work with anyone who is Theo, or > > "under" Theo, it's unrealistic to work with that. Hence the > > reason we need to make a code fork of OpenSSH as soon as > > convenient. > > First of all, allow me to thank you for all of the work you have done > maintaining OpenSSH for FreeBSD. I am looking forward to its entry into the > base tree. (I'm also planning to convert from SSH to OpenSSH on all my systems > as soon as it is feasible.) Thank you for the feedback, too :) > That said, the prospect of having a FreeBSD specific branch of OpenSSH > disturbs me. I manage an extremely heterogeneous Unix environment and > eventually hope to have OpenSSH running an all of my systems. I am concerned > that if OpenSSH branches, that there will be inter-operability problems at some > point down the road. While I appreciate the work that you are doing to make > OpenSSH more secure, and I understand the difficulties involved in working > with the OpenBSD folks, I urge you to try to avoid a code fork if it is at > all possible. I don't want to one day have to decide which OpenSSH to deploy > on my systems. Don't mistake a code fork for interoperability problems. The big issue is that there is so much work being done for OpenSSH by FreeBSDers which will never go in the OpenBSD's OpenSSH, it's not worth it to try to keep things a "straight port". Yes, this is one of those things where we know that we can do a much better job. As for interoperability, it is paramount to be compatible with the protocols that everyone implements. It's only natural to provide an extension to a previous protocol, and implement it backward-compatibly in every respect. Don't think of it as "embrace and extend" if it's really improving the protocol in an open manner, easily implemented by others, and that improvement is paramount in completely securing a protocol. Yes, I think this would be generating a de facto standard, but it's not a negative thing. Most standards are de facto. Besides, if few people appreciate the security a protocol change can afford, they'll be losing out. If something can be done to make something more secure, especially when whatever that is is designed to provide security, it should be done. That may include extending a protocol, but extending a protocol to a new version is not a bad thing if it's done with the proper steps to maintain complete compatibility in all respects. </rant> =] > > Regards, > --Keith Stevenson-- > > -- > Keith Stevenson > System Programmer - Data Center Services - University of Louisville > k.stevenson@louisville.edu > PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10001011619460.1082-100000>