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

Tue Dec 12 15:26:45 UTC 2017

Hi,

I suggest to drop the security team and Moritz from further replies
because we are starting to change the discussion topic. I recommend to
discuss changes to Debian's security policy on debian-devel or with the
security team directly.

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

Thanks for your concerns. You don't need to worry though because I know
how much time I should sensibly spend. It was neither time consuming nor
difficult to fix libpam4j in all distributions. The question is what
kind of message do we want to send out? I want a usable and secure
system by default and all resources for this goal are a good investment.
If libpam4j had been a package in testing, it would have been removed
from said distribution because of the grave bug. Just because someone
discovered the bug after we released the package, doesn't mean we should
ignore it.

This makes me wonder whether I should touch any package with a popcon
value lower than 100, or 1000, or 10000 installations from now on. Who
decides what is important. According to your logic we probably only need
to support Tomcat and all its dependencies which can also be ignored if
they only serve as build-dependencies. I want to be able to recommend
Debian as a Java platform. With Fedora we are the only ones who actually
put some effort into integrating Java into a Linux distribution. The
rest is either downloading dependencies from the internet without
further checks or they just distribute binary files without source. Of
course we could do the same which would save us a lot of time.

What I mean by "blocking" is, you have the tendency to veto or
protesting against too many, in my opinion, completely valid decisions.
Azureus has been broken for a very long time. There was a lot of time to
react to all open RC bugs but nothing happened. Finally the day arrived
when we wanted to remove the package and you delayed the removal again.
Actually I feel bad about it because I think I'm a bit too pushy but on
the other hand it doesn't make sense to keep a useless package in Debian
and there was really enough time. The result: Azureus is still not
removed from Debian, nor has it been fixed. Now I have reached the point
of: I don't care anymore.

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

No, I don't blame you for the lack of contributors. My point of
criticism is that you managed the Maven 3 transition single-handedly
without a plan how other people could contribute to it. I remember that
I asked this question on the list and your reply about plexus-utils2.
However I just couldn't wrap my mind around this topic because I didn't
understand your reasons why you updated package x first, that broke 5
packages, then you updated (seemingly) unrelated package y, which broke
another 5 packages, then you introduced foo-bar2 and switched 10
build-dependencies. Then you packaged a new release of xxx that broke
two more r-deps but that wasn't even related to Maven 3. And here I lost
it because I had to spent a lot of time to figure out what actually
caused this FTBFS. Was it because of the transition or something else?

This is probably completely clear to you but if you are not working on
those updates it is quite hard to grasp for outsiders. That's why I
would prefer that you start one project like Maven 3 and complete it
without getting distracted and organize such a complex update in a way
that other people might be able to help you. The idea is that people
understand all the steps and can digest all the pieces.

Take the recent Gradle update for example. I updated the package,
rebuild the majority or most important r-deps, discovered that two
packages FTBFS now and asked for help. You replied with a very helpful
comment and we could immediately fix one of them. Now it would be great
if we completed this update together by patching, not upgrading, bnd
because that would open another can of worms. One issue down. That's
what I call a digestible piece.

I know it is more difficult for Maven core libraries but the basic idea
is to reduce the complexity when attempting upgrades.

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

[...]

Ok, I snip the rest because I have reached my mail limit for today. I
wasn't talking about the developer, I was talking about the use in
production. You know that Debian's libraries don't change for the next
five years. So you ask your developer to test and develop the
application against Debian's system libraries (we don't care about
Windows or MacOS) because you don't want to take care of security
updates. That is certainly only one use case but my basic thought is
that you can't simply tell users how to use the software. That surely
wouldn't work for other languages and I don't see a reason why Java
should be any different.

Regards,

Markus

-------------- 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/20171212/6ae075c8/attachment.sig>