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

-------------- 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/20171210/6d34b1c8/attachment.sig>