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

[Moritz Mühlenhoff]

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

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Markus Koschany]

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

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

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


> 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

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Markus Koschany]

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 

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

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


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


> Why do you package libspring-java in the first place?

Because we need it as a build dependency of quite of few other packages.


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


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

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Markus Koschany]

Am 10.12.2017 um 00:49 schrieb Emmanuel Bourg:
> Le 10/12/2017 à 00:07, Markus Koschany a écrit :
> 
>> However we should always be able to assess security vulnerabilities.
>> Just hoping that nobody will ever use the Debian library in some other
>> context is negligent. I would be really disappointed when I built an
>> Java app with Debian's system libraries and then I have to find out that
>> it is basically unsupported and contains security holes because it is
>> "just" a build-dependency for some other project.
> 
> I tend to disagree with this reasoning. We can't support any usage of
> the libraries we ship, we don't have the resources for that. Our
> responsibility should be limited to the code that we actually use in
> Debian. Java developers don't use the system libraries anyway, they
> typically pull the jars from Maven Central and bundle them with their
> applications. Patching unused features would really be a waste of time.

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. To ignore such bugs would be a disservice to
any Debian user if we can fix them.

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? Why do you package libspring-java in the first place?
Because you don't want that people build web applications with this
package? Sorry, but that makes no sense to me.

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.

>> To be fair: CVE-2017-5533 and CVE-2017-5528 probably do not affect us
>> because we ship the Jasperreports Library and not the server. Please
>> correct me if I am wrong.
> 
> I don't know, I'm not familiar enough with jasperreports. I can just.
> observe that the Spring modules depending on it are nowhere used in
> Debian yet.

I'm not familiar with jasperreports either. I just did a major upgrade
two years ago. But apparently it is not very important. So why all the fuss?
>> Thus said maybe you are able to find the relevant changes or you get a
>> more helpful reply from the support guys. Otherwise I would try to
>> disable jasperreports in libspring-java which appears to be optional. (I
>> know probably requires another patch...)
> 
> libspring-java is already quite complicated. An additional patch to
> maintain would be a hindrance, especially for disabling the usage of a
> library we don't really care about. On the other hand maintaining such a
> patch is maybe less complicated than regularly upgrading jasperreports,
> that's probably worth investigating. If we go that route I'd rather see
> libspring-java upgraded to the version 5.0 before patching it.

Jasperreports has lots of dependencies. My first thought was to backport
the latest upstream release but this would probably require other
backports. The same procedure for every security issue? No thanks. Then
I would rather suggest to disable the spring module.

>> For reference here is the link to my support request:
>>
>> https://community.jaspersoft.com/questions/1072461/security-update-cve-2017-14941-cve-2017-5528-cve-2017-5529
> 
> I'm not convinced they understood the context and our point of view.
> Upgrading the library was just the obvious solution to the issue raised,
> that doesn't make the answer hostile or uncooperative. I'd suggest
> asking the developers directly instead of going through a sales or
> customer support representative.

Upgrading to the latest version is always the recommended upstream way.
Good upstreams document their fixes though. I think it was sensible to
ask this question in the community forum. At least I gave it a try, if
you can find out more, please do.

> Emmanuel Bourg

Regards,

Markus



signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Emmanuel Bourg]

Le 10/12/2017 à 00:07, Markus Koschany a écrit :

> However we should always be able to assess security vulnerabilities.
> Just hoping that nobody will ever use the Debian library in some other
> context is negligent. I would be really disappointed when I built an
> Java app with Debian's system libraries and then I have to find out that
> it is basically unsupported and contains security holes because it is
> "just" a build-dependency for some other project.

I tend to disagree with this reasoning. We can't support any usage of
the libraries we ship, we don't have the resources for that. Our
responsibility should be limited to the code that we actually use in
Debian. Java developers don't use the system libraries anyway, they
typically pull the jars from Maven Central and bundle them with their
applications. Patching unused features would really be a waste of time.


> To be fair: CVE-2017-5533 and CVE-2017-5528 probably do not affect us
> because we ship the Jasperreports Library and not the server. Please
> correct me if I am wrong.

I don't know, I'm not familiar enough with jasperreports. I can just
observe that the Spring modules depending on it are nowhere used in
Debian yet.


> Thus said maybe you are able to find the relevant changes or you get a
> more helpful reply from the support guys. Otherwise I would try to
> disable jasperreports in libspring-java which appears to be optional. (I
> know probably requires another patch...)

libspring-java is already quite complicated. An additional patch to
maintain would be a hindrance, especially for disabling the usage of a
library we don't really care about. On the other hand maintaining such a
patch is maybe less complicated than regularly upgrading jasperreports,
that's probably worth investigating. If we go that route I'd rather see
libspring-java upgraded to the version 5.0 before patching it.


> For reference here is the link to my support request:
> 
> https://community.jaspersoft.com/questions/1072461/security-update-cve-2017-14941-cve-2017-5528-cve-2017-5529

