Add script/ci pipeline for key expiration checking

This script will return 1 if any user keys are expiring within two months' time. This was added in a separate contrib/ directory rather than including as a Makefile target because the shell would otherwise get quite messy-looking for Make-isms.

The CI pipeline has also been altered so that the routine checks for keys will only run on an automated pipeline and will be ignored for regular checks since we don't want development to be stalled due to someone's key expiring.

Fixes #4

This checks the keys from pacman's keyring, not from the repository. So...

• This fails completely if the host does not have pacman and it's keyring installed.
• Does not reflect changes in the repository. Failures are resolved only on update of package archlinux-keyring.

I was following your very own suggestion!

It's not the business of the script to be initializing the keyring/pacman, so I don't consider that an issue.

As far as changes in the repo, this certainly could be improved to use keyringctl et al but this is a now solution that could be used.

Updates should be happening routinely on the _/archlinux Docker image, right? So that's not an issue.

That suggestion was before we had keyringctl I think.

Don't get me wrong... This is still very helpful and your work is much appreciated!

However adding a pipeline does not give much benefit. The pipeline should recover once keys with extended lifetime are merged into master.

Also having latest archlinux-keyring in the docker container does not help here. That still does not reflect the actual state of the repository's master state. (I have to admit that having a system without pacman and its keyring is a very theoretical issue. )

Nice work! :) I'm not sure how useful a failed pipeline is tho, as no one is notified (see upstream issue).

Maybe the script should create a issue (API doc) and tag the relevant people?

Good idea! However, I fear that not all staff have a Gitlab account/associated email address. There's also no way to be certain of a username based solely on the key ID. I feel the only "proper" way would be to shoot off an email to the key ID's contact. However, I just wanted to make sure this wasn't offensively bad first and just simply fail the build. A second MR could remove the failure state and (somehow) shoot off a mail.

However, I fear that not all staff have a Gitlab account/associated email address.

Creating a GitLab account is basically a requirement for on-boarding these days, perhaps there is some older staff without a GitLab account, but that is solvable.

There's also no way to be certain of a username based solely on the key ID.

We can solve that with a mapping file if needed.

I feel the only "proper" way would be to shoot off an email to the key ID's contact.

One downside of that approach is that it is difficult to track. Ex: How do the packager communicate if they can't renew the key for whatever reason (travel etc.).

However, I just wanted to make sure this wasn't offensively bad first and just simply fail the build. A second MR could remove the failure state and (somehow) shoot off a mail.

+1 for a iterative approach :)

mentioned in issue #4

I'll close this, as I plan on implementing this in the context of what I'm doing in upstream sequoia for https://gitlab.com/sequoia-pgp/sequoia/-/issues/809 Those changes will allow us to more easily find soon outdated keys using sq inspect.

Thanks for looking into this either way!

closed

mentioned in merge request dbscripts!53 (closed)