Re: testing security uploads to bookworm-security
Hi,
On Tue, Mar 07, 2023 at 10:50:10AM +0100, Salvatore Bonaccorso wrote:
> Hi Moritz,
>
> On Mon, Mar 06, 2023 at 10:37:07PM +0100, Moritz Muehlenhoff wrote:
> > On Mon, Mar 06, 2023 at 10:17:04PM +0100, Paul Gevers wrote:
> > > Dear security team,
> > >
> > > It's the time of the season to ask you to consider testing that the next
> > > security suite is working as intended. In our checklist [1] it's mentioned
> > > to coordinate with you an upload to bookworm-security to confirm the build
> > > happens as expected. The checklist goes on to suggest a check that also a
> > > package needing signing works.
> > >
> > > I recall Ivo and Salvatore coordinated that on IRC for bullseye although I
> > > can't find it in the logs. Can I be of any assistance?
> >
> > For bookworm-security I could prepare an update for CVE-2021-26825/CVE-2021-26826,
> > it's fixed in sid, but the current version is blocked by FTBFS errors (#1031132).
> > The security fixes don't matter that much, but it would be a fine test.
> >
> > For the signed infra, not sure what we used for bullseye, we could do a linux
> > upload maybe, have it built and get signed in the private queue and then reject it?
> >
> > That would test the whole signing workflow, and the release part after that is the
> > same as for a non-signed update. Salvatore, thoughts?
>
> We can do this time as you proposed, so a full cycle with up to dak
> new-security-install for godot, and for the signed package one just
> go through all steps until we have all packages in embargoed queues,
> and then reject.
Btw, as i forgot to mention in above reply: we last time used fwupd as
more lightweight variant of a signed package, instead of a big hammer
with src:linux. Indeed there were on dak side fixes like
https://salsa.debian.org/ftp-team/code-signing/-/commit/20fbebb2705386b39783de51e277b08da6468e37
and
https://salsa.debian.org/ftp-team/code-signing/-/commit/049ae606d0e61b8b0bdef299e142a6a81379c768
(because the archive side because of the naming scheme change for
security archive).
This won't be necessary anymore, but now I wonder if the
non-free-firmware part is covered (in case ever will need e.g. a
intel-microcode DSA).
Regards,
Salvatore
Reply to: