GitHub: Packages support for fine-grained PATs | Hacker News Reader

GitHub: Packages support for fine-grained PATs

github.com

Presumably this means the new finely-grained PATs? https://docs.github.com/en/authentication/keeping-your-accou...

The annoying thing about those is that they force you to set an expiration date, with a maximum of one year from today.

For most of the things I need a PAT for this is a big frustration. I want to set up things like cron jobs that access specific data from specific repos - but I really don't want to have to remember to go and grant them a new token every 365 days.

Older PATs don't have this problem, which means I'm incentivized to continue using those even though they are much less secure because they grant a wider scope.

I want unlimited expiration on finely grained tokens.

My ideal implementation would include both easy revocation and good audit logging - I want to know when the token was last used, but ideally I'd like to know what it was used for and have details of where that request came from (I guess IP address would have to do for that). That way if my token leaks I can revoke it and analyze what happened using the audit log.

I just found this roadmap item relating to this: https://github.com/github/roadmap/issues/599 - "Fine-grained PAT expiry policies for organizations"

It talks about letting organizations set a policy saying "no token lasts more than X months" - I'd love it if this could expand to "... or set a policy that says unlimited tokens are allowed", since then I could set that for my own organizations and stop complaining about this!

That’s a lot of words to say “I want to continue shooting myself in the foot, please!” Your complaining makes out like you’re powerless to stop yourself from using legacy PATs. You’re not. You could just suck it up and spend the time doing the very low effort high reward activity of rotating your keys. There’s a reason why every security posture determination questionnaire under the sun asks about key rotation. It’s because old keys lingering around is a very material security issue in practice. GitHub emails you when a fine-grained PAT is about to expire. Repeatedly. If you forget, then presumably your actual automations are going to stop working. And to be blunt, if it gets to that point (e.g. you don’t act on repeated emails, or your cron monitoring isn’t such that you’re told about about things failing) then it sounds like you have bigger problems. You long for increased audit logging (have you actually looked at what’s already available!?). Audit logging is only so useful because it tells you what already happened, and you have to actually either notice that your key has been compromised, or be proactively monitoring your audit logs. Are you telling me that you’ve managed to carve out the time in your day for this, but you can’t rotate your keys once a year?

I have great sympathy for GitHub’s position and have been in similar ones. Your customer’s security is always, to varying degrees, your problem. I’ve got no doubt that this explicit design choice is in response to support requests, and that it informed by their real-world experiences re attack vectors related to PATs. The problem is that every developer always wants to hit the “no, I’m special, let me do this” button.

I have too many things to do in my life and too little time to do it in. For my personal stuff, I'm fine with fully automated key rotation but I'm not going to do it manually, just as I don't rotate my SSH keys. (For businesses, yes, it makes sense.)

I fully agree! I know the risks, but for personal projects I really don’t want to think about having to rotate my keys.

(I found this comment useful, thanks.)

This is why I'd like this to be an organizational setting.

When I'm working in a business setting I'm fine with operational overhead like having to rotate keys.

For personal projects I want to be able to set something up with the minimum scoped permissions possible and then leave it running.

I am part of a few projects where for organizational reasons (e.g. corporate-community partnerships), we use `repository_dispatch` to trigger builds across repositories. PATs are great here, as they can be scoped down to single repos and permissions.

There is a miniscule attack vector from using PATs here (maximum someone could do is trigger many GH Actions builds, but they also could do that otherwise), and to rotate the PAT, two people have to coordinate (as the origin repo has tighter permissions), and even though docs exist in the repo for how to rotate them, as it's a rare task people didn't find them the first year (second year is still coming up). For that use-case I'd greatly appreciate if PATs would exist that have a longer/no expiry.

It would be a bit complicated to implement and explain to end-users, but maybe there's a path here where you're allowed to set unexpiring tokens but only if the scopes they have are tightened beyond a specific level?

A system that says "sure, you can have a token that doesn't expire if all you are doing is repository_dispatch" would be really useful to me too.

The gold standard is to have these tokens be emphermal and have them be issued my something like https://github.com/martinbaillie/vault-plugin-secrets-github. You should never rely on manually rotating tokens, it's 2024 and we have decades of production outages due to expired certs to prove that this stuff needs to be automated. Having mandatory expiration is a great way to incentivize users to do the right thing here.

IMO, the right way is for GitHub to allow for JWT/OIDC federation, ideally allowing custom public keys to be uploaded, so I can issue my own tokens from a secure crypto source. With the GitHub app, you're still copying/pasting long lived tokens during the setup phase.

If I want my random DigitalOcean VPS to have access to an account elsewhere, it's going to need a secret of some sort. If it gets issued ephemeral secrets from something like Vault it still needs to be able to identify itself to Vault as "I'm DigitalOcean VPS ID=32443 and I need a 1 hour secret to access this GitHub repo".

Eventually, something needs to have a non-expiring secret to help identify it.

The more complicated we make this stuff the more chance someone will make a mistake in configuring it and open themselves up to a breach.

I’m not familiar with DO but one approach to the secret zero thing that works elsewhere is the VPS gets assigned an OIDC identity by the provider (or the VPS has access to one if it asks). That identity is in turn used to sign in to Vault.

This is such a pain in the ass/security nightmare because without this you have to grant full read/write on your repositories using classic tokens.

I'm not sure why this was posted, but I assumed that it's because it's a very basic feature that's been on the roadmap for over 2 years with no progress?

Is there a new update? Has it been shipped? It doesn't look like it

Reply on news.ycombinator.com