It's pretty stupid that you could neither name a #GPG key registered to #GitLab, or see which may have expired. My key has expired, I've renewed it locally, and now am updating it on both #GitHub and GitLab.
On GH, it's easy to know which key I'd have to replace since it lets you know which of them has expired, and when registering it for the first time, you have to give it an identifier. On GL, there's no (human) identifier whatsoever, and it doesn't tell you which of them has expired either.
Better find a way to identify it correctly tho or you might risk deleting the wrong GPG key, and potentially cause your verified commits to be deemed unverified.
---
Edit: Figured it out. When you list your GPG key on your system like this:
gpg --list-secret-keys --keyid-format long
and get something like this:
/home/user/.gnupg/pubring.kbx
------------------------------
sec ed25519/1H89FHO4MGAJTJ9Z 2024-01-15 [SC] [expires: 2026-01-15]
0A41C9F6335DBF47A1A186FAC82F22229FCCE1BF
While on GH, you can identify your key either through the 1) name you gave it or 2) the "short key" i.e. 1H89FHO4MGAJTJ9Z, on GL you identify it through its "long key" i.e.
0A41C9F6335DBF47....
Likewise, on GH, it tags each "Key ID" and "Subkey" as
Expired if they're expired - easy enough to understand, meanwhile on GL, it tags valid, non-expired keys as
Verified, which may be somewhat confusing or vague.. especially when users coming into this setting is either adding a new GPG key or renewing an outdated one.
vault-crypt is live
Bash-based. No dependencies. No noise.
https://github.com/DeadSwitch404/vault-crypt
(plz hire me) 
Sid
/
) 
