Could you please revert recent token changes which break existing tokens!?

General
1

I am using hosted version of Gitlab and recent update set expiration date of 1 year to all existing tokens. ( Deprecation announcement for non expiring access tokens (!96594) · Merge requests · GitLab.org / GitLab · GitLab Populate default expiration and pre-select least privilege scopes when creating new access tokens (#348660) · Issues · GitLab.org / GitLab · GitLab )

Why break things? Github allows you to make never-expire tokens. We use tokens to automate many things. After 1 year, it is GUARANTTEED to get things broken. WHY make people do unnecessary work anyway?

Suggestion:

  1. Let people make never-expire token!!
    2.Or at least… Make the token expire after 1 year AFTER INACTIVITY. When there is an activity DO NOT EXPIRE IT in the first place!!!
2 Likes
2

Please avoid shouting (caps lock) to keep the discussion civil and welcoming. I’d also suggest changing the username.

Tokens without expiry date pose a security risk, and tokens used for automation are one of the attack targets from malicious actors.

GitLab will send notifications about tokens that will be expiring. Notification emails | GitLab You can setup monitoring for automation tokens that check the expiry date. For example, the GitLab API provides endpoints to list personal/project/group access tokens where the response contains the expires_at field.

  1. Project access tokens API | GitLab
  2. Group access tokens API | GitLab
  3. Personal access tokens API | GitLab

Using python-gitlab, admins can automate the checks to e.g. weekly reports about token expiry and take action for production critical environments. More tips for security considerations in GitLab Token overview | GitLab

For additional feedback, I’d suggest commenting directly into the deprecation issue Deprecate non-expiring access tokens (#369122) · Issues · GitLab.org / GitLab · GitLab

1 Like