From 30d2be97cc6ef2c49f7abac3598a473dff432461 Mon Sep 17 00:00:00 2001 From: Adriaan de Groot Date: Mon, 1 Apr 2024 17:13:44 +0200 Subject: [PATCH] Comment on release-process --- _posts/2024-04-01-calamares-and-xz.md | 75 +++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 _posts/2024-04-01-calamares-and-xz.md diff --git a/_posts/2024-04-01-calamares-and-xz.md b/_posts/2024-04-01-calamares-and-xz.md new file mode 100644 index 0000000000000..eba5cb5df6cc0 --- /dev/null +++ b/_posts/2024-04-01-calamares-and-xz.md @@ -0,0 +1,75 @@ +--- +published: true +layout: post +title: "Calamares and xz" +excerpt_separator: +--- + +Calamares does not use _xz_ directly, and Calamares isn't _sshd_, +so the attack against _xz_ does not affect Calamares directly. +It is worthwhile, though, to reflect on how Calamares development +and releases happen, and what we can learn from the attack against _xz_. + + + +## Release Tarballs + +Calamares produces separate release tarballs, and encourages you +to use those instead of the GitHub (yes, Calamares is still on GitHub) +automatic tarballs. This is **exactly the attack vector** against _xz_. +So what should we do with the tarballs? + +The [releases](https://github.com/calamares/calamares/releases) page lists +all Calamares releases. Each release has an attached tarball (generated +by Adriaan de Groot) and a GPG signature (generated by Adriaan de Groot). +There are also the automatic zip and tarball archives that GitHub provides. +Each release mentions a SHA256 (of the tarball) and a GPG signing key. + +The release tarball is made by running `git export`. You can find the +command in the script `ci/RELEASE.sh` which is what gets used to +create the tarballs in the first place. + +In other words: the tarballs **must** be reproduced exactly by +a `git export` command. This may be slightly different from the automatic +archives, which can change if GitHub decides to spit out a different +format (unlikely as that is). + + +## Verifying Release Tarballs + +Suppose we go back to [Calamares 3.2.46](https://github.com/calamares/calamares/releases/tag/v3.2.46) +from November 2011. The release metadata says: + +``` +SHA256: 8ceba247e0c94702284be42f8c003c12a364140dddd36ac03163418ea2b22138 +Signing key: 86B8EDB6ED8E3F96A9BAECB5CFDDC96F12B1915C +``` + +There have been various signing keys used over the years in Calamares. +I have generally used signing keys with an expiry date, although that +makes this one a little harder to verify. The key is still in +[Adriaan de Groot's public key](https://euroquis.nl/doc/pubkey.asc), although it expired in 2022: + +``` +sub rsa3072/0xCFDDC96F12B1915C + created: 2020-07-11 expired: 2022-01-02 usage: S +``` + +Anyway, if you fetch the tarball, the signature, and the automatic tarball, +then you can use `sha256sum` and `gpg` to verify the integrity of those +artifacts. + +- Both the automatic tarball and the release tarball have the **same** SHA256. + This is because both are created from the exact same git tree with the + same `git export` command. It also matches the published SHA256. +- Both the automatic tarball and the release tarball pass signature verification + with the attached GPG signature. GPG does warn about the expired signing key, + and this is expected. + + +## Tarballs in Future + +Although the hand-rolled tarballs don't provide any value over the automatic +tarballs **right now**, there are no plans to stop rolling them. +They are reproducible from the git repository. If you find a mis-matched tarball, +then we want to know.