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
