jasperreports: CVE-2017-14941, CVE-2017-5528, CVE-2017-5529

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

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: jasperreports: CVE-2017-14941, CVE-2017-5528, CVE-2017-5529

Date: Tue, 31 Oct 2017 22:45:32 +0100

[Message part 1 (text/plain, inline)]

Package: jasperreports
X-Debbugs-CC: team@security.debian.org
Severity: important
Tags: security

Hi,

the following vulnerabilities were published for jasperreports.

I couldn't find much information about them, so I asked a question on
the community board for jasperreports.

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


CVE-2017-14941[0]:
| Jaspersoft JasperReports 4.7 suffers from a saved credential disclosure
| vulnerability, which allows a remote authenticated user to retrieve
| stored Data Source passwords by accessing flow.html and reading the
| HTML source code of the page reached in an Edit action for a Data
| Source connector.

CVE-2017-5528[1]:
| Multiple JasperReports Server components contain vulnerabilities
| which may allow authorized users to perform cross-site scripting
| (XSS) and cross-site request forgery (CSRF) attacks.  The impact of
| this vulnerability includes the theoretical disclosure of sensitive
| information.  Affects TIBCO JasperReports Server (versions 6.1.1 and
| below, 6.2.0, 6.2.1, and 6.3.0), TIBCO JasperReports Server Community
| Edition (versions 6.3.0 and below), TIBCO JasperReports Server for
| ActiveMatrix BPM (versions 6.2.0 and below), TIBCO Jaspersoft for AWS
| with Multi-Tenancy (versions 6.2.0 and below), and TIBCO Jaspersoft
| Reporting and Analytics for AWS (versions 6.2.0 and below).

CVE-2017-5529[2]:
| JasperReports library components contain an information disclosure
| vulnerability. This vulnerability includes the theoretical disclosure
| of any accessible information from the host file system. Affects TIBCO
| JasperReports Library Community Edition (versions 6.4.0 and below),
| TIBCO JasperReports Library for ActiveMatrix BPM (versions 6.2.0 and
| below), TIBCO JasperReports Professional (versions 6.2.1 and below,
| and 6.3.0), TIBCO JasperReports Server (versions 6.1.1 and below,
| 6.2.0, 6.2.1, 6.3.0), TIBCO JasperReports Server Community Edition
| (versions 6.3.0 and below), TIBCO JasperReports Server for
| ActiveMatrix BPM (versions 6.2.0 and below), TIBCO Jaspersoft for AWS
| with Multi-Tenancy (versions 6.3.0 and below), TIBCO Jaspersoft
| Reporting and Analytics for AWS (versions 6.3.0 and below), and TIBCO
| Jaspersoft Studio for ActiveMatrix BPM (versions 6.2.0 and below).

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-14941
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14941
[1] https://security-tracker.debian.org/tracker/CVE-2017-5528
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5528
[2] https://security-tracker.debian.org/tracker/CVE-2017-5529
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5529

Please adjust the affected versions in the BTS as needed.

[signature.asc (application/pgp-signature, attachment)]

Message #10 received at 880467@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: 880467@bugs.debian.org

Subject: Re: jasperreports: CVE-2017-14941, CVE-2017-5528, CVE-2017-5529

Date: Wed, 1 Nov 2017 20:42:43 +0100

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, attachment)]

Message #15 received at 880467@bugs.debian.org (full text, mbox, reply):

From: Moritz Mühlenhoff <jmm@inutil.org>

To: Markus Koschany <apo@debian.org>

Cc: 880467@bugs.debian.org, team@security.debian.org

Subject: Re: jasperreports: CVE-2017-14941, CVE-2017-5528, CVE-2017-5529

Date: Sat, 9 Dec 2017 23:29:17 +0100

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

Message #20 received at 880467@bugs.debian.org (full text, mbox, reply):

From: Emmanuel Bourg <ebourg@apache.org>

To: Moritz Mühlenhoff <jmm@inutil.org>, 880467@bugs.debian.org, Markus Koschany <apo@debian.org>

Cc: team@security.debian.org

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

Date: Sat, 9 Dec 2017 23:43:38 +0100

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

Message #25 received at 880467@bugs.debian.org (full text, mbox, reply):

From: Moritz Mühlenhoff <jmm@inutil.org>

