Calamares and xz
Apr 1, 2024
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 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 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, 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 exportcommand. 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.