sign tarballs and static binaries with gpg for release

What

This MR adds gpg signature files for the tarballs and static binaries we release. These are different from the sha256 checksum files already present.

While sha256 gives a way to check then integrity of the binary artifacts, these are relatively easy to replace in a supply chain attack, where the attacker is able to modify the storage where the artifact is stored.

GPG signatures also need a secret key that is stored in the google vault allowing to mitigate this problem.

This MR focus on the binary artifacts. The deb and rpm packages are already signed and secured via apt/dnf.

Why

How

Manually testing the MR

To run a test release pipeline you need to tag this branch and push the tag on nomadic-labs/octez. Then you need to check if the gitlab_release job is correctly executed.

For example check this job: https://gitlab.com/nomadic-labs/tezos/-/jobs/10362770001

This is the release page for the static binaries : https://gitlab.com/nomadic-labs/tezos/-/packages/40587292

To test if the binary is correctly signed, download the binaries from the release page above and run :

$ gpg --show-keys scripts/packaging/package-signing-key.asc
pub   rsa3072 2024-01-17 [SC] [expires: 2026-01-17]
      B37EB972D5D275A243594ECACFC482F3CD08D36D
uid                      Nomadic Labs <info@nomadic-labs.com>
sub   rsa3072 2024-01-17 [E] [expired: 2025-01-16]

$ gpg --import scripts/packaging/package-signing-key.asc

$ gpg --verify ~/Downloads/arm64-octez-baker-PsRiotum.sig ~/Downloads/arm64-octez-baker-PsRiotum
gpg: Signature made Mon 16 Jun 2025 04:27:57 PM CEST
gpg:                using RSA key B37EB972D5D275A243594ECACFC482F3CD08D36D
gpg: Good signature from "Nomadic Labs <info@nomadic-labs.com>" [ultimate]

For official release the public key is located in https://packages.nomadic-labs.com/debian/octez.asc

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR