Comment on release-process

_posts/2024-04-01-calamares-and-xz.md

@@ -0,0 +1,75 @@
+---
+published: true
+layout: post
+title: "Calamares and xz"
+excerpt_separator: <!--more-->
+---
+
+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_.
+
+<!--more-->
+
+## 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.