Re: Review libsoup2.4 for bullseye
On Sat, Apr 26, 2025 at 02:47:12PM +0200, Andreas Henriksson wrote:
> Hello Adrian,
Hi Andreas,
> Thanks for your feedback! Thoughts below.
>
> On Tue, Apr 22, 2025 at 08:20:35PM +0300, Adrian Bunk wrote:
> > On Tue, Apr 22, 2025 at 01:31:07PM +0200, Andreas Henriksson wrote:
> > > Hello,
> >
> > Hi Andreas,
> >
> > >...
> > > I've also pulled additional
> > > commits adding testcases (but some are still disabled, because they need
> > > porting to the older libsoup 2.74 APIs), and I'm now at a published
> > > building package.
> > >...
> > > I'd like to ask both for opinions and help with backporting testcases.
> > > If you have any guidance to share on how to decide how much effort is
> > > worth putting into manually backporting testcase code (with the
> > > possibility of me introducing bugs), please share.
> > >...
>
> Recap about status:
> At the time of posting my original message I've just got a first
> building version together. More work is definitely planned
> to verify it.
> Some tests have been disabled to make the package build at this point
> (and investige more time to check if it makes sense to try backporting
> them as well is needed/planned).
>
> > I would aim for every CVE to verify both that the issue was present
> > before the fix, and that it is fixed with the fix.
> >
> >
> > That's easy when a PoC or testcase reproduces the problem,
> > when neither is available (or is available but does not
> > trigger the problem) a more thorough reading of the code
> > is usually needed.
> >
> > Most of these libsoup CVEs come with a PoC, and they should be tried.
>
> I've just briefly looked, but the PoC code seems to be for libsoup 3.x
> (current upstream relevant version of libsoup -- with different API)
> rather than libsoup 2.4 - so even PoC code would need to be backported
how confident are you that your backport of a fix is correct when you
don't understand the differences between 2.4 and 3.0?
There are some differences[1] in areas like threading or error handling
one should be aware of.
> (and plumbing needed to actually make them build and run). Secondly
> manual interpretation of the output will also be needed. Additionally
> setting up the (understanding and) setting up the expected test
> environment the PoC relies on takes additional time.
Most of the libsoup CVEs seem to come from code review, and test cases
are basically the PoCs with plumbing.
That's different from the common fuzzing CVEs where the PoC can often be
used to reproduce it with a commandline program.
> It thus feels relying on PoC rather than upstreams testcase in this case
> would leave much more room for (human) errors. Do you agree?
I don't think it makes much difference.
> > I wouldn't spend too much effort on additionally backporting testcases
> > when it has already been verified with the PoC that an issue was present
> > and is now fixed.
>
> I've found in working on previous packages that spending time on setting
> up the PoC code, which usually doesn't come with a build system and
> other plumbing, can take a less than trivial amount of time. Thus when
> another method exists to verify I feel like I probably need to motivate
> the invested time.
Given how many hours for how little work some contributors invoice, it
would be an above-average performance if you manage to provide packages
with properly tested fixes for the 15 CVEs for all releases from trixie
to jessie with 30 hours of work.
My estimate for the effort of fixing libsoup would be to start by
spending half a day learning libsoup and the differences between 2.4
and 3.0, then half an hour or an hour per CVE for a backport to trixie,
and then 1-2 hours per release backporting everything from trixie to
bookworm to ... to jessie.
That estimate is somewhere in the 15-30 hours range, the important part
is that spending time first on understanding things properly can get you
both a better result and less time spent.
By starting with trixie you would also notice that some CVEs are already
fixed there, including a ported testcase for CVE-2025-2784 that is
disabled in your backport.
The per-CVE work includes reading through all available information, the
discussion in upstream bugs might contain information like regressions
caused.
Porting a 20 LOC testcase is likely trivial when you understand why it
needs porting.
> Additionally it is my interpretation that usually if an upstream fix for
> a particular CVE is not complete, then often the incomplete part gets
> assigned a new CVE -- which would then be handled separately.
> Thus I guess the one of the main reason to verify ourselves is to make
> sure we did not introduce problems in our backports.
And to verify that the problem existed before your fix.[2]
Based on the descriptions one of the libsoup CVEs might have been
introduced by another of these CVEs, which might or might not be
true (and would make one CVE non-affected even though the fix has
to be included).
>...
> Regards,
> Andreas Henriksson
cu
Adrian
[1] https://libsoup.gnome.org/libsoup-3.0/migrating-from-libsoup-2.html
[2] Note that when the PoC/testcase does not find the problem that
doesn't prove that the version is not affected, it means that
further investigation is needed.
Reply to: