LTS/ELTS Report for May 2019

[Roberto C . Sánchez]

For May I spent 22.25 hours on the following LTS tasks:

- ghostscript: CVE-2019-3839, additional cups-filter update
- python-urllib3: CVE-2019-11236, CVE-2019-11324
- python3.4, python2.7: CVE-2019-9947, CVE-2019-9740
- libspring-security-2.0-java: CVE-2019-3795
- libav: CVE-2017-17128, CVE-2018-5984, CVE-2018-5766
- bind9: CVE-2019-5743, testing of patch prepared by Thorsten Alteholtz
- libspring-java: FTBFS w/ latest tomcat8, CVE-2014-3578, CVE-2014-3625,
  CVE-2015-3192, CVE-2015-5211

I also spent 4.25 hours on the following ELTS tasks:

- python2.7, python2.6: CVE-2019-9740, CVE-2019-9947
- python-urllib3: CVE-2019-11236, CVE-2019-11324

Regards,

-Roberto

-- 
Roberto C. Sánchez

RFC: remaining CVEs on libspring-java

[Roberto C . Sánchez]

Hello all,

I would like some input from the group on how to handle the remaining
CVEs (all of which have been tagged no-dsa) on libspring-java:

Are are the CVEs which remain open in the jessie version:

CVE-2018-1257
CVE-2018-1199
CVE-2018-11040
CVE-2018-11039
CVE-2016-9878
CVE-2016-5007
CVE-2015-5211
CVE-2015-3192
CVE-2014-3625
CVE-2014-3578

I have integrated patches for CVE-2014-3578, CVE-2014-3625,
CVE-2015-3192, CVE-2015-5211, and CVE-2016-9878 (all of which are fixed
in stretch).  CVE-2015-5211 was especially complex because of the very
large changes between the 3.0 and 3.2 releases of Spring.  I elected to
not attempt to backport the patch for CVE-2016-5007 because the "fix"
for that CVE was the introduction of a new API.  That seemed not worth
the effort, given that there are documented mitigations.

That leaves CVE-2018-11039, CVE-2018-11040, CVE-2018-1199, and
CVE-2018-1257.  Of those, CVE-2018-11039, CVE-2018-11040, and
CVE-2018-1199 are also tagged no-dsa on stretch.  CVE-2018-1257 is still
vulnerable in stretch.  It does not seem to provide a clear benefit to
implement fixes for these CVEs if they are to remain unfixed in stretch.

To fix those last few could potentially place users in a position where
a jessie systems has these issues fixed, then an upgrade to stretch
subsequently exposes them.  For that reason, I am hesitant to proceed
with fixing them.

Does that seem like a sensible position?  If not, what might be some
reasons to go ahead with the additional fixes?

Regards,

-Roberto

-- 
Roberto C. Sánchez