Re: testing security uploads to bookworm-security
Hi FTP-masters,
On Tue, Mar 07, 2023 at 11:07:44AM +0100, Salvatore Bonaccorso wrote:
> 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).
We made a test upload targeting bookworm-security with a package which
will migrate in some days anyway to bookworm, but still fixing a
security issue.
python-cryptography/38.0.4-3~deb12u1 was uploaded to security-master
as source only upload, the upload got rejected with:
| Source-only uploads to NEW are not allowed.
|
| binary:python-cryptography-doc is NEW.
| binary:python3-cryptography is NEW.
| source:python-cryptography is NEW.
Can you have a look? Is something yet missing to habe the
bookworm-security suite up and running for security-master?
Once this is accepted, and packages build we will try to as well
install it into the archive. Following that a test upload involving a
package needing the code-signing service will be done as well (though
skipping the install step later likely).
Regards,
Salvatore
Reply to: