Github app tokens being conflated with personal access token

[sondrelg]

Created from @amoosbr's comment in the v3 issue:

Hi,
not sure if my question belongs to the v3 release or not.
Just wanted to let you know, about my experience, when I tried to use v3.0.0 with a GitHub App token.

Based on the README image-names section, I expected to use a GitHub App for cleanup a image name like bla/*
Readme snippet:

These operators are only available for personal- and GitHub app-tokens. See the token parameter section for more info.

Unfortunately, when I tried to use it as documented in the GitHub App token sample, I got the following response:

2024-07-29T09:34:18.768949Z DEBUG container_retention_policy: Logging initialized
2024-07-29T09:34:18.769670Z DEBUG parse input: container_retention_policy::cli::models: Recognized token as temporal token
2024-07-29T09:34:18.770018Z DEBUG parse input: container_retention_policy::client::builder: Constructing base urls
2024-07-29T09:34:18.770047Z DEBUG parse input: container_retention_policy::client::builder: Constructing HTTP headers
2024-07-29T09:34:18.770065Z DEBUG parse input: container_retention_policy::client::builder: Creating rate-limited services
2024-07-29T09:34:18.770328Z DEBUG fetch rate limit: container_retention_policy::client::client: Retrieving Github API rate limit
2024-07-29T09:34:18.842278Z DEBUG fetch rate limit: container_retention_policy::client::client: There are [15](https://github.com/bosch-adas-genai/actions/actions/runs/10141744949/job/28039764262#step:4:16)000 requests remaining in the rate limit
thread 'main' panicked at src/client/client.rs:46:17:
Restrictions in the Github API prevent us from listing packages when using a $GITHUB_TOKEN token. Because of this, filtering with '!' and '*' are not supported for this token type. Image name cache/* is therefore not valid.

Looking at the latest history, I saw a commit, that mentions GitHub App tokens behave like temporal tokens.
I tried using building and running the 3.0.0 release candidate, where the GitHub App tokens was not treated as temporal token. Then my GitHub App token didn't have the needed scopes:

The token does not have the scopes needed. Tokens need `read:packages` and `delete:packages`. The scopes found were none.

My GitHub App has packages:write permission and is installed on the org with access to all repositories. I didn't find a packages:delete option for GitHub Apps.

I'm not 100% sure, if I just used the action wrong or my App has wrong settings. But if it is not possible to have wildcard image names with GitHub App tokens, perhaps the README can be updated.

As soon as I switched to using a classical PAT, the workflow stated to work as expected.

Originally posted by @amoosbr in #84 (comment)

[sondrelg]

@amoosbr, this is the line you're hitting:

container-retention-policy/src/client/client.rs

Line 465 in 148a83b

eprintln!("The token does not have the scopes needed. Tokens need `delete:packages`. The scopes found were {}.", response_headers.x_oauth_scopes.unwrap_or("none".to_string()));

. It's possible we could just remove this check. It's mainly there so that users with personal access tokens without permissions, get a clearer error than the one they would get from making the request with lacking permissions. Since we're inferring the token type from the token prefix, I can't immediately think of a good way to differentiate between a classic PAT and an app token 🤔

[amoosbr]

I did some further test and I'm not able to list container packages using my GitHub App token.
Not sure, if it is at all possible to use an GitHub App to list packages or not.
At least I wasn't able to list any container packages via direct curl request to the GitHub API

# get token for GitHub App using: https://github.com/Link-/gh-token
❯ token=$(gh token generate --key /path/to/key.pem --app-id 111111 --installation-id 2222222)
❯ echo $token
{
  "token": "ghs_....",
  "expires_at": "2024-07-29T17:01:47Z",
  "permissions": {
    "contents": "read",
    "metadata": "read",
    "packages": "write"
  }
}

❯ token=$(jq -r ".token" <<< $token)

❯ curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $token" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  "https://api.github.com/orgs/ORG/packages?package_type=container"
{
  "message": "Invalid argument.",
  "documentation_url": "https://docs.github.com/rest/packages/packages#list-packages-for-an-organization",
  "status": "400"
}

I also forked this repo and adjusted all temporal token checks and also got the same error response:

2024-07-29T15:11:35.381497Z DEBUG select packages: container_retention_policy::client::client: Fetching data from https://api.github.com/orgs/ORG/packages?package_type=container&per_page=100
thread 'main' panicked at src/client/client.rs:59:14:
Failed to fetch packages: Failed to deserialize paginated response: {"message":"Invalid argument.","documentation_url":"https://docs.github.com/rest/packages/packages#list-packages-for-an-organization","status":"400"}. The error was invalid type: map, expected a sequence at line 1 column 0.

Will stick with the PAT tokens until GitHub adjusts it's API.

[sondrelg]

There's a working example of a Github token being used, here: https://github.com/snok/container-retention-policy/blob/main/.github/workflows/live_test.yaml#L40:L59, so I think it should be possible. You do need to install the app into your org., and so on.

[ptab]

@sondrelg that specific test points to a single package name and not a wildcard, so that's likely why it works.

For what it's worth I can confirm what @amoosbr described: I am also unable to list all organization packages using a Github App token (using either this action or a direct curl request), while I can using a PAT with packages: write scope.

[JonasKs]

I've also confirmed with GitHub support that this is not possible:

GitHub Packages are only accessible to classic personal access tokens and to GitHub Actions through the GITHUB_TOKEN available on every workflow run. GitHub Apps can't delete package versions.

Our Docs erroneously indicate that the endpoints for packages work with GitHub App installation tokens but that is not yet possible, the Docs should soon be updated to reflect this.

While it is not supported at the moment, authentication to GitHub Packages using GitHub Apps is on Engineering's roadmap but I do not have a timeline for when that will be published, sorry.