Comment by account42
2 years ago
Disagree. This is obviously a deliberate design choice with obvious implications. Expecting a bounty for reporting this is unreasonable. These kind of beg bounties are exactly what gives security "researchers" a bad name.
The security implications are also minor. The only problem really is with making a fork of a private repo public - that should only make what exists in that fork public and not any other objects. Something that was already public staying public even when you delete it from your repo is not a security issue at all. Keys you have ever been pushed to a public repo should be revoked no matter what, with or without this GitGub feature.
I wasn't really expecting a bounty, more so hoping they'd fix the issue. For example, to this day I keep having to tell people to never fork the Unreal Engine repository, instead making a manual copy, just in case.
This causes lots of problems for repositories that are private with the expectation that companies will make private forks with their own private changes.
Someone once pushed a bunch of console SDKs (under strict NDA) to a private fork without knowing this. Now that code is just there, if you can guess the commit hash, forever. Literally nothing can be done to remove it. Great.
I reported a variant of this issue that (to me) was unexpected:
* You add someone to your private repo.
* After some time, you revoke their access.
As long as they keep a fork (which you can't control) they can use this same method to access new commits on the repo and commits from other private forks.
Back in 2018, this was a resolved as won't fix, but it also wasn't documented.