To: Emmanuel Bourg <ebourg@apache.org>

Cc: Moritz Mühlenhoff <jmm@inutil.org>, 880467@bugs.debian.org, Markus Koschany <apo@debian.org>, team@security.debian.org

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

Date: Sat, 9 Dec 2017 23:49:53 +0100

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

Message #30 received at 880467@bugs.debian.org (full text, mbox, reply):

From: Emmanuel Bourg <ebourg@apache.org>

To: Moritz Mühlenhoff <jmm@inutil.org>

Cc: 880467@bugs.debian.org, Markus Koschany <apo@debian.org>, team@security.debian.org

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

Date: Sun, 10 Dec 2017 00:06:51 +0100

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.

Message #35 received at 880467@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: Emmanuel Bourg <ebourg@apache.org>

Cc: 880467@bugs.debian.org, Moritz Mühlenhoff <jmm@inutil.org>, team@security.debian.org

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

Date: Sun, 10 Dec 2017 00:07:55 +0100

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, attachment)]

Message #40 received at 880467@bugs.debian.org (full text, mbox, reply):

From: Emmanuel Bourg <ebourg@apache.org>

To: Markus Koschany <apo@debian.org>

Cc: 880467@bugs.debian.org, Moritz Mühlenhoff <jmm@inutil.org>, team@security.debian.org

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

Date: Sun, 10 Dec 2017 00:49:08 +0100

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

Message #45 received at 880467@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: Emmanuel Bourg <ebourg@apache.org>

Cc: 880467@bugs.debian.org, Moritz Mühlenhoff <jmm@inutil.org>, team@security.debian.org

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

Date: Sun, 10 Dec 2017 15:38:35 +0100

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, attachment)]

Message #50 received at 880467@bugs.debian.org (full text, mbox, reply):

From: Emmanuel Bourg <ebourg@apache.org>

To: Markus Koschany <apo@debian.org>

Cc: 880467@bugs.debian.org, Moritz Mühlenhoff <jmm@inutil.org>, team@security.debian.org

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

Date: Mon, 11 Dec 2017 12:11:20 +0100

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.

Message #55 received at 880467-close@bugs.debian.org (full text, mbox, reply):

From: Emmanuel Bourg <ebourg@apache.org>

To: 880467-close@bugs.debian.org

Subject: Bug#880467: fixed in jasperreports 6.3.1-1

Date: Mon, 11 Dec 2017 12:48:59 +0000

Source: jasperreports
Source-Version: 6.3.1-1