I'm not convinced they understood the context and our point of view.
Upgrading the library was just the obvious solution to the issue raised,
that doesn't make the answer hostile or uncooperative. I'd suggest
asking the developers directly instead of going through a sales or
customer support representative.

Emmanuel Bourg

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Markus Koschany]

Am 09.12.2017 um 23:43 schrieb Emmanuel Bourg:
> Le 09/12/2017 à 23:29, Moritz Mühlenhoff a écrit :
> 
>> I'd say let's kick it out, then. We have a build dependency (and run time
>> dependencies) on libspring-java, can we axe it out there?
> 
> jasperreports is just a build dependency of some unused parts of
> libspring-java. No application in Debian needs it at run time. So these
> vulnerabilities can be safely ignored in the stable releases.

The situation with jasperreports is not great. I understand your
reasoning but I agree with Moritz that this is a more general issue with
jasperreports. My motivation to upgrade the library back in 2015 from
version 4 to 6 was libspring-java because this is something I use
personally and it is also a quite important piece of Java software.

However we should always be able to assess security vulnerabilities.
Just hoping that nobody will ever use the Debian library in some other
context is negligent. I would be really disappointed when I built an
Java app with Debian's system libraries and then I have to find out that
it is basically unsupported and contains security holes because it is
"just" a build-dependency for some other project.

To be fair: CVE-2017-5533 and CVE-2017-5528 probably do not affect us
because we ship the Jasperreports Library and not the server. Please
correct me if I am wrong.

Thus said maybe you are able to find the relevant changes or you get a
more helpful reply from the support guys. Otherwise I would try to
disable jasperreports in libspring-java which appears to be optional. (I
know probably requires another patch...)

For reference here is the link to my support request:

https://community.jaspersoft.com/questions/1072461/security-update-cve-2017-14941-cve-2017-5528-cve-2017-5529


Regards,

Markus



signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Emmanuel Bourg]

Le 09/12/2017 à 23:49, Moritz Mühlenhoff a écrit :

> Yeah, but libspring-java is not the issue here, it's jasperreports:
> We ship a jasperreports package of an uncooperative upstream which
> would need to see full backports across all supported suites since
> they don't tell us how to fix this with backports (or actually any
> vulnerability information).

Yes but since jasperreports isn't used anyway there is no need to
backport the fixes, that's the point I was trying to make. Until
jasperreports is actually used in Debian we can educate upstream about
the importance of documenting the security fixes.

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Moritz Mühlenhoff]

On Sat, Dec 09, 2017 at 11:43:38PM +0100, Emmanuel Bourg wrote:
> Le 09/12/2017 à 23:29, Moritz Mühlenhoff a écrit :
> 
> > I'd say let's kick it out, then. We have a build dependency (and run time
> > dependencies) on libspring-java, can we axe it out there?
> 
> jasperreports is just a build dependency of some unused parts of
> libspring-java. No application in Debian needs it at run time. So these
> vulnerabilities can be safely ignored in the stable releases.

Yeah, but libspring-java is not the issue here, it's jasperreports:
We ship a jasperreports package of an uncooperative upstream which
would need to see full backports across all supported suites since
they don't tell us how to fix this with backports (or actually any
vulnerability information).

Cheers,
   Moritz

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Emmanuel Bourg]

Le 09/12/2017 à 23:29, Moritz Mühlenhoff a écrit :

> I'd say let's kick it out, then. We have a build dependency (and run time
> dependencies) on libspring-java, can we axe it out there?

jasperreports is just a build dependency of some unused parts of
libspring-java. No application in Debian needs it at run time. So these
vulnerabilities can be safely ignored in the stable releases.

Emmanuel Bourg

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Moritz Mühlenhoff]

On Wed, Nov 01, 2017 at 08:42:43PM +0100, Markus Koschany wrote:
> Short update:
> 
> One staff member told me that my options are to read the advisories,
> which don't contain any detailed information or patches, or, if I have a
> commercial license, to contact support. Great, let's buy a license to
> get more information about security bugs.

WTF

> So far the only viable option would be to upgrade to the latest upstream
> release and backport that to Wheezy, Jessie and Stretch as well but I'm
> not thrilled to maintain another Oracle-like Java package when it comes
> to security bugs.

I'd say let's kick it out, then. We have a build dependency (and run time
dependencies) on libspring-java, can we axe it out there?

Cheers,
Moritz

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Markus Koschany]

Short update:

One staff member told me that my options are to read the advisories,
which don't contain any detailed information or patches, or, if I have a
commercial license, to contact support. Great, let's buy a license to
get more information about security bugs.

So far the only viable option would be to upgrade to the latest upstream
release and backport that to Wheezy, Jessie and Stretch as well but I'm
not thrilled to maintain another Oracle-like Java package when it comes
to security bugs.

Markus



signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.