Bug#880467: jasperreports: CVE-2017-14941, CVE-2017-5528, CVE-2017-5529

Mon Dec 11 18:49:16 UTC 2017

Am 11.12.2017 um 12:11 schrieb Emmanuel Bourg:
> 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).

First of all let me point out that there are more CVE to fix which are
not resolved by the latest upgrade. According to the security advisory
for CVE-2017-5532 jasperreports 6.3.1 is still vulnerable. The issue
should be resolved by upgrading to > 6.4.1. Like I said before it is not
clear to me if this package is affected by the other CVE due to lack of
information. I will file a new bug report to track those issues properly.

I disagree with your assessment of libpam4j and I believe the general
reoccurring negativity does not help very much. In my opinion it is
completely OK if you refuse to work on a package because I know you have
put quite a lot on your plate already and I assume you are a volunteer
like myself. On the other hand there are rules and best practices how to
maintain a package in Debian. Let me quote the developers reference: [1]

"As the maintainer of the package, you have the responsibility to
maintain it, even in the stable release. You are in the best position to
evaluate patches and test updated packages,[...]"

I believe the sentence is very clear. For the first step of evaluation
it doesn't really matter how many installations the popcon project shows
(which is opt-in btw) but the severity and impact is important. The sole
purpose of libpam4j is to interact with PAM. If it does authentication
incorrectly, so that users can completely circumvent it, we call that a
grave bug. The next step is to evaluate how complicated a fix would be.
The fix was a one-liner and simple. Thus it would have been extremely
silly not to apply it in all distributions because the version is
identical. Even without the LTS project this should have been an
absolute no-brainer. Raphael was correct to file #879002 because the
package is unmaintained and unused. This is a fact. You can refuse to
work on it but please do not block other people from doing the right
thing which is either to fix bugs or remove bit-rotting and broken
software from Debian.

>> 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.

To be honest it takes more time to explain you my point of view than
fixing such a package. I consider a stable and secure system more
important than latest feature X. That is probably the reason why I'm in
the Debian now. If Debian can't keep up the high quality standards we
promise then there are usually two ways to resolve such a problem: Get
more people involved or decrease the number of packages, so that our
expectations match reality again. Nobody wants broken packages.

There is also nothing silly users can do with our packages because
Debian's security and QA policy applies to all packages. Of course we
want our users to use them. We don't want them to worry what packages
receive security support or not. By default every stable package in
Debian main receives security support. This is one of our selling
points, isn't it?

If we can't even support the status quo then introducing new features
and packages will only increase the burden. The reason why we struggle
with big changes like Maven2->Maven3, Java8->Java9 is foremost the lack
of manpower, lack of communication and lack of a strategy to minimize
the brokenness in unstable. It has simply become too hard for
contributors to keep up with the changes. When only a select few know
why something is suddenly broken, chances are very slim that someone
else will fix it.

>> Why do you package libspring-java in the first place?
> 
> Because we need it as a build dependency of quite of few other packages.

A build-dependency is still a supported package by default and binary
packages of libspring-java are also used as runtime dependencies. That
also doesn't change the fact that it is mainly a web framework and no it
is not silly to use software as such if it is provided in Debian.

>> I agree we have not enough human resources to support every use case.
>> But by packaging stuff we also make a promise to support packages in
>> stable releases. We can't do that if we don't even know the severity of
>> security issues. Then the only sensible way is to remove the software.
>> Ignoring issues is and has never been a good option.
> 
> An alternative would be to mark the packages with the support level
> users can expect. Something like this:
> - Level 3: Full stable support. Security fixes are backported and
> stability is guaranteed (for example Tomcat, OpenSSL, Linux kernel).
> Feel free to depend on it for your needs.
> - Level 2: Security support, stability not guaranteed. Fixes will be
> provided as full updates, regressions may occur (for example OpenJDK).
> - 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 already have something like that in place. Our default is your
security Level 3. We only deviate from "Level 3" when certain
requirements are met, namely: upstream is obnoxious and doesn't disclose
details about security vulnerabilities or fixing a package is not
feasible with single patches. Those are exceptions not the rule though
because they can have a negative effect on system stability.

>> 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.

There is also Jessie..and Wheezy and we need version > 6.4.1.
Reverse-dependencies are not broken? I'm still not keen to backport
jasperreports and given the current situation and this conversation I am
not going to work on it.

Regards,

Markus

[1]
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20171211/7e76746d/attachment.sig>