We believe that the bug you reported is fixed in the latest version of
jasperreports, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 880467@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Emmanuel Bourg <ebourg@apache.org> (supplier of updated jasperreports package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Mon, 11 Dec 2017 13:14:45 +0100
Source: jasperreports
Binary: libjasperreports-java
Architecture: source
Version: 6.3.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>
Changed-By: Emmanuel Bourg <ebourg@apache.org>
Description:
 libjasperreports-java - Java reporting generator library
Closes: 880467
Changes:
 jasperreports (6.3.1-1) unstable; urgency=medium
 .
   * Team upload.
   * New upstream release
     - Fixes CVE-2017-5528 and CVE-2017-5529 (Closes: #880467)
     - Refreshed the patches
     - Adapted the build to the new source layout
   * Track and download the new releases from GitHub
Checksums-Sha1:
 bfeebfd690f1c8d9b6e36ad0c937f7967d1ef559 2847 jasperreports_6.3.1-1.dsc
 35f250a958d6d2d7134bd129776b98857580d8f9 1543728 jasperreports_6.3.1.orig.tar.xz
 ec308337dab6a022d3e191de103ee3fe08f0ed1b 12604 jasperreports_6.3.1-1.debian.tar.xz
 048ce73f4780622c77590fa558a98d01fc9e72ac 16272 jasperreports_6.3.1-1_source.buildinfo
Checksums-Sha256:
 8d4043574732d1b8e6c3f5969ad6055fb052f0c3e58350a8b1adb1eb2915709b 2847 jasperreports_6.3.1-1.dsc
 ea948587b0eed68ddc6fb5886937185616986cb720ac3665c0d489dbd9e2e0ba 1543728 jasperreports_6.3.1.orig.tar.xz
 528f6549e4901a72185b5774fdfb64603ab5e759639625201f3ef4f70736f641 12604 jasperreports_6.3.1-1.debian.tar.xz
 33197dfcb54ecd81f4cb0314a21bb07147831765cee98593863c875df29e5f0d 16272 jasperreports_6.3.1-1_source.buildinfo
Files:
 1b91772b4972a63302a235cdb6d686c2 2847 java optional jasperreports_6.3.1-1.dsc
 a8bc0c7ecc19d9a6c769fd56c427e75c 1543728 java optional jasperreports_6.3.1.orig.tar.xz
 38aa44a9c35842e304a81d5b0ec83eb8 12604 java optional jasperreports_6.3.1-1.debian.tar.xz
 4c4850bc2840c8632a3d1c5683f7aa53 16272 java optional jasperreports_6.3.1-1_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQJGBAEBCgAwFiEEuM5N4hCA3PkD4WxA9RPEGeS50KwFAloueRMSHGVib3VyZ0Bh
cGFjaGUub3JnAAoJEPUTxBnkudCsx4EP/ig/6zI2IoiUVK/3zIzmD2+g23CQd/+s
NDDmVJpxtdeK6MVQUzMQEu7BB0QALvagKDXyHCRNwRxQ9PByKD2Mn0E5QVKS0VOU
rZFOm8HQfHaCYujs5mPowBEt0Do7XEMEKrVcbsBg8pB4Aq+4I8kxRrMHbMHdrzy/
5KrwSgFoousuUvAEvi0aDveC3qzWq12GPDfHfGrituAaKw90R5sP6tJZg4nTpJcR
gZIHAHRBJ92pJa+fLCfFq3fl2q6QOOfyUmRCH3WDQGW73pAV5ArIKG//jWE5FtZh
fCvItHfJ9/DEprUZv/2m4BdaW0U92za9XrF8q5Tt98JdZC3J9nbd7lzZhsQ9SDsu
cYQH+MFI6iUq/n3C3SxyovbRG1FLau7Yj4/mt4M0OgEu/qCfRN459sxCP4kBCDN+
XSy3tAE1LU6eQTyLvOdvieP8a2djwzQaO2WMJyo4wQMJNV9i9wko7/176z9GKMow
SboIoLHr7WVQ+qstK3K8JrQ41Qfz7J4z2RWHFMDB58fTnfEc8CgI5m/1pxwXvr6c
MLqQJ/YTOm7jovXxMSDKDtFwj0ALeZx2eIvS6EZ4PWxg3jffsitMygdjMsMgqolL
AyxnvJPxryIDK6q/6ALoseyzCJ+/Ni9iHb97FRgldS6ck9/NDFfGEzXb15LYCnP9
2qxwqai66OUq
=9cM8
-----END PGP SIGNATURE-----

Message #60 received at 880467@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: Emmanuel Bourg <ebourg@apache.org>

Cc: 880467@bugs.debian.org, Moritz Mühlenhoff <jmm@inutil.org>, team@security.debian.org

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

Date: Mon, 11 Dec 2017 19:49:16 +0100

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

Message #65 received at 880467@bugs.debian.org (full text, mbox, reply):

From: Emmanuel Bourg <ebourg@apache.org>

To: Markus Koschany <apo@debian.org>

Cc: 880467@bugs.debian.org, Moritz Mühlenhoff <jmm@inutil.org>, team@security.debian.org

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

Date: Mon, 11 Dec 2017 23:24:20 +0100

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

Message #70 received at 880467@bugs.debian.org (full text, mbox, reply):

From: Markus Koschany <apo@debian.org>

To: Emmanuel Bourg <ebourg@apache.org>

Cc: 880467@bugs.debian.org, Moritz Mühlenhoff <jmm@inutil.org>, team@security.debian.org

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

Date: Tue, 12 Dec 2017 16:26:45 +0100

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

Message #75 received at 880467@bugs.debian.org (full text, mbox, reply):

From: Moritz Mühlenhoff <jmm@inutil.org>

To: Emmanuel Bourg <ebourg@apache.org>

Cc: Markus Koschany <apo@debian.org>, 880467@bugs.debian.org, team@security.debian.org

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

Date: Wed, 13 Dec 2017 19:38:51 +0100

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

Send a report that this bug log contains spam.