narc-Ontakac2
commented
1 year ago The secret WORKFLOW_TAGGING is obsolete. After rethinking that I found that the benefit (each build sets a marker tag) is not worth the risk (workflows can write workflows).
Furthermore I realized that of course everybody can create a signing key, it does not have to be me :-) So I'll give a short writeup on how to do this.
If possible the secrets should be on organization level. This way they can be used for vzlogger and libsml. The secrets live in an enviroment, the name I would prefer is main.
The first step is to create the SIGNING_PASSPHRASE. This protects the key, which makes sence because the key is written to the disk of the build system while the passphrase is not. The passphrase should be long, e.g. 30 characters. Nobody will ever have to enter that manually. An option for creating it is apg, but any reasonable password generator will do.
The signing key is generated with
gpg --full-generate-keyIt will ask you for a several things. Use 4096 RSA. My current key is this:
pub rsa4096 2023-01-28 [SC] [verfällt: 2026-01-27]
DB3F996D35A1EE0DA3FCCFED12672035D0F1058A
uid [ ultimativ ] Joachim Zobel (This key is used for automatic signing from build scripts and not as secure as a debian developer key) <jz-autosign@heute-morgen>
sub rsa4096 2023-01-28 [E] [verfällt: 2026-01-27]I think it makes sense to use my name, as I do the packaging. Every email of the form jz-*@heute-morgen.de is an alias for míne. The part in brackets after the name is entered as a comment. It really should be there.
An expiration date should not be to far in the future (mine has 3 years).
The actual SIGNING_KEY value is the exported from the key ring with
gpg --export-secret-key --armor <key-id>The SIGNING_KEY_ID is also added as a secret (although it is not) to have all three values in one place.
The public key can be published to keyservers:
gpg --send-keys --keyserver pgp.mit.edu <key-id>```
This adds a release workflow that creates Debian packages for several platforms (currently amd64, armhf and arm64).
It does need multiple secrets for package signing. These are SIGNING_KEY, SIGNING_KEY_ID (not really a secret), SIGNING_PASSPHRASE and WORGFLOW_TAGGING. Workflow tagging is a token with the special permission to modify workflows. This is unfortunately needed to mark the release (which includes the workflows) with a tag. I will need administrator permissions (preferrably on the volkszaehler organisation level) to create these. There are other ways, this way it can however be done without transferring the secret key.
Note that this uses the version at the head of the changelog as the leading version value.
I have added sed oneliners to debian/rules to keep the version numbers in sml.pc and library.json in sync. What are these files used for?