Hi Norman,
Norman Gray <[log in to unmask]> writes:
> On 13 Feb 2012, at 23:25, OlŠµ Streicher wrote:
>> So, there is no prevention of a fork of openssh. If you really want to be
>> sure to get the original code, you must download it from the openBSD
>> server. One can just take the code, patch it and provide the result again as
>> "openssh".
>
> [and...]
>
>> Debian does this, for example. There are a couple of changes in the C source
>> code; see for example
>> <http://patch-tracker.debian.org/package/openssh/1:5.9p1-2> for the current
>> testing version. Some of the changes are security relevant, and even then
>> the software does not need to be renamed, but remains "openssh" in
>> Debian. Even the "open" does not need to be changed, pointing back to its
>> origin, "open"BSD.
> Hmm: What's being illustrated here is not a fork, in any meaningful sense, nor
> a set of improvements (in scare-quotes or otherwise),
It is "kind-of-a-fork" and also includes some improvements. See, for
example the first patch
<http://patch-tracker.debian.org/patch/series/view/openssh/1:5.5p1-6+squeeze1/gssapi.patch>:
| Description: GSSAPI key exchange support
| This patch has been rejected upstream: "None of the OpenSSH developers
| are in favour of adding this, and this situation has not changed for
| several years. This is not a slight on Simon's patch, which is of
| fine quality, but just that a) we don't trust GSSAPI implementations
| that much and b) we don't like adding new KEX since they are pre-auth
| attack surface. This one is particularly scary, since it requires
| hooks out to typically root-owned system resources."
| .
| However, quite a lot of people rely on this in Debian, and it's better
| to have it merged into the main openssh package rather than having
| separate -krb5 packages (as we used to have). It seems to have a
| generally good security history.
| Author: Simon Wilkinson <[log in to unmask]>
| Bug: https://bugzilla.mindrot.org/show_bug.cgi?id=1242
| Last-Updated: 2010-02-27
[...]
This patch shows clearly the point that you think openSSH wants to
avoid: that someone puts in code that is not approved by the original
author -- in this case, the code was even *rejected* by them.
> What we can see here is that the patch-tracker.debian.org URL is both
> a provenance and an audit trail (debian is nothing if not bureaucratic
> and obsessive). It's possible to start at the debian-distributed
> openssh library, and work back through the applied patches to the
> canonical openssh distribution, see who is responsible for each
> integration fix, and see that none of them are obviously
> 'improvements'.
Yes, but this is not required by the openSSH license. It is just
practice of Debian. It would be the same for SOFA, PAL and AST.
> One difference is that there are more people who'd take an interest in
> relative primes than in osculating elements (why, I cannot imagine),
> so there are more people who would scan crypto patches and raise
> concerns, than would scan SOFA patches. However the audit trail would
> still be there, along with the pointers to the original distribution.
Ofcourse. Debian is a huge distribution, where many look into this.
However, it has a number of smaller derivatives which are all allowed to
do the same, and where almost nobody will check it. People are going
to download Mint Linux without checking whether it contains additional
patches for openSSL and whether they are dangerous. It is their risk,
but if someone is fooled by a security fault but in Mint Linux, the
openSSH authors would not be disreputed.
> The last thing is: who has change control for the debian package?
> (it's been a while since I looked at the debian package manual, since
> I started but abandoned packaging a library some years ago) I take it
> that it'd be you, Ole, as the package maintainer, yes? I imagine that
> in principle any debian member could add changes, but in practice it's
> socially unlikely to be anyone but you -- is that correct?
It is. The official package maintainer would be the "Debian Science
Team", with me as uploader, and I would take responsibility over the
package. If I am not responding, the science team would try to find
someone else, and if that fails and an update is needed (f.e. on some
security relevant stuff, or if changes in Debian require this), a
Non-Maintainer Upload (NMU) would happen by the Debian QA group,
changing the minimum to get it working.
Best regards
Ole
|