undefined

points

by stingraycharles11 hours ago |

comments

by eddythompson8010 hours ago|

[-]

But they explicitly setup the permissions this way.

by GuestFAUniverse9 hours ago|

parent|

[-]

Half the crowd using GitHub ever thought about plugins that have org wide access but /promise/ not to misuse it. And years ago that included a lot of popular plugins (my POV was that those were outright stupid) -- on par with Docker in standard configuration: brain dead, works on my laptop idiocracy.

I stopped disabling plugins from "managers" that overreached from their repos only to org wide years ago. While I liked a lot of people I worked with in that institution on a personal level, I was happy not having to work with them as devs, when that institution got closed.

Some nice people behave rather dumb when it comes to tech. And than comes AI and tramples along, because there are no boundaries (See the article what they are writing about /assumed/ security boundaries. They assume things so much, it becomes physical pain to read or listen to them.)

by NorthSouthNorth1 hours ago|

parent|

[-]

I also find this frustrating. Every time I want to add an app to Github, it defaults to org wide. So far, I've managed to keep the reins on that, and nobody has made a mistake, but I am just waiting for the day someone adds something org-wide that shouldn't be.

Another rant(ish). You can request a PAT for, say, 30 days for a repo, and if you don't have access, it'll prompt an admin to approve that PAT. Okay, makes sense. But then you can refresh that same token without permission going forward.

by _joel5 hours ago|

parent|

prev|

[-]

You give apps explicit access to repos (or the full org). If you chose full org, what do you expect?

by stingraycharles3 hours ago|

parent|

[-]

Giving an app full scope to all repos in an org does not automatically imply that it would leak information from private repo A in comments on public repo B. That’s the issue being discussed here.

Like I said earlier, I can see both points of view, and I think the answer is more granular scoped permissions (eg on a per-workflow basis). Right now the permissions are crude.