5 ms·

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 u

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.

sunshowers 2y ago
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.)
- gladwindos 2y ago
  I fully agree! I know the risks, but for personal projects I really don’t want to think about having to rotate my keys.
simonw 2y ago
(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.
hobofan 2y ago
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.
- simonw 2y ago
  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.

sunshowers 2y ago

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.)

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

simonw 2y ago

(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.

hobofan 2y ago

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.

simonw 2y ago
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.