You cannot block what someone commits (they can block it themselves with tools like gitleaks invoked on a pre-commit hook) so the only thing you can do as a 3rd party is to scan and react when you do notice a secret published.
GitHub certainly could block push requests, at least git itself can via hooks, there are a number of hooks invoked by git-receive-pack that can influence what it does.
But the commit still exists locally (since git is decentralized) so you now end up with a weird state that you have code you cannot push to origin. Definitely not a desirable feature.
> at least git itself can via hooks
I already said that:
> they can block it themselves with tools like gitleaks invoked on a pre-commit hook
The problem with git hooks is that they're not cloned with the repo. So you're reliant on the user installing those git hooks locally (sure, some repos will have helper scripts to install the hooks for you. But you're still reliant on the user running that script).
> code you cannot push to origin. Definitely not a desirable feature.
If there is data that shouldnever be pushed to origin, then it is a highly desirable feature that the server block pushes that include that private data.
> The problem with git hooks
I was talking about GitHub's own git hooks that run on their servers, not about any local ones.
> is that they're not cloned with the repo.
It would be a terrible security issue if they were automatically enabled after cloning.
> If there is data that should never be pushed to origin, then it is a highly desirable feature that the server block pushes that include that private data.
It’s already too late by that point because your secrets have already left the building. You’re not relying on upstream being honourable
> I was talking about GitHub's own git hooks that run on their servers, not about any local ones.
There’s no such thing. You can have CI tooling like GitHub Actions, but they’re a different beast to git hooks
> It would be a terrible security issue if they were automatically enabled after cloning.
It doesn’t have to be either/or. There are ways of having a sensible compromise. Like a git config that enables hooks from known safe origins. Or having the user promoted whether they want to install git hooks upon cloning.
True, but it is better than the secrets becoming entirely public, automated bots could be harvesting them and exploiting the resources they protect.
> There’s no such thing.
I would be surprised to here that GitHub doesn't actually run git on their servers. If they receive git pushes using git, then own git hooks are involved, ones that GitHub has written for their own purposes. They could simply add one to block bad pushes.
> Like a git config that enables hooks from known safe origins.
That sounds a bit terrifying to me, but I'm not of the GitHub generation.
> Or having the user promoted whether they want to install git hooks upon cloning.
That sounds like it would enable phishing-like attacks and people just clicking "yeah sure" without verifying the safety of the hook.
> True, but it is better than the secrets becoming entirely public, automated bots could be harvesting them and exploiting the resources they protect.
True. And some popular repos do already run into this problem. So it’s not a theoretical problem.
> I would be surprised to here that GitHub doesn't actually run git on their servers.
They’ve documented about how their backend works so there’s no need to speculate. They run an implementation of git but not the standard git CLI.
> If they receive git pushes using git, then own git hooks are involved, ones that GitHub has written for their own purposes. They could simply add one to block bad pushes.
They have their automation, GitHub Actions.
Sure they “could” also implement what you’ve described but it’s not how it currently works. So a pointless argument since we could be here all year discussing the literal infinity of different things Github “could” do in theory but that their infrastructure doesn’t currently support.
> That sounds a bit terrifying to me, but I'm not of the GitHub generation.
What I posted has literally nothing to do with GitHub. In fact if your origin is private git server (as I started out using git, since GitHub didn’t exist back then) then it’s even easier to designate a trusted origin. This approach makes total sense for businesses. Doesn’t work so well for open source but it’s just one option of many.
> That sounds like it would enable phishing-like attacks and people just clicking "yeah sure" without verifying the safety of the hook.
Potentially yes. But if you’re cloning a git repo, making code changes and then committing it back, you’d hope that individual is competent enough to audit the git hook. At the very least, they’ll be running the build scripts locally to unit test their changes, so it’s not like that phishing attack isn’t already present. Feels very much like you’re looking for reasons to dismiss any suggestions here rather than have an intelligent discussion.
