Trisquel 11 signing key

That seems to be correct. The Trisquel wiki page for verifying downloads seems to have been updated recently to include the new key you mention:

"Trisquel's images are signed with the main key B138CA450C05112F or at Aramo's release with F5DAAAF74AD4C938."
https://trisquel.info/en/wiki/verify-trisquel-download

The comment attached to the new key (11/aramo) suggests that a different signing key will be used for Trisquel 12, maybe another new key or going back to the main key, but I don't know if this is the intention.

As far as I can tell, the new key used for Aramo is self-signed only. In my opinion it would be nice to see it also signed by the main key.

You can confirm by using,

curl -s https://cdimage.trisquel.info/trisquel-images/trisquel-archive-signkey.gpg | gpg --show-keys --with-fingerprint

Regards

Hi Ark, I downloaded the signing keys from the URL you gave. It seems to me that the new key used for Aramo is only self-signed. I'm wondering why the new key is not signed by the main key which was used previously?

The new key's been added into the APT repository for Trisquel 10 as part of the nabia-updates repository and by doing so that means the key has been signed by the old one key, letting a chain of trust be established.

What we know so far:
Old key: 60364C9869F92450421F0C22B138CA450C05112F
New key: D24DDAC9226D5BA5E9F3BED3F5DAAAF74AD4C938

To demonstrate:

wget https://archive.trisquel.org/trisquel/pool/main/t/trisquel-keyring/trisquel-keyring_2023.02.07_all.deb
sha256sum trisquel-keyring_2023.02.07_all.deb
7414bc52cf2e71b148ee6fa0aff18a4c42a26cf0de98286b745c1da00e8e335b trisquel-keyring_2023.02.07_all.deb

wget https://archive.trisquel.org/trisquel/dists/nabia-updates/main/binary-amd64/Packages
Verify that you do find that hash within the file for trisquel-keyring_2023.02.07_all.deb within there:

Package: trisquel-keyring
Version: 2023.02.07
Architecture: all
Maintainer: Rubén Rodríguez <name at domain>
Installed-Size: 22
Depends: gnupg (>= 1.0.6-4)
Priority: important
Section: misc
Filename: pool/main/t/trisquel-keyring/trisquel-keyring_2023.02.07_all.deb
Size: 5832
SHA256: 7414bc52cf2e71b148ee6fa0aff18a4c42a26cf0de98286b745c1da00e8e335b
SHA1: 22cdbc387ba0861a231c7fcc03ddf11c45d8b78c
MD5sum: 23c1a71277d3bea92e82d05626818157
Description: GnuPG keys of the Trisquel archive
The Trisquel project digitally signs its Release files. This package
contains the archive keys used for that.

Compute the sha256sum of the Packages file:
04fa482560b1772af64a49de7d06d2d5730f474185dfa881a940320629679622 Packages

Note that this is what I get at the time of writing this message; it's possible that your may be different if there are changes made to the nabia-updates repository. It's not important if your hash matches mine or not though - Just that you determine what it is.

Then download the Release file for the
wget https://archive.trisquel.org/trisquel/dists/nabia-updates/Release
For whatever hash you computed of the Packages file, verify that it's present in this file under nabia-updates.

The release files for Trisquel 10 are signed with the prior key:
wget https://archive.trisquel.org/trisquel/dists/nabia-updates/Release.gpg

And, if you have the prior key, you can then proceed to verify the signature using that key in the same way as normal, to whatever extent you trust the prior key:

gpg --verify Release.gpg Release
gpg: Signature made Fri 31 Mar 2023 11:21:51 AM PDT
gpg: using RSA key 60364C9869F92450421F0C22B138CA450C05112F
gpg: Good signature from "Trisquel GNU/Linux <name at domain>" [unknown]

This, by the way, are the steps that the package manager takes when verifying things.

Technically it's a GPG signature on a hash of a hash of the key and could, in theory, mean that the package manager's security model is vulnerable to hash collisions should someone find a way to either make a different .deb with the same hash or a Packages file with their own hash that still has the same hash as the one mentioned in the Release file. But this is the same steps that the package manager takes when verifying things; the packages themselves aren't directly GPG signed. I think it's a limitation in the package manager and maybe the .deb package format in general but as far as I know there aren't known vulnerabilities in SHA-2 that would allow for someone to very easily make make their own hash collision at present. And, if something is found in the future, hopefully the package manager will have moved on to something else like SHA-3 by then.

Nice explanation, that clears it up!