[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: remaining CVEs on libspring-java


Am 02.06.19 um 01:53 schrieb 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:


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

You could also consider to fix them in Stretch as well. And sometimes,
if the code base is just too different, we fix what we can in Jessie.
Fixing all versions is better than fixing two versions is better than
fixing one version is better than fixing nothing but...

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

you could have contacted either me or Emmanuel Bourg from the Java team
when it comes to Java packages. The Spring framework is a very fine but
also complex web framework. We use many parts of it as
build-dependencies for other packages. I don't believe that a serious
Java developer will build web applications with our Spring package, and
a look into packages-to-support seems to confirm my suspicion. I would
upload what has already been fixed and then follow Stretch.



Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: