Re: Review libsoup2.4 for bullseye
Hello Adrian,
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
(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.
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 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.
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.
Anyway, I'm off to spend some more time on the package now. Would be
interesting to hear your thoughts on which parts you agree or disagree
about on the above if you have time to follow up.
>
> > Regards,
> > Andreas Henriksson
> >...
>
> cu
> Adrian
>
Regards,
Andreas Henriksson
Reply to: