Re: OpenSSL 1.1.0

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Kurt Roeckx writes ("OpenSSL 1.1.0"):
> I just uploaded OpenSSL 1.1.0 to unstable. There are still many
> packages that fail to build using OpenSSL 1.1.0. For most packages
> it should be easy to migrate 1.1.0. The most common problems when
> going to OpenSSL 1.1.0 are:
> - configure trying to detect a function that's now a macro.
> - Accessing members of structures that have now become opaque. You
>   now need to use function to get or set them.

I'm concerned that we are setting up a situation where:

 * A maintainer (or interested party) for a package which peripherally
   uses openssl;
 * Gets an RC bug report;
 * Is threatened with autoremoval;
 * Does not really know how to respond;
 * Does not have useful support from their own upstream because
   their own upstream hasn't got to grips with this yet;
 * Feels under pressure that they must Fix It Now.

This seems to be setting ourselves up for failures - particularly,
failures where the package compiles and seems to work, but has some
kind of problem in its use of openssl APIs which constitutes a
security problem.

Maintainers who feel pressured may well apply patches which have not
had the level of review or discussion that would normally be
appropriate.  In security-sensitive code this is unfortunate.

There doesn't seem to be any way for a maintainer who is unsure to get
a review of a proposed patch to their package.  This is particularly
true when upstreams don't have patches - which seems to be true for
many packages (even BIND, say, only had them very recently).

Nor do we have any coherent tracking of what ad-hoc patches we are
(collectively) rushing to apply.

The use of RC bug status is a very strong imperative to maintainers.
I worry that we haven't really thought through the implications.

In general any large-scale transition like this needs to take into
account not only the technical goals, but also the best way to get the
best quality work out of our contributors.  I worry that the current
process is likely to encourage hasty actions.

If the process we have adopted results in security bugs, it will not
be enough to blame the poor maintainer who felt they had no
alternative.

Thanks for your attention.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.