Re: RFC: remaining CVEs on libspring-java
On Thu, Jun 06, 2019 at 12:06:42AM -0400, Roberto C. Sánchez wrote: > On Tue, Jun 04, 2019 at 12:56:21PM +0200, Markus Koschany wrote: > > > 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. > > > Your mention of packages-to-support caused me to go look, where I found > that libspring-java is not listed. That makes me think that it was > mistakenly added to dla-needed.txt. Given that it should not have been > listed in the first place, that supports wrapping up and uploading the > work that I have done up to this point without going any further. > Emilio and Mike pointed out to me in IRC that I was misunderstanding the role of packages-to-support in LTS. Thanks to them for explaining the situation to me. That said, I'll still go ahead with your recommendation. Regards, -Roberto -- Roberto C. Sánchez
Re: RFC: remaining CVEs on libspring-java
On Tue, Jun 04, 2019 at 12:56:21PM +0200, Markus Koschany wrote: > 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. I have done that previously when I required assistance and have always received it. However, in this case the situation seemed to be more about the philosophy of fixing CVEs in jessie that were still open and unlikely to be fixed in stretch; nothing about libspring-java in particular. > 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. > Your mention of packages-to-support caused me to go look, where I found that libspring-java is not listed. That makes me think that it was mistakenly added to dla-needed.txt. Given that it should not have been listed in the first place, that supports wrapping up and uploading the work that I have done up to this point without going any further. Regards, -Roberto -- Roberto C. Sánchez
Re: RFC: remaining CVEs on libspring-java
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
RFC: remaining CVEs on libspring-java
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
