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:  "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  https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security
Description: OpenPGP digital signature