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?
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?
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.
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).
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.
Hi,
Salvatore Bonaccorso writes:
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.
There were two issues:
- The override sync from ftp-master to security-master was not handling
the fancy new `-security` addition to suite names.
- `bookworm-security` was still configured to not accept any uploads
(as was done when the suite was created to prevent accidental
uploads).
Both issues are now solved and the python-cryptography source upload was processed successfully.
From what I see there are the mipsel and mips64el builds missing andaccording to a quick chat with Adam on IRC it is not that they are yet
Hi Ansgar,
[Adding debian-wb-team@lists.debian.org list]
On Thu, Mar 09, 2023 at 01:16:21AM +0100, Ansgar wrote:
Hi,
Salvatore Bonaccorso writes:
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.
There were two issues:
- The override sync from ftp-master to security-master was not handling
the fancy new `-security` addition to suite names.
- `bookworm-security` was still configured to not accept any uploads
(as was done when the suite was created to prevent accidental
uploads).
Both issues are now solved and the python-cryptography source upload was processed successfully.
Thank you for addressing both. I can confirm we have now partially
builds on the embargoed queue.
From what I see there are the mipsel and mips64el builds missing and according to a quick chat with Adam on IRC it is not that they are yet
just missing because of buildd overloaded. Actually bookworm-security
seems not yet configured to be handled by mipsel and mips64el buildds.
Wanna-build team, can you have a look and check the mipsel, mips64el
status (and actually if we are setup complete as well on buildd setup
for bookworm-security)?
Hi,
On Thu, Mar 09, 2023 at 11:35:46AM +0100, Salvatore Bonaccorso wrote:
Hi Ansgar,
[Adding debian-wb-team@lists.debian.org list]
On Thu, Mar 09, 2023 at 01:16:21AM +0100, Ansgar wrote:
Hi,
Salvatore Bonaccorso writes:
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.
There were two issues:
- The override sync from ftp-master to security-master was not handling
the fancy new `-security` addition to suite names.
- `bookworm-security` was still configured to not accept any uploads
(as was done when the suite was created to prevent accidental
uploads).
Both issues are now solved and the python-cryptography source upload was processed successfully.
Thank you for addressing both. I can confirm we have now partially
builds on the embargoed queue.
FTR, Steve as well uploaded src:shim to test the code signing
involving path, and looks fine AFAICS. To Steve's request we will
though not install those packages, so reject them from the embargoed
queues.
From what I see there are the mipsel and mips64el builds missing and according to a quick chat with Adam on IRC it is not that they are yet
just missing because of buildd overloaded. Actually bookworm-security
seems not yet configured to be handled by mipsel and mips64el buildds.
Wanna-build team, can you have a look and check the mipsel, mips64el
status (and actually if we are setup complete as well on buildd setup
for bookworm-security)?
This one would still need to be checked, looping in as well Debian
Build Daemon team alias. Buildd admins, chan you have a look? I still
would like to install for real python-crytpography, though we have
missed the window to do it earlier than the -3 upload migrated to
testing. It still should work I think. Otherwise we will do then
another test with another package.
Hi,
On 2023-03-10 16:55, Salvatore Bonaccorso wrote:
Hi,
On Thu, Mar 09, 2023 at 11:35:46AM +0100, Salvatore Bonaccorso wrote:
Hi Ansgar,
[Adding debian-wb-team@lists.debian.org list]
On Thu, Mar 09, 2023 at 01:16:21AM +0100, Ansgar wrote:
Hi,
Salvatore Bonaccorso writes:
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.
There were two issues:
- The override sync from ftp-master to security-master was not handling
the fancy new `-security` addition to suite names.
- `bookworm-security` was still configured to not accept any uploads
(as was done when the suite was created to prevent accidental
uploads).
Both issues are now solved and the python-cryptography source upload was
processed successfully.
Thank you for addressing both. I can confirm we have now partially
builds on the embargoed queue.
FTR, Steve as well uploaded src:shim to test the code signing
involving path, and looks fine AFAICS. To Steve's request we will
though not install those packages, so reject them from the embargoed queues.
From what I see there are the mipsel and mips64el builds missing and according to a quick chat with Adam on IRC it is not that they are yet just missing because of buildd overloaded. Actually bookworm-security seems not yet configured to be handled by mipsel and mips64el buildds.
Wanna-build team, can you have a look and check the mipsel, mips64el status (and actually if we are setup complete as well on buildd setup
for bookworm-security)?
Sorry to not have looked that earlier. Indeed none of the mips*el
buildds were configured to build bookworm-security. I have enabled it on
two buildds for now, but this has to be done for all buildds. We also
need to check that it is the case for the other architectures. I have no
time now, I'll keep you updated once done, but in the meantime you
should be able to do tests with more packages.
This one would still need to be checked, looping in as well Debian
Build Daemon team alias. Buildd admins, chan you have a look? I still
would like to install for real python-crytpography, though we have
missed the window to do it earlier than the -3 upload migrated to
testing. It still should work I think. Otherwise we will do then
another test with another package.
python-cryptography has now been uploaded on both mipsel and mips64el.
Hi Aurelien,
On Fri, Mar 10, 2023 at 05:59:08PM +0100, Aurelien Jarno wrote:
Hi,
On 2023-03-10 16:55, Salvatore Bonaccorso wrote:
Hi,
On Thu, Mar 09, 2023 at 11:35:46AM +0100, Salvatore Bonaccorso wrote:
Hi Ansgar,
[Adding debian-wb-team@lists.debian.org list]
On Thu, Mar 09, 2023 at 01:16:21AM +0100, Ansgar wrote:
Hi,
Salvatore Bonaccorso writes:
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.
There were two issues:
- The override sync from ftp-master to security-master was not handling
the fancy new `-security` addition to suite names.
- `bookworm-security` was still configured to not accept any uploads
(as was done when the suite was created to prevent accidental
uploads).
Both issues are now solved and the python-cryptography source upload was
processed successfully.
Thank you for addressing both. I can confirm we have now partially builds on the embargoed queue.
FTR, Steve as well uploaded src:shim to test the code signing
involving path, and looks fine AFAICS. To Steve's request we will
though not install those packages, so reject them from the embargoed queues.
From what I see there are the mipsel and mips64el builds missing and according to a quick chat with Adam on IRC it is not that they are yet just missing because of buildd overloaded. Actually bookworm-security seems not yet configured to be handled by mipsel and mips64el buildds.
Wanna-build team, can you have a look and check the mipsel, mips64el status (and actually if we are setup complete as well on buildd setup for bookworm-security)?
Sorry to not have looked that earlier. Indeed none of the mips*el
buildds were configured to build bookworm-security. I have enabled it on two buildds for now, but this has to be done for all buildds. We also
need to check that it is the case for the other architectures. I have no time now, I'll keep you updated once done, but in the meantime you
should be able to do tests with more packages.
This one would still need to be checked, looping in as well Debian
Build Daemon team alias. Buildd admins, chan you have a look? I still would like to install for real python-crytpography, though we have
missed the window to do it earlier than the -3 upload migrated to testing. It still should work I think. Otherwise we will do then
another test with another package.
python-cryptography has now been uploaded on both mipsel and mips64el.
Thanks, confirmed the two bulds arrived as well.
Paul and release team, here is a summary: so I think we can confirm
that the bookworm-security side of things works now (modulo the above checking by Aurelien). We did:
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 418 |
Nodes: | 16 (2 / 14) |
Uptime: | 50:10:43 |
Calls: | 8,814 |
Calls today: | 10 |
Files: | 13,307 |
Messages: | 5,973,240 |