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

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


Reply to: