On Mon, Jul 01, 2002 at 09:22:30AM +0900, itojun@iijlab.net wrote:

 > 	there were reasons why they couldn't annouce the config file workaround
 > 	when 3.3 release was made.

There is NO reason that this work around could not have been disclosed
by the OpenSSH developers through the appropriate channels (e.g. CERT, who
then privately communicates with the security contacts of the various other
organizations).  There was also no reason not to provide a patch against
older versions of OpenSSH which fixed the problem through those same channels.

This would have allowed:

	* Projects such as NetBSD and FreeBSD to (silently) protect their
	  servers.

	* Software vendors to have new binaries, patches, whatever available
	  when the advisory is made public.  Again, this could have been
	  done silently, without the general public's knowledge.

	* Vendors to determine that no action is necessary on their part
	  based on how their software is configured.  Again, this can take
	  place without the general public's knowledge.

Instead, what happened is that a rumor of a nasty exploit was floated, with
the suggestion to upgrade to a new version (which includes new, non-mature
code, something which is especially dangerous to do, considering the security-
sensitive nature of the code in question), and a general sense of panic in the
community.

This goes against the spirit of "full disclosure".  The generally-accepted
practices for disclosing security issues are there for a reason: Because
they tend to work pretty well, and thus provide a greater level of protection
for the Internet as a whole.

On a somewhat related topic: I can't help but wonder if it's time for
us to adopt a policy of "no more wholesale updates of OpenSSH" -- basically
all of the security problems in OpenSSH have been a direct result of
development done by OpenSSH developers.  For a group of people who claim
to audit code line-by-line, they're certainly not auditing it when they
write it themselves or when they apply patches submitted by other contributors,
or else these problems wouldn't keep creeping up.

Seems like we, as a Project, would be better served by simply sticking
with the version we have, and applying fixes to it piece-meal as necessary.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>