Length of ghs tokens increasing

[jharmon-gilead]

GitHub has started to roll out app tokens that are longer and break the validate_gh_pat() check.

gh/R/gh_token.R

Lines 93 to 116 in e9194ae

	if (
	x == "" ||
	# https://github.blog/changelog/2021-03-04-authentication-token-format-updates/
	# Fine grained tokens start with "github_pat_".
	# https://github.blog/changelog/2022-10-18-introducing-fine-grained-personal-access-tokens/
	grepl(
	"^(gh[pousr]_[A-Za-z0-9_]{36,251}|github_pat_[A-Za-z0-9_]{36,244})$",
	x
	) ||
	grepl("^[[:xdigit:]]{40}$", x)
	) {
	x
	} else {
	url <- "https://gh.r-lib.org/articles/managing-personal-access-tokens.html"
	cli::cli_abort(c(
	"Invalid GitHub PAT format",
	"i" = "A GitHub PAT must have one of three forms:",
	"*" = "40 hexadecimal digits (older PATs)",
	"*" = "A 'ghp_' prefix followed by 36 to 251 more characters (newer PATs)",
	"*" = "A 'github_pat_' prefix followed by 36 to 244 more characters (fine-grained PATs)",
	"i" = "Read more at {.url {url}}."
	))
	}
	}

They say "The overall length of the tokens will be longer (520 characters) and will vary based on the data stored within it." The "" there is annoying, so I'm not sure EXACTLY what should be allowed, but something along these lines should work:

  if (
    x == "" ||
      # https://github.blog/changelog/2021-03-04-authentication-token-format-updates/
      # Fine grained tokens start with "github_pat_".
      # https://github.blog/changelog/2022-10-18-introducing-fine-grained-personal-access-tokens/
      grepl(
        "^(gh[pousr]_[A-Za-z0-9_]{36,251}|github_pat_[A-Za-z0-9_]{36,244}|ghs_[A-Za-z0-9_]+)$",
        x
      ) ||
      grepl("^[[:xdigit:]]{40}$", x)
  ) {
    x
  } else {
    url <- "https://gh.r-lib.org/articles/managing-personal-access-tokens.html"
    cli::cli_abort(c(
      "Invalid GitHub PAT format",
      "i" = "A GitHub PAT must have one of four forms:",
      "*" = "40 hexadecimal digits (older PATs)",
      "*" = "A 'ghp_' prefix followed by 36 to 251 more characters (newer PATs)",
      "*" = "A `ghs_` prefix followed by about 500 characters (GitHub App installation tokens)",
      "*" = "A 'github_pat_' prefix followed by 36 to 244 more characters (fine-grained PATs)",
      "i" = "Read more at {.url {url}}."
    ))
  }
}

I'm seeing sporadic failures on GitHub Actions that look like they are caused by this.

I'll submit a PR shortly.

[jeroen]

FYI https://github.blog/changelog/2026-04-24-notice-about-upcoming-new-format-for-github-app-installation-tokens/ suggest we remove the validation alltogether:

It’s recommended that you treat tokens as opaque strings and avoid validating them against hardcoded patterns.
To help prepare for this change, ensure that:

• Your apps do not take a dependency on access tokens being a certain length.
• There are no regexes in your codebase such as ghs_[A-Za-z0-9]{36} that validate a token. These may not match the new tokens.
• Any database columns for access tokens can fit at least a 520 character string.

[jharmon-gilead]

It's probably still worth checking that it isn't empty, and at least at the moment the starting strings seem valid... but it probably wouldn't hurt to remove it entirely. I know my actions have been less finicky since I pointed at my version from #232 in the repo that was failing sporadically, at least, so lowered validation helps.

[mpadge]

I think at least skipping validation on GitHub actions (via envvar) would be important. As is, validating a key of potentially unknown format issued by GitHub while on GitHub requires assuming things only they can ultimately know and determine. Skipping validation there would at least remove susceptibility to their whims.

[mpadge]

@gaborcsardi Can you please get this on CRAN asap? We at rOpenSci have a heap of workflows for our daily updates that all rely on org-wide tokens. Most of them currently fail due to this issue, and dependence on this package is only indirect, so a lot of work to pull in this dev version instead of CRAN. That'd be hugely appreciated - thanks!