Hi,
I don't have much time to contribute to this discussion, but let
me make a few remarks. It may be useful to realign expectations
and to spend our resources more wisely.
On Mon, Dec 11, 2017 at 12:11:20PM +0100, Emmanuel Bourg wrote:
> Le 10/12/2017 à 15:38, Markus Koschany a écrit :
>
> > We usually do support this use case. Take for example the recent
> > libpam4j update. No package in Debian is using it at the moment. The
> > whole purpose of this piece of software is authentication with PAM and
> > if you can circumvent the PAM auth mechanism, then it is obviously
> > broken, in a very bad way.
>
> IMHO patching libpam4j in the stable releases was a waste of time (and
> sponsor money as far as Debian LTS is concerned) since it is totally
> unused (the popcon isn't above the noise level).
Then we should remove it from the archive.
But as long as it is present in the archive it is covered by security
support and severe vulnerabilities get fixed in security updates independant
of the popcon size (if a PAM module fails to validate access that's severe
even if only a handful of users are affected).
> > Yes, Java developers download their libraries from Maven Central and
> > bundle everything. But how can you be so sure that someone is not using
> > Debian libraries in production because they are stable and receive
> > security support?
>
> We can never be sure someone isn't doing something silly with our
> packages, but that's not a reason for supporting them either. We already
> struggle to support the latest versions of Java, if we get distracted by
> fixing unused features in barely used packages we delay expected changes
> in more important packages, this is also a disservice to our users.
Well, there are certainly such installations. E.g. at work our release
engineering team operates Gerrit (which is not packaged in Debian), but they
still
made sure to make that installation use the Debian packages of Bouncycastle
and libmysql-java (so that those can upgraded via the distro in case of
security issues).
> - Level 1: Unsupported. The package is available as a convenience for
> building other packages. Use it at your own risk. Contributions to
> improve its support are kindly accepted.
We have a very narrow selected set of unsupported packages, but we generally
try to keep it minimal. If there are Java packages which are entirely limited
to being build deps for an actual program, we can mark them as unsupported
by adding a README.Debian.security file which describes the status quo
and add those packages to "debian-security-support" (which allows admins
to detect such packages).
If the Java maintainers can agree on a list, let's do that for buster?
> > Jasperreports has lots of dependencies. My first thought was to backport
> > the latest upstream release but this would probably require other
> > backports.
>
> I upgraded the package to the version 6.3.1 and it didn't require new
> dependencies. Backporting it to stretch may not be that difficult.
My problem with that is rather the uncooperative upstream (if that's
actually the case and not just a communication problem!), if an upstream
doesn't want to work with us and tell us details of security issues, this
makes those package unsuitable for a Debian stable release. We've dropped
virtualbox and mysql for that reason and OpenJDK is somewhat special since
Oracle are a little more open there than usual (also due to IcedTea).
Cheers,
Moritz
