Hi, 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. Regards, Markus
signature.asc
Description: OpenPGP digital signature
