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

Emmanuel Bourg ebourg at apache.org
Mon Dec 11 22:24:20 UTC 2017


Le 11/12/2017 à 19:49, Markus Koschany a écrit :

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

Huh?? I'm certainly not blocking anyone from fixing jasperreports or
libpam4j. I'm just putting the issues into perspective and trying to
convince you that there are more important things to do with our limited
resources. I failed, well, so be it. But please don't see that as
negative, I hold absolutely no grudge against your position, I'm
sincerely grateful that you invest so much time into the Debian Java
ecosystem and the security support. I'm just someone pragmatic that
likes doing things that make sense, and I feel concerned when someone is
about to spend a significant amount of time on something unnecessary
(not by the rules, but by the impact it'll have on actual users).


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

Do you mean that I'm holding important information and that's why we
don't see more contributors joining the party? I don't think this is a
fair assessment. Look at the Java 9 transition, Chris posted the bug
list months ago and no new contributor showed since, we are just a
handful of regular contributors slowly fixing the bugs. For the Maven 3
transition I requested some help with plexus-utils2 last month and I got
absolutely nothing.


> 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 respectfully disagree. Depending on a Java library provided by the
operating system for someone doing cross-platform Java development is a
bad idea for many reasons :
- The application becomes non portable across operating systems.
- In addition to package formats, the developer has to deal with even
more OS specific details (Debian has version X, Ubuntu has Y, and Fedora
doesn't have it, dealing with that in a standard Maven build is not
trivial).
- It becomes more difficult to develop on another OS (for example
Windows) and deploy on Debian.
- More differences between platforms means even more QA work.
- For a given OS, it might be necessary to have version specific
packages (i.e. one for Debian 8 and another one for Debian 9). A
corollary is that the same package may not be used for both Debian and
Ubuntu.
- The application is tied to the version of the library in Debian which
can't be upgraded at will.
- Security support is nice but meaningless, since the developer has to
support other operating systems and upgrade its dependencies everywhere
anyway.

I can see some notable exceptions though:
- libraries intended to interact with a specific version of an
application in Debian. For example mysql-connector-java which is aligned
with the version of MySQL/MariaDB in Debian.
- libraries with a native part (like JNA or tomcat-native) since Debian
supports more architectures.


> We already have something like that in place.

Yes but nothing formalized, like a dedicated field at the package level
in debian/control, or another medium detached from the package that
could be queried and displayed to the users.


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

The upgrade beyond 6.3.1 looks a bit more involved dependency wise. I'll
give it a try.

Emmanuel Bourg



More information about the pkg-java-maintainers mailing list