OpenSSH 5.0 released

It isn't a "low blow" to honestly state that Debian has not followed good procedure. You could
tell from the bug report yourself that it had been forwarded to a single developer and not a
security group contact and you never bothered to check with us to coordinate a release.

So yes, if you follow good procedure in future than you are not likely to be criticised. 

There is a "security" tag, but there is no facility for hidden bugs in debbugs. Security bugs
that are not publicly known should be reported to security@debian.org
(http://www.debian.org/security/faq#discover)

There is a security tag available in the BTS but as far as I know there's no facility in the
BTS for hiding reports based on it or any other criteria.  (I don't know how the security team
tracks things internally, but I'm 99.8% sure it's not using bugs.debian.org.)

I suppose reportbug and reportbug-ng should nag users who report bugs tagged security to send
them to team@security.debian.org (or security@debian.org) instead if the vulnerability isn't
publicly-known; I don't know how many users would know that offhand, though, so I'm not sure
the question would help much.

Hiding a bug in this fashion would violate Debian's social contract ("We will not hide
problems").

I don't know the real reason so this is just conjecture.  Maintainers will carry around
patches for a package that others find useful.  RedHat/Fedora really do want to patches to go
into upstream so that they don't have to carry them around.  

You've indicated that there are 50+ patches that they have been carrying since 2005.  I don't
know if that is true or not, but that would seem to indicate that it is hard to get patches
accepted in upstream for whatever reason.  The package maintainer has probably accepted that
requests for patches being accepted will fall on deaf ears and has not bothered to attempt to
get the supplier of the patch to send it upstream.  

I couldn't find any links quickly, but I have seen posts in the past about the difficulty of
getting patches into openssh.  At some point people will stop caring and won't attempt it
anymore.  This is not just an issue with OpenSSH but it common to other projects as well.
Con Kolivas's decision to stop providing is a high visibility example.If someone at openssh
really wanted, they could probably pull the source for the major distibutions packages and see
what they're putting in them.

Don't get me wrong I'm not trying to cast blame onto anyone, it's just the way life is and
people make mistakes. Fix it and go on.  

> However, to my mind the real fault here lies with XXX

I think it was rather a unfortunate chain of multiple human errors. Blaming a sigle point
misses the whole point, when fiasco could have been avoided had almost anyone in the chain of
events not done their mistake:

x) confusing ipv4/ipv6 behaviour on socket bind

If someone as experienced as openssh developers fall to this, how many other will/have done
the same mistake? This api does not seem to follow the principle of least surprise.

x) openssh developers creating the bug

Not fully understanding the api you are using is quite common source of security problems.
Requesting an tcp listening socket and then telling X to connect to the ipv4 address via
$DISPLAY might seem reasonable to assume safe when ipv6 doesn't pop into your mind.

x) fedora fixing the bug without realizing the the security implications

Has also happened often before. Especially when dealing with software as critical to security
as openssh, every bug should be considered as a security bug until proven wrong. It is
unfortunate that distributions hold bugfixes in their packages without pushing them upstream..

x) reporting the security bug to debian via inproper channel

For a enduser, finding out the proper way of reporting bugs is hard enough.  Now it requires
even more to find out that there is a separate channel or security issues. Now documentation
might help but most people don't read them anyway. debbugs could support security bugs better
(as it already supports the security tag the user was properly using..)

x) reporting it to wrong upstream contact

Different person than above, but basically the same mistake.

x) Debian security not watching "security" tagged bugs closely.

Presumably caused by lack of manpower.

x) pushing the update to Debian not via the security channel

While it was somewhat reasonable to expect that people before him in buglog had contacted the
upstream properly, A bigger mistake was to upload to unstable directly instead notifying
debian security team to do security uploads to stable and testing.

--

While the specific people have probably learned by now and will not repeat their mistake(s),
new people will join and eventually do similar mistakes. It's quite hard to avoid human
mistakes without same time making contributing inhumanly hard.