Re: Review libsoup2.4 for bullseye
Hello again,
On Sat, Apr 26, 2025 at 06:16:47PM +0300, Adrian Bunk wrote:
> 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?
I'm somewhat confident, but the initial work was done in quite a haste
with the plan to go over it again once I had more time.
>
> 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.
Not sure yet how much harder backporting will get for the older ELTS
releases, but hopefully not much. We'll see when we get there.
I think there's basically no upper limit on how much time you can spend
on testing and review (and finding new bugs while at it?!), and since
I'm quite new to the (E)LTS efforts I'm still trying to understand what
is a reasonable amount of hours to invest.
I'm also still working on improving my effectiveness with handling
multiple releases in parallell for (E)LTS.
>
> 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.
My main challange so far has been finding time to work on this at all.
>
> 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.
I'm already aware of the trixie status, and the reason I disabled
tests to get to a building status is simply because I ran out of
time when I did my initial work and sent my initial mail.
Interesting that you mention specifically the CVE I was looking at right
now:
https://salsa.debian.org/lts-team/packages/libsoup/-/commit/80fc883b02cd8e2c3a76bc5d548e42253c51dfaf
>
> The per-CVE work includes reading through all available information, the
> discussion in upstream bugs might contain information like regressions
> caused.
I quickly glanced over all issues last time and I'm going through them
again now to see what has happened since (and what I potentially missed
when I was in a rush last time).
The most interesting finding is what I already spotted last time, that
the debian security-tracker links fixing commits that are sometimes not merged
and in for example CVE-2025-32049 it's just introducing an option with
the default set to same as before -- so not fixing anything.
https://gitlab.gnome.org/GNOME/libsoup/-/merge_requests/408#note_2394070
>
> Porting a 20 LOC testcase is likely trivial when you understand why it
> needs porting.
Just needs time to actually look at it first though.
>
> > 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.
Regards,
Andreas Henriksson
Reply to: