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

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!!!

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