Fortran-lang machine user GitHub account for commit signing

I am posting this here mostly because it has to do with the Fortran-lang GitHub Organisation as a whole.

The VS Code extension in Fortran-lang as part of it’s publishing process should update the version listed in package.json to match that of the GitHub Release and its git ref/tag. These commits should try and be signed since they touch the normal git history, the git tags and the published vscode extension. Unfortunately, GitHub does not offer signed commits Support Signed Commits by · Issue #667 · actions/runner · GitHub via Actions and it does not look like is going to fix that, which means we have to do it ourselves.

The easy way of doing this is for an individual to upload a personal GPG key as a secret and use it to sign commits within GitHub Actions. However, that creates the security problem since any maintainer not just the GPG key owner would be able to sign commits using with that key.

Alternatively, we can create a machine user for Fortran-lang and upload a GPG key for that user as an organisation level secret. Individual repos would then use the machine user’s credentials to sign commits.

This brings me to my question, should Fortran-lang create a machine account for CI and automation tasks? Is that something other existing Fortran-lang projects could use?

What do you want to convey with a signed commit or signed tag?

As a starting point for learning about signing messages, commits, etc., I found Kernel Maintainer PGP guide — The Linux Kernel documentation to be a valuable resource. Following their motivation, having an automated signing process, seems like putting trust in the wrong place, i.e. the hosting infrastructure, rather than the developers.

Although I do get why in most cases it’s pointless to sign automated commits (I remember reading that same doc a few years back), in the case of authoring software releases I think it’s valuable for users to be able to authenticate that the release was created via Fortran-lang or one of the repos maintainers.

This is a nice to have feature of keeping our Release commits and tags signed, while also allowing us to use common npm tools in the process (npm version, npm update, etc.)

If you checkout the release history of fpm (Releases · fortran-lang/fpm · GitHub), you will find that all (release) commits are signed, and they are actually signed with GitHub’s key, meaning they were created in the web interface (for example by squash and merge / create merge commit from a PR). With the common development strategy we are using in the Fortran-lang projects this is likely to be the case for any release published so far.

But note that none of the tags are actually signed, however it can be done by signing them locally and than pushing them to GitHub. Funnily, GitHub doesn’t differentiate with the Verified badge whether only the commit or the tag or both are signed (check out Tags · dftbplus/mpifx · GitHub, where all three signing situation are present).

An example for creating signed artifacts via automation on GitHub is the MSYS2 package build. Eventually, the signing of all packages happens locally by a developer rather than as part of the automation process.

1 Like

Providing checksums with every release artifact could be a first step to allow verification of the provided artifacts. Signing them automatically doesn’t convey more information than having a SHA256 checksum in my opinion.

A more viable strategy would be to provide release artifacts with checksums and detached signatures and also discourage the usage of any automatically generate git-archives as they cannot be augmented with a checksum / signature. For this to be useful for verification purposes, a developer has to manually sign the released artifacts, further we have to establish trust for the developer keys by cross-signing them in the community.

1 Like

I think what the fpm current release is doing is quite close to what the vscode release should do. The main difference is that the vscode release needs to modify the tag after it has been created from GitHub’s web interface.

For completeness here is what should happen in a release:

  • Issue release from GitHub web interface, which creates a tag e.g. v4.0.0
  • On a Linux runner do:
    • npm ci
    • vsce publish --no-git-tag-version ${GITHUB_REF_NAME:1} This also updates package.json’s version to 4.0.0
    • git add package.json
    • git commit -S -m "ci: update package.json version"
    • git tag -f $GITHUB_REF_NAME
    • git push origin -f $GITHUB_REF_NAME This removes GitHub’s key (green badge)

It’s fine. If the vscode extension is the only one using npm to increment its version from our TS/JS projects I can do all the above manually and live with the fact that some commits will not be signed and that the green ticks will be missing from the release

An added benefit of having a machine user for the Fortran-lang is that we can exempt it from certain branch protection rules such as force pushes. Currently, if you want to have a branch protection rule that restricts force pushes to certain individuals or teams it is not possible to also have an Action that force pushes. I found out the hard way…