GitLab recently introduced a maximum lifetime for *all* access
tokens. The change is discussed in a [blog post][1] from last
October. Most importantly:
As of the 16.0 milestone (May 2023), we applied an expiration date of
May 14, 2024, to any personal, group, or project access token that
previously didn't have one.
We first noticed this issue in [January][2] and have looked at
mitigations, but ultimately, there's no good workaround short of
"service accounts" which is some Open Core thing they are pushing onto
us. There's some work upstream to make it easier to rotate tokens (which
make the entire security measure moot in the first place, fun).
So anyways. Your things might break now. And when you recreate the
tokens, they will still have an upper time limit (one year, IIRC), so
you will need to fix this again and again.
I'm sorry. Further discussion in [2]. For now our approach is wait and
see what gitlab.com is going to do, because this is breaking a *lot* of
things in a lot of places, and I can't imagine they will just let the
thing burn for that long. The actual recommended workaround from
upstream now is to have a *pair* of tokens that renew each other but we
have found that to be really impractical.
So for now, we're just trying to document the tokens we have and how to
refresh them, as an immediate mitigation. I encourage you to pay
attention to the "your token has expired" notification as well.
At least one person asked "wait, does this affect me? what is this?", so
let me clarify a bit.
If you don't know what a personal access token is, you are likely not
affected and can disregard this.
If you're not sure, and everything is still working, you're likely not
affected. A precaution might be to look at your projects continuous
integration (CI) pipelines to see if they are still green, consider
running scheduled pipelines manually to see if they break.
If you don't know what CI is, you're likely not affected.
If you want to audit your projects thoroughly, you can use an audit
script I wrote:
it will show you projects with private tokens (before they are expired
AKA destroyed) and secret project variables that *might* be backed by
tokens.
So remember last May, we all had to jump to fix access tokens in GitLab
because they suddenly started expiring?
No? Well, ignore this message this message then, whoohoo, lucky you.
Yes? Or you've forgotten about this and are thinking "oh shoot, is this
still a thing OMG WILL EVERYTHING BREAK?"
Well, I got you covered. We just upgraded to the shiny new GitLab 17.4
and it has an option to disable maximum expiry dates for access tokens.
So I disabled enforced expiry dates on gitlab.torproject.org.
Note that you will most likely *still* have tokens expiring, and will
very likely require my script below to figure out how to deal with this.
The next catastrophe for this is scheduled in May 2025, because that's
when the tokens we fixed in May 2024 will expire.
But hopefully now you have a way to fix this issue forever.
See also:
Have a good weekend!
a.
···
On 2024-05-29 12:09:02, Antoine Beaupré wrote:
At least one person asked "wait, does this affect me? what is this?", so
let me clarify a bit.
If you don't know what a personal access token is, you are likely not
affected and can disregard this.
If you're not sure, and everything is still working, you're likely not
affected. A precaution might be to look at your projects continuous
integration (CI) pipelines to see if they are still green, consider
running scheduled pipelines manually to see if they break.
If you don't know what CI is, you're likely not affected.
If you want to audit your projects thoroughly, you can use an audit
script I wrote:
--
Antoine Beaupré
torproject.org system administration
_______________________________________________
tor-project mailing list
tor-project@lists.torproject.org tor-project Info Page