Re: RFR: openscad update
Hi Helmut,
I would propose that you are contacting the original openscad maintainer
and ask him, whether you can make a p-u upload for buster (if it is still
possible).
Thus you can get an experience with dealing of such uploads. Anyway, for
LTS we do not have any point releases. So basically it is possible to fix
even those CVEs which are not DSA-considered. But for not-important issue
it is better to pick up several issues (maybe together with some important
ones) and make an upload.
Leaving the package in dla-needed.txt without any action is not a good idea.
Or the upload should be done with the fixes. Or CVEs should be tagged as
<ignored> in tracker. In both cases the package should be removed from
dla-needed.txt as well.
The package can stay in dla-needed.txt longer (due to some testing
issues, or waiting for upstream reaction etc.) and it is OK. But simpl
leaving the package in dla-needed without any action can not bring a benefit.
Best regards
Anton
Am Do., 23. Juni 2022 um 17:03 Uhr schrieb Helmut Grohne <helmut@subdivi.de>:
>
> Hi,
>
> I've been looking into updating openscad in buster to fix CVE-2022-0496
> and CVE-2022-0497. They're already fixed in bullseye and later. They are
> input sanitization issues and CVE-2022-0496 needed a little porting of
> the patch. I verified that the provided PoCs for CVE-2022-0496 do
> trigger in an asan/ubsan build and no longer trigger after applying the
> patch. The provided PoC for CVE-2022-0497 did not trigger in an
> asan/ubsan build, but the fix is quite obvious and the PoC looks quite
> sensitive to the memory layout, so that's unsurprising. Beyond the
> build-time test suite, autopkgtests also pass.
>
> Given the buster -> LTS transition, I'm unsure where to upload this to.
> Adam's mail seems to indicate that it's late for the point release.
>
> Full build available at https://subdivi.de/~helmut/openscad_lts/, and
> .debdiff attached. Did I miss anything obvious on the process side?
>
> Helmut
Reply to: