Security note: all the releases are signed. You can even check that the files JS and CSS file in the plugin match the ones uploaded in release pages. Thanks to @ku1ik for providing these files directly!

Updating in Hugo

As usual to get the latest version the player on your website, you can run:

hugo mod get -u cj.rs/gohugo-asciinema

Changelogs

Here is the changelogs in the upstream Asciinema player for the updated versions:

• 3.7.0
• 3.6.4
• 3.6.3
• 3.6.2
• 3.6.1
• 3.5.0
• 3.4.0
• 3.3.0

Delay Updating the CSS and JS Files

I apologize for the delay in updating those versions in my Hugo module. I do have alerts set up when a new version comes in but I’m still testing manually to make sure that the updated version works well. This Hugo module being a side-project, I did not get the chance to do the testing any earlier. I’ve tested all those versions against various pages of my website, and it all worked well. But please feel free to report any problem you may encounter.

Moving forward, I’ll rely on a script to automate the bulk of the update, that should help updating only a few days after the release. That script is not perfect and will be improved incrementally.

Since this is a release related to Asciinema, here is an asciicast of that new script downloading the latest CSS and JS, making a commit and tagging it.

Please feel free to use this script and open a PR if you spot an update before I do in the future 😁.

I’m now signing my git commit and tags with an SSH key. Details of the fingerprint can be found in the security document. It says that commit after 2024-01-01 are going to be signed, because I’m starting now on one machine and I will propagate the configuration over the next few days to other machines.

Why

Why bother with cryptographic signatures?
Anyone can pretend to be me. They just need to write my name and email in the author fields of a commit message. However¹, I’m the only one able to produce signatures with that particular public key. This will help to check that I’m actually the author of the commits and tags you rely on when using my code.

I’m doing it only now because GPG can be quite hard to use, especially with multiple machines. So I had to wait for the SSH signing scheme in Git to be supported more widely.

Verification

Code Hosting Platforms

GitHub will check this, adding a “verified” badge like this:

Codeberg shows similar badges.

Locally

Signatures can of course also be verified locally. This blog post explains in details how to do it.
TL;DR: populate a file (allowed_signers) with trusted keys, configures git to use it and then commands like git log --show-signature will check that signatures are valid for each commit.

Caveats

I wrote earlier that I was the only one able to generate this signature for this particular public key. This is true only as long as the corresponding secret key remains secret. I’m using a strong password to encrypt that key on my disk and that password is accessible only by physically touching a Yubikey. This goes a long way towards preventing the private key leaking. However, it is still possible for an attacker taking full control of my machine for extended periods of time to intercept that password and to decipher the secret key with it. Then, they will be able to produce signatures as if they were me. It would be a bit harder for the attacker if the SSH key was on the Yubikey, but then it becomes tricky to work on multiple machines. So that’s the setup for now, a compromise between potentially higher level of security and usability so that I actually use it.

Currently, I’m not signing release artifacts, but I might in the future. GPG is more common for this, but it’s very hard to maintain long term GPG keys. With this allowed_signers SSH file, rotating keys seems easier, so I’m more likely to do it more often and limit risks. I’ll try with only commit and tag signing first. Then I’ll apply the learnings to sign release artefacts.

EDIT(2023-12-31): This blog post describes the various options to sign commits very well, in particular talking about revocation scenarios. It was written shortly after I wrote this piece. I mostly agree with the author, but I think that SSH is a good middle ground: revocation works very well locally, it can be paired with Yubikey verification and it’s already supported by code hosting providers, without pesky OpenID verifications like gitsign.