Sunday, 2 August 2020

Debian 10.5 media testing - 202001082250 - last few debian-live images being tested for amd64 - Calamares issue - Post 5 of several.

Last few debian-live images being tested for amd64. We have found a bug with the debian-live Gnome flavour. This specifically affects installs after booting from the live media and then installing to the machine using  the Calamares installer found on the desktop. The bug was introduced as a fix for one issue that has produced further buggy behaviour as a result.

Fixes are known - we've had highvoltage come and debug them with us - but will not be put out with this release but will wait for the 10.6 release which will allow for a longer time for debugging overall.

You can still run from the live-media, you can still install with the standard Debian installers found in the menu of the live-media disk - this is _only_ a limited time issue with the Calamares installer. At this point in the release cycle, it's been judged better to release the images as they are - with known and documented issues - than to try and debug them in a hurry and risk damaging or delaying a stable point release.

Saturday, 1 August 2020

Debian 10.5 media testing - 202008012055 - post 4 of several

We've more or less finished testing on the Debian install images. Now moving on to the debian-live images. Bugs found and being triaged live as I type. Lots of typing and noises in the background of the video conference. Now at about 12-14 hours in on this for some of the participants. Lots of good work still going on, as ever.

Debian 10.5 media testing - pause for supper - 202001081715 - post 3 of several

Various of the folk doing this have taken a food break until 1900 local. A few glitches, a few that needed to be tried over again - but it's all going fairly well.

It is likely that at least one of the CD images will be dropped. The XFCE desktop install CD for i386 is now too large to fit on CD media. The netinst .iso files / the DVD 1 file / any of the larger files available via Jigdo will all help you achieve the same result.

There are relatively few machines that are i386 architecture only - it might be appropriate for people to use 64 bit amd64 from this point onwards as pure i386 machines are now approaching ten years old as a minimum. If you do need a graphical user environment for a pure i386 machine, it can be installed by using an expert install or using tasksel in the installation process.

Debian 10.5 media testing - continuing quite happily - 202001081320 - post 2 of several

We've now settled into a reasonable rhythm: RattusRattus and Isy and Sledge all working away hard in Cambridge: Schweer in Germany and me here in Cheltenham.

Lots of chat backwards and forwards and a good deal of work being done, as ever.

It's really good to be back in the swing of it and we owe thanks to folk for setting up infrastructure for us to use for video chat, which makes a huge difference: even though I know what they're like, it's still good to see my colleagues.

Debian 10.5 media testing process started 202008011145 - post 1 of several.

The media testing process has started slightly late. There will be a _long_ testing process over much of the day: the final media image releases are likely to be at about 0200-0300UTC tomorrow.

Just settling in for a long day of testing: as ever, it's good to be chatting with my Debian colleagues in Cambridge and with Schweer in Germany. It's going to be a hot one - 30 Celsius (at least) and high humidity for all of us.

EDIT: Corrected for UTC :)

Debian 10.5 Buster point release 20200801 - all of the fixes :)

The point release is happening today for Debian Buster 10.5. This is an important release because it incorporates all the recent security fixes from the latest GRUB / Secure Boot "Boothole" security problems.

Behind the scenes, there has been a lot of work to get this right: a release subject to an embargo to allow all the Linux releases to co-ordinate this as far as possible, lots of consistent effort, lots of cooperation - the very best of Free/Libre/Open Source working together.

Secure Boot shims are signed with a different key to go to upstream this time around: in due course, when revocation of old, insecure code happens to plug the security hole, older media may be deny-listed. All the updates for all the affected packages (listed in https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot/ ) are included in this release.

This has been a major wake-up call: the work behind the scenes has meant that each affected Linux distribution will be in a much better position going forward and working together is always good.

Friday, 24 July 2020

How to use the signed checksum files to verify Debian media images

Following on from the blog post the other day in some sense: someone has asked on the debian-user list: "I do not understand from the given page (https://www.debian.org/CD/verify)  how to use .sign files and gpg in order to check verify the authenticity of debian cds. I understand the part with using sha256sum or sha512sum or md5sum to check whether the files were downloaded correctly."

Distributed with the CD and other media images on Debian CD mirrors, there are files like MD5SUM, MD5SUM.sign, SHA256SUM, SHA256SUM.sign and so on.

SHA512SUM is a plain text list of the SHA512SUMs for each of the files in the directory. SHA512SUM.sign is the GPG-signed version of that file. This allws for non-repudiation - if the signature is valid, then the plain text file has been signed by the owner of that key. Nothing has tampered with the checksums file since it was signed.

After downloading the SHA1SUM, SHA256SUM and SHA512SUM files and the corresponding .sign files from, say, the prime Debian CD mirror at

Assuming that you already have GPG installed: sha256sum and sha512sum are installed by the coreutils package, which Debian installs by default.

gpg --verify SHA512SUMS.sign SHA512SUMS will verify the .sign signature file against the signed file.

gpg --verify SHA512SUMS.sign SHA512SUMS
gpg: Signature made Sun 10 May 2020 00:16:52 UTC
gpg:                using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B


The signature is as given on the Debian CD verification page given above.

You can import that key from the Debian key servers if you wish.

gpg --keyserver keyring.debian.org --recv-keys DF9B9C49EAA9298432589D76DA87E80D6294BE9B

You can import the signature for checking from the SKS keyservers which are often more available:

gpg --keyserver pool.sks-keyservers.net --recv-keys DF9B9C49EAA9298432589D76DA87E80D6294BE9B 

and you then get:

gpg --verify SHA512SUMS.sign SHA512SUMS
gpg: Signature made Sun 10 May 2020 00:16:52 UTC
gpg:                using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: Good signature from "Debian CD signing key " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: DF9B 9C49 EAA9 2984 3258  9D76 DA87 E80D 6294 BE9B


My own key isn't in the Debian CD signing key ring - but this does now show me that this is a good signature from the primary key fingerprint as given.

Repeating the exercise from the other day and producing a Debian amd64 netinst file using jigdo, I can now check the checksum on the local .iso file against the checksum file distributed by Debian. If they match, it's a good sign that the CD I've generated is bit for bit identical. For my locally generated file:

sha512sum debian-10.4.0-amd64-netinst.iso
ec69e4bfceca56222e6e81766bf235596171afe19d47c20120783c1644f72dc605d341714751341051518b0b322d6c84e9de997815e0c74f525c66f9d9eb4295  debian-10.4.0-amd64-netinst.iso


and for the file checksum as distributed by Debian:

less SHA512SUMS | grep *iso
ec69e4bfceca56222e6e81766bf235596171afe19d47c20120783c1644f72dc605d341714751341051518b0b322d6c84e9de997815e0c74f525c66f9d9eb4295  debian-10.4.0-amd64-netinst.iso


and they match! 

As ever, I hope this blog post will help somebody.

[Edit: Someone has kindly pointed out that grep *iso SHA512SUMS | sha512sum -c will check this more efficiently.]