Anyone can access deleted and private repository data on GitHub
trufflesecurity.com
trufflesecurity.com
Here is their full response from back then:
> Thanks for the submission! We have reviewed your report and validated your findings. After internally assessing the finding we have determined it is a known low risk issue. We may make this functionality more strict in the future, but don't have anything to announce now. As a result, this is not eligible for reward under the Bug Bounty program.
> GitHub stores the parent repository along with forks in a "repository network". It is a known behavior that objects from one network member are readable via other network members. Blobs and commits are stored together, while refs are stored separately for each fork. This shared storage model is what allows for pull requests between members of the same network. When a repository's visibility changes (Eg. public->private) we remove it from the network to prevent private commits/blobs from being readable via another network member.
> A fork is a new repository that shares code and visibility settings with the upstream repository. All forks of public repositories are public. You cannot change the visibility of a fork.
[1] https://docs.github.com/en/pull-requests/collaborating-with-...
Edit: I popped this up because to me is absolutely miserable from a big company to just say: "Thanks, but we were aware of this".
https://docs.github.com/en/pull-requests/collaborating-with-...
I don't think they're being underhanded exactly... they're just making a terrible decision. Quoting from the article:
> The average user views the separation of private and public repositories as a security boundary, and understandably believes that any data located in a private repository cannot be accessed by public users. Unfortunately, as we documented above, that is not always true. Whatsmore, the act of deletion implies the destruction of data. As we saw above, deleting a repository or fork does not mean your commit data is actually deleted.
"We surveyed a few (literally 3) commonly-forked public repositories from a large AI company and easily found 40 valid API keys from deleted forks."
This is how your customers get their entire cloud taken over, because you made a stupid, stupid decision and instead of fixing it when warned (repeatedly!) you instead decide to just blame the customer for not reading page 537 paragraph 3 subsection B about the counter-intuitive security footgun you've left in your product.
This is negligence, pure and simple.
The thing to keep in mind is that large-scale bug bounty programs make their own incentive weather. People game the hell out of them. If you ack and fix sev:info bugs, people submit lots more sev:info bugs, and now your security program has been reoriented around the dumbest bugs --- the opposite of what you want a bounty program to do.
To provide one example I reported to a large cloud provider that their managed Kubernetes system exposed the Insecure port to the container network, meaning that anyone with access to one container automatically got cluster-admin rights. That pretty clearly seems like not a good security choice, but probably hard to fix if they were relying on that behaviour (which I'm guessing they were).
Their response was to say it was a "best practice" behaviour (no bounty applicable) and that they'd look to fix and asked me not to publicly mention it. Then they deprecated the entire product 6 months later :D
That's one example but I've seen similar behaviour multiple times for things that are more architecture choices than direct bugs, which makes me think reporting such things isn't always welcome by the program owners.
My employer doesn't pay out for known security issues, especially if we have mitigating controls.
A lot of people spam us with vulnerability reports from security tools we already use. At least half of them turn out to be false positives we are already aware of. In my opinion, running a bug bounty program at all is a net negative for us. We aren't large enough to get the attention of anyone competent.
I'm honestly not yet convinced that is enough here - I've fallen victim to this without realizing it - the behaviour here is so far removed from how I suspect most user's mental model of github.com works. For me none of the exposed data is sensitive, but the point remains I was totally unawares it would be retrievable like this.
If the behaviour flies so against the grain, just publishing it in a help doc is not enough I'd argue. The linked article makes the exact same argument:
> "The average user views the separation of private and public repositories as a security boundary, and understandably believes that any data located in a private repository cannot be accessed by public users. Unfortunately, as we documented above, that is not always true. Whatsmore, the act of deletion implies the destruction of data. As we saw above, deleting a repository or fork does not mean your commit data is actually deleted."
There's a deeper problem here, which is that making the UX on hosting sites less surprising doesn't fix the underlying problem. There is a best-practices response to commiting hazmat to a repository: revoke the hazmat, so that its disclosure no long matters. You have to do this anyways. If you can't, you should be in contact with Github directly to remove it.
1. GitHub has a nasty privacy/security hole, where commonsense expectations about the meanings of common words are violated by the system.
2. Github has publicly announced that they don't care about this part of user data security (private code), so won't pay people to know tell them what they alreay know and announced.
Github won't pay you to tell them they are wrong when everyone alreay knows.
Beyond that is is also a batshit crazy implementation. Just I imagine AWS would still allow AWS credentials to give access to a deleted account
Lets get back to what we had before when multiple people can find the same bug and exploit if needed. Now we have the one person who finds the bug it gets patched and they don't get paid.
But if you buy someone non-refundable tickets to a concert they already have tickets for, you aren't owed compensation.
In this case, the spot turned out to be a freckle, which everyone involved already knew was a freckle (since it was documented), and if anyone owes anyone anything, it's the researcher that owes github for wasting their time.
Exactly.
> The receiver is obligated to return the favor.
Not at all. This is a very toxic expectation.
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.
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.
* 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.
For companies like Microsoft, which a CSRB audit showed that their security culture 'inadequate', the risk of disclosure with a POC is about the only tool we have to enforce their side of the Shared Responsibility Model.
Even the largest IT spender in the world, the US government has moved more from the carrot to the stick model. If they have to do it so do we.
Unfortunately as publishing a 'bad practices' list by us doesn't invoke the risk of EULA busting gross negligence claims, responsible disclosure is one of the few tools we have.
In my experience, there was two reasons for this behavior:
1. They don't want to spin dev cycles on something that isn't directly related to revenue (e.g. security) 2. Developers don't have the same mindset as someone who's whole job is security. So they think something is fine when it's really not.
GitHub clearly knew. Would you prefer that a vendor lie?
Is my repository accessible?
As far as I know, it is not accessible.
the issue is the `fork` mechanism of github is not semantically like a `git clone`
it's more like creating a larger git repo in which all forks weather private or not are contained and which doesn't properly implement access management (at least point 2&3 wouldn't be an issue if they did)
there are also some implications form point 1 that forks do in some way infer with gc-ing orphan commits (e.g. the non synced commits in he deleted repo in point 1) at least that should be a bug IMHO one which also costs them storage
(also to be clear for me 2&3 are security vulnerabilities no matter if they are classified as intended behavior)
What I don't know is if in 3 months you DO set your remote origin to that fork to for instance, pull upstream patches into your private repo, you're still not pushing, only pulling, so I would THINK they'd still never get your changes, but I don't know if git does some sort of log sync when you do a pull as well.
Maybe that would wind up having the commit hash available.
I 'love' it when I see the words "hide", "archive", "remove", and other newspeak to avoid using the word "delete", since 'they' never actually delete (plus there are 1-2-5-10-forever years' of backups where your 'deleted' info can be retrieved relatively easy).
> After some internal discussion, we have determined this is a known low risk issue. We may make this functionality more strict in the future, but don't have anything to announce now. As a result, this is not eligible for reward under the Bug Bounty program. Below is a reference to our instructions for users to remove sensitive data from a repository. https://help.github.com/articles/removing-sensitive-data-fro...
My conclusion would be: don’t use GitHub.
obviously not a fan of this policy though
In the meantime I'll be calling "private" repos "unlisted", seems more appropriate
The same for “deleted” repos.
Which is, indeed, what every modern database does.
What GitHub is doing here is neither temporary nor inaccessible.
1. Create a private repo R
2. Create a private fork F of R
3. Push commits to the fork F
4. Make R public
So basically, if you ever intend to open source anything, never do it to an existing private repo. Always start a from-scratch repo to be the root of your new public project.
However, if they "don't care" about such an issue, how can I trust them to care about other stuff?
- gives you control over gc-ing their hosted remote?
- does not to your knowledge have a third-party public reflog or an events API or brute-forceable short hashes?
if so, especially the second of those seems a fragile assumption, because this is "just" the way git works (I'm not saying the consequences aren't easy to mentally gloss over). Even if gitlab lacks those things curently (but I think for example it does support short hashes), it's easy to imagine them showing up somehow retroactively.
If you're just agreeing with the grandparent post that github's naming ("private") is misleading or that the fork feature encourages this mistake: agreed.
Curious to know if any git hosting service does support gc-ing under user control.
Or you know, self-host, preferrably on-prem.
Basic git hosting only needs a sshd running on the server. If you want collaborative features with a web UI then there are solutions for that available too.
Clone and mount, unmount and commit
i read headlines like the above with the implied "not just to the employees there anymore"
Order does not indicate any preference.
That might be a bit too strict. I'd still expect my private repos (no forks involved) to be private, unless we discover another footnote in GH's docs in a few years ¯\_(ツ)_/¯
But I'll forget about using forks except for publicly contributing to public repos.
> Users should never be expected to know these gotchas for a feature called "private".
Yes, the principle of least astonishment[0] should apply to security as well.
[0] https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
That doesn't fork, but does what you would expect, a fully private repo.
git is a "distributed" version control software afterall. It means a peer can't control everything.
And anyone in the world can pull what was pushed to a public git repo before you delete it. You should always assume that has happened.
"Anyone can access deleted and private repository data on GitHub"
Not everything needs to be designed for idiots and lazy people, it's ok for some tools and services, especially those aimed at technical people and engineers to require reading to use properly and to be surprising or unintuitive at first glance.
I agree generally that interfaces have been dumbing down too far, but "private is actually not private and it's on you for not knowing that, idiot B)" is a weird place to be planting that flag.
GitHub may very well say that this is working as intended, but if it truly is then you should be forced to make both the repo and fork public at the same time.
Essentially "Making repo R public will make the following forks public as well 'My Fork', 'Super secret fork', 'Fork that I deleted because it contained the password to my neighbours wifi :P'.
OK. I'm not sure if the last one would actually be public, but I wouldn't be surprised if that was "Working as intended(TM)" - GitHub SecOps
The issue here is that if you have a private repo and a private fork of that repo. If you make the private repo public and keep the fork private, then you are not explicitly told that your fork is actually public, whether you want to or not.
I've used github for a long time, would not have expected these results, and was unnerved by them.
I'd recommend reading the article yourself. It does a good job explaining the vulnerabilities.
I can sympathize with someone who gets bit by it, as it might not have occurred to them, but it’s part of the model.
The third strikes me as counter-intuitive and hard to reason about.
P.S. If you publish your keys or access tokens for well known services to GitHub and you are prominent enough, they will be found and exploited in minutes. The idea that deleting the repository is a security measure is not really worth taking seriously.
this isn't quite right
content addressable storage is just a mean of access it does
- not imply content cannot be deleted
- not imply content cannot be access managed
you could apply this to a git repo itself (like making some branches private and some not) but more important forks are not git ops, they are more high level github ops and could very well have appropriate measurements to make sure this cannot happen
e.g. if github had implemented forks like a `git clone` _non of this vulnerabilities would have been a thing_
similar implemented different access rights for different subsets of fork networks (or even the same git repo) technically isn't a problem either (not trivial but quite doable)
and I mean commits made to private repositories being public is always a security vulnerability no matter how much github claims it's intended
Nonetheless, given that GitHub exists to facilitate both anonymously pulling the entire history of the repository, and given that any forks would contain the full contents of that repository, it is very natural that GitHub would take the "once public always public" line.
> and I mean commits made to private repositories being public is always a security vulnerability no matter how much github claims it's intended
I specifically said the third use case was different, because it is the one that doesn't involve you explicitly choosing to publish the commits that contain your private information. I did not and would not defend GitHub on that point.
I don’t think that follows at all. Purging hashes without a link to a commit/repository would be pretty natural.
The exact UX here is debatable, but I don't think security warnings buried in the docs is enough. They should be accounting for likely misunderstandings of the model.
I wouldn't mind a disclaimer when you delete a repository that any information that repository ever contained is likely to have already been downloaded and stored. Per the comment I added, I'm not sure it would really help that much, but it would not be harmful.
It couldn't hurt, but that isn't the misunderstanding I'm worried about.
As described in the first example of the article, you can make a fork, commit to it, delete your entire fork, and yet the data will still be accessible via the parent repo, even though no one ever forked or cloned or saw your fork. That is not intuitive at all.
You can say "Well just consider any data that has ever been public compromised forever", and indeed you should, but this behavior is still surprising and could bite devs even if they know they should follow the advice in that quote.
Consider a situation like this...
Dev forks, accidentally pushes a secret or some proprietary code in a commit, and immediately deletes the fork. They figure it was only up for a very short time, now it's gone, risk someone saw it is low. They don't bother rotating, because that would be a major operational pain (and yes, it shouldn't be, but for many orgs it is).
Is this dev making a mistake? Of course. That's not good security thinking. But their assessment of the risk being low might actually be correct if their very reasonable mental model of deletion were correct. But the unintuitive way GH works means that the actual risk is much higher than their reasoning led them to believe.
No one can, with a straight face, say that they don’t restrict access because “this is just how the technology works”. Doesn’t matter if it is content addressable or an append-only FS or whatever else.
Even for some technology where the data lives forever somewhere (it doesn’t according to Git; GitHub has a system which keeps non-transitively referenced commits from being garbage collected), the non-crazy thing is to put access policy logic behind the raw storage fetch.
No. That doesn't make sense. It only sounds vaguely plausible at first because content addressable storage often means a distributed system where hosting nodes are controlled by multiple parties. That's not the case here, we're only talking about one host.
Imagine we were talking about a (hypothetical) NetFlix CDN where it's content addressed rather than by UUID. Would anyone say "they forgot to check auth tokens for Frozen for one day, therefore it makes sense that everyone can watch it for free forever"?
So you've used it heavily, but haven't read the docs or thought about how forks work, and are now surprised. This seems like a learning opportunity, read the docs for stuff you use heavily, read the man pages and info pages for tools you rely on.
None of this seemed surprising to me, perhaps because I've made PRs, seen that PRs from deleted repositories are still visible, and generally have this mental model of "a repository fork is part of a network of forks, which is a shared collection of git objects".
However in UX/DX the question isn't whether users can develop the right intuition based on how they interact with software over time and reading through the documentation but how to shorten the time and effort necessary for that, ideally so that a single glance is enough.
Do you think reading all the documentation for every feature of every tool you use in your life is a good use of your time and something that should be expected of everyone? As someone developing software used by other people, I don't.
Similar (but less concerning) is the ability to use short SHA1 hashes. You'd have to either be targeting a particular repository (for example, one for which a malicious actor can expect users to follow the tutorial and commit API keys or other private data) or be targeting a particular individual with a public repository who you suspect might have linked private repositories. It's not free to guess something like "07f01e", but not hard either.
If these links still worked exactly the same, but (1) you had to guess 07f01e8337c1073d2c45bb12d688170fcd44c637 and (2) there was no events API with which to look up that value, this would be much, much less impactful.
As someone who has used git and GitHub extensively over that time, none of what the author documented was a surprise to me.
However, I also remember when people were trained to do a "Save As" when preparing a final Word document or Powerpoint for sharing with a third party. That certainly bit enough business users that Microsoft eventually changed the default behavior.
GitHub is not simply a UI to actual git repositories it hosts. It also carries a lot of data that is not stored in the repository itself. The UI deliberately blends the two types of interactions. There's no such thing as "creating a pull request" in git, for example.
It's not at all unreasonable for a user to assume "forking" merely creates a copy with an upstream origin. Read through the steps again:
1. You fork a public repository
2. You commit code to your fork
3. You delete your fork
Of course the mistake is that the fork is not a copy. The fork isn't a fork (i.e. a separate copy that shares the original's history), it's a view of the original repository with its own refs. The commits are added to the same repository, only the refs that reference them aren't. This makes sense architecturally but it means most metaphors and analogies people likely bring to the table break down because they assume a fork is a copy, not a collection of refs layered over a shared repository of commits - after all "allowing stranges to add commits to the repository" is what PRs are for. Except of course that's not what PRs do then, PRs actually allow strangers to add references to commits to your branches.
We all need to embrace: Nobody has ever been impressed that you already knew something. When people share a discovery with you, it’s not about you. It’s about them and their joy of discovery. They want to share that joy with you.
Trying to think of an example it usually goes something like
A: We should do X
B: No. See this document (the sharing part)
A: I wrote that document and I'm telling you we should do X (the "I already knew this" part)
https://github.com/github-community-projects/private-mirrors
As it pertains to the post, since that private mirror is disconnected, none of the concerns about accessing deleted data apply.
The downside is that you don't get any of GitHub's performance and UI affordances from the fork network. But for the use case of private iterations on work headed for a public upstream, that's a trade-off that seems worth making.
On the other hand, once an API key or password has been published somewhere, you should rotate it anyway.
What would github do after receiving a DMCA request in that case?
With something as nuance as this, I wouldn't safely assume all processes, especially one from a compliance (none-technical) department account for it.
You can't host anything this way that you can't already host in your own repository, and GitHub does have a way to remove content that will make it inaccessible, whether in your repository or through another.
It already is. Even to github org's own repos. Any time you make a PR, the /tree/ link to it stays valid forever, even if the repo author removes it.
That GitHub is telling these companies, and bear in mind that these companies are paying customers of GitHub, yeah we don't care that your private proprietary code can be hacked off GitHub by anybody, is incredibly disturbing. Is there really not enough pressure from paying customers to fix this? Is Microsoft just too big to care?
Once we eliminated the references in the tree and all forks (they were all private thankfully), we reached out to BitBucket support, and they were able to garbage collect those commits, and purge them to the point where even knowing the git hashes they were not locatable directly.
That's exactly how you should treat anything made available to the public (and there's no need for the subsequent qualifier that appears in the article—"as long as there is at least one fork of that repository").
It's thinking of posted-publicly-but-unclear-if-exploited as "possibly leaked" (rather than "definitely leaked") that's the problem here, not GitHub's totally reasonable stance.
The one thing they seem to be able to show is that commits in private branches show up in the parent repository if you know the SHAs. And that seems like a real vulnerability. But AFAICT it also requires that you know the commit IDs, which is not something you can get via brute forcing the API. You'd have to combine this with a secondary hole (like the ability to generate a git log, or exploiting a tool that lists its commit via ID in its own metadata, etc...).
Not nothing, but not "anyone can access private data on GitHub" as advertised.
Well, GitHub accepts abbreviations down to as short as four hex digits... as long as there's no collision with another commit, that's certainly feasible. Even if there is collision, once you have the first four characters you can just do a breadth-first search
Making it a "template" repo mostly fixed the issue. That creates a copy instead of a fork. However it still happens from time to time.
Say a private commit depends on a public commit C. Suppose in the public repo, the branch containing C gets deleted and C is no longer reachable from the root. From the public repo's point-of-view, C can be garbage-collected, but GitHub must keep it alive, otherwise the deletion will break the private commit.
It would be "a spooky action at a distance" from the private repo's POV. Since the data was at a time public, the private repo could have just backed up everything. In fact, if that's the case, everyone should always backup everything. GitHub retaining the commit achieves the same effect.
The public repo's owner can't prevent this breakage even if they want to, because there's no way to know the existence of this dependency.
The security issue discussed in the post is a different scenario, where the public repo's owner wants to break the dependency (making the commit no longer accessible). That would put too much of a risk for anyone to depend on any public code.
My mental model is that all commits ever submitted to GitHub will live forever and if it's public at one time, then it will always be publicly accessible via its commit hash.
More generally, you probably want to construct a new history for the public repo anyway, so you'll want a brand new repo to ensure none of the scrubbed history is accessible.
I always started a new repository without git history. I can’t imagine trying to audit every single commit.
What do you mean "missed"? They described the situation where data is leaked from a private fork, which is when you make the original repo public.
There's no other time when data leaks. A public repo can't have ongoing private forks.
I'm not so sure about the "forever" part as git gc is a thing, and at least in 2013 they ran it regularly: https://stackoverflow.com/a/56020315
No idea about nowadays though. There is this blog post:
https://github.blog/engineering/scaling-gits-garbage-collect...
> We have used this idea at GitHub with great success, and now treat garbage collection as a hands-off process from start to finish.
But maybe it never was a reference to POLA proper - "principle of least privilege" is more widespread I think, outside of the object capability community. And maybe "least astonishment" came first!
When I looked into it a while back, apparently it is intended behavior, which just seems odd.
https://docs.github.com/en/rest/actions/secrets?apiVersion=2....
Have we stopped naming vulnerabilities cute and fuzzy names and started inventing class names instead? Does this have a logo? Has this issue been identified anywhere else?
chatgpt: Create a logo image of a fork impaling a small gnome named "code"
It's very formally called Cross Fork Object Reference (CFOR). But commonly known as Git Forked! (Including the exclamation mark).
But I'm still not entirely satisfied with the word choice.
For example if the root repo is DMCA’d, or, if repo B forks repo A, then B adds some stuff that causes B to get DMCA’d. Can A still access B?
NB: according to https://www.gtlaw.com/-/media/files/webinars/ian-ballon-may-..., page 4-470, it’s possible that failing to process a DMCA notice may only lead to losing safe harbor for the material identified in the notice, not for the entire service.
So GitHub might just choose to ignore the notice for React, get sued, and win, all without losing the safe harbor.
For less popular repos, I would not be surprised if you could take down any repo literally by submitting a completely bogus notice.
But honestly I still don’t know how much leeway - legally - service providers have in applying their own technical/legal expertise when evaluating DMCA notices. I’d appreciate any sources (court decisions, textbooks, whitepapers, descriptions of actual industry practices, etc) on the topic.
>But what’s more interesting; GitHub exposes a public events API endpoint. You can also query for commit hashes in the events archive which is managed by a 3rd party, and saves all GitHub events for the past decade outside of GitHub, even after the repos get deleted.
Oof
1. If a URL would be in the “[t]his commit does not belong to any branch of this repository, and may belong to a fork outside of the repository” and that URL uses a shortened commit hash, return 404 instead. Assuming no information leakage via timing, this would make semi-brute-force probing via short hashes much harder.
GitHub is clearly already doing the hard work for this.
2. A commit that was never public should not become public unless it is referenced in a public repository.
This would require storing more state.
The other two cases are indeed not worse than third-party archival, but they're still socially concerning. When you ask your own host to delete something you uploaded, you don't expect them to ignore you just because someone could have already archived it maybe. Making it harder to find can still be valuable; not all archives stay available forever, if any.
I've had a service say that deleting the information fully can take eight months.
> Any commits made to your private fork after you make the “upstream” repository public are not viewable.
Does that mean a private repo that has never been or will be public isn’t accessible? That scenario wasn’t mentioned.
(there is checkbox allowing that when you are opening PR that I bet almost noone noticed)
I reported that years ago and all they changed it that they extended documentation about this "feature"
my main issue was that you cannot easily revoke this access because target repo can always reopen PR and regain write access.
but they basically "stated works as intended"
Accessing commits on a private fork when it's upstream is made public
The other 2 are just common sense... push something to a public repo and it's public forever. Everyone knows once somethings on the internet it's already too late to make it secret again.
1) Never store secrets in any repo ever! As soon as you discover that its happened, rotate the key/credential/secret asap!!
2) Enterprises that rely on forking so that devs can colab are fucked! Protecting IP by way of private repos is now essentially broken on GH!
3) what the actual fuck github!!??
It's well-explained and fairly presents the facts and GH's position. Based on the reaction here, it's clear many people are not aware of these footguns. If anything, the article is a public service.
It's been written about multiple times, and now truffle is reposting old content with a name like IDOR to try to invent a new vuln class that doesn't exist.
The title of the post is misleading, a specific set of repos leak data under specific circumstances - not every repo. The first two sentences of the post immediately downscope the claim made by the title.
Im guessing you didn't bother to check out thier YouTube.
This post is the only thing the OP has ever posted in 8 months, probably because it's truffle themselves. I stand by my statement, it's clickbait.
And many more haven't known. It wouldn't be sitting on the front page with 1300+ upvotes otherwise. This is, effectively, not some ho-hum old news -- even if it was for you. And that's what so many are complaining about. The hypocrisy of violating POLA so blatantly and then shrugging it off, pointing to some explanation buried in the docs that they know damn well most people won't read, and saying "Hey the info is right there, on you if you didn't RTFM".
If I force push and orphan a commit, I expect that will get garbage collected and be gone forever.
Or if I commit a file I shouldn't have and rewrite my repo history and push up a whole new history, is the old history still hanging out forever?
If true, then it seems that there is no way to delete any commits at all from any repo that has any forks?
I do not believe the presence of forks matters. Or rather, your version is the initial fork.
My impression is that garbage collection is an expensive and disruptive option (to all forks) and so there's no button or API for it. Hence the recommendations to contact support if you accidentally commit an API KEY or the like (but really, you have already rotated that key, right?)
Github is a software distributing network. Like the app store, or Steam. They grant you access to licensed content, which you self license, and then they facilitate access for you. Based on the honor system. But some things can just be assumed to be true for the sake of simplicity and liability.
For example, If I make a repo public and then take it private the hashes that were obtained while it was open are still open. If I make a repo that's closed and open it, the whole thing is open.
If you fork a public repo and make private commits on it to a software distributor like Github, that is probably just going to end in a violation of the license. In this scenario, Github is saving you from yourself.
If anyone's wondering: Organizations that require SAML are included in your organizations even when you don't have a SAML session when signing in elsewhere via OAuth. Unlike generalized per-organization app authorizations, where GitHub can actually hide organization membership. Only way to find out if a user has a SAML session is for the consuming app to request the membership with your token, and interpret 403 as "no SAML session". As far as I know only Tailscale implemented this. This really sucks for apps like SonarCloud where someone can now view work code from their so cleanly separated personal and professional use GitHub account.
> I submitted a P1 vulnerability to a major tech company showing they accidentally committed a private key ... They immediately deleted the repository,
That is a ridiculous response to a compromised key. The repository should not have been "deleted", the key should have been revoked.
Imagine if you lost a bag with 100 keys to your house. Upon realising you desperately try to search for the bag only to find it's been opened and the keys spread around. You comb through the grass and forests nearby collecting keys and hoping you find them all.
Or you just change the locks and forget about it.
If you upload something, anything, to a computer system you do not own you need to consider it no longer secret. It's as simple as that. Don't like it? Don't do it.
I detest things like delete buttons in messaging apps and, even worse, email recall in Outhouse-style email apps. They just give people a false sense of security. I've been accidentally sent someone's password several times on Teams. Yeah you deleted the message, but my memory is very good and, trust me, I still know your password.
If there's a security problem here it's in people believing you can delete stuff from someone else's system, or that that systems make it look like you can. The solution is the same though: education. Don't blame GitHub. Don't force them to "fix" this. That will only make it worse because there are still a million other places people will upload stuff and also won't actually delete stuff.
Turns out I found out you could even invite external collaborators into your fork and totally bypass enforced SSO.
Even if you block forking into your main repo, the existing forks remains active and still can pull from upstream.
It feels like if you need proper security, you have to go with enterprise
Ultimately I don't think it's feasible to break this behaviour and the most we can hope for is a big red warning when something counterintuitive happens.
What gives?
https://github.com/trufflesecurity/trufflehog/commit/7bc0b2 https://github.com/trufflesecurity/trufflehog/commit/7bc0b4 https://github.com/trufflesecurity/trufflehog/commit/7bc0b8 https://github.com/trufflesecurity/trufflehog/commit/7bc0b8
Trusting some company will actually delete your stuff is kind of naive in my opinion.
The example of people forking and putting an API key in the repo, I would never let my people do this. Once you push, it will be "out there".
But that's just me...
How I manage this is that every time I want to open-source a previously private feature, I take the changeset diff and apply that to the files in the public repository. Same features, but plausibly different hash.
That, unfortunately, sounds like the result of publishing something on the Internet. Not GitHubs fault.
If you’re not gonna share it then it hardly matters. Use a backup drive.
Git is distributed. You don’t have to put your dotfiles on GitHub. Local is enough.
as far as "git is distributed" I don't know if that's the case if you keep it purely local, but hey, you seem to have it all figured out so good job.
Morally seems even worse, Crowdsec did it by accident, GitHub knows about it for years now.
it doesn't matter if it's behaving as intended or how there are forks
also point 1 implies that github likely doesn't properly GCes there git which could have all kinds of problematic implications beyond the point 1 wrt. purging accidental leaked secrets or PI....
all in all it just shows github might not take privacy security serious ... which is kinda hilarious given that private repo using customers tend to be the paying customers
One GitHub employee even contributed a configuration to Git which allows you to do the same thing: run a program or feed a file which tells the GC what nodes to not traverse.
Sounds like a win for foss
“Private” means it should only be available to specific involved parties only.
If you implement any other behavior to these concepts you are implementing anti patterns.
We need to be precise and consistent in the wording of the functions we are providing in order to ensure we easily can understand what is going on, without having to interpret documentation to be able to fully understand what is going on.
This seems like a terrible security vector but I'm not sure migrating thousands of repos out of github vs. training engineers to keep public and private repos completely separated makes sense and you haven't explained why you use CodeCommit.
Unless it is this reason, which like I said, seems a bit heavy handed, but I rarely move private repos to public.
I kind of assumed this was a distributed Git problem, not Github, but I don't know.
No they aren't.
Insane
Further, even if you had managed to delete the secrets from the repo you have to assume that others already copied them and rotat your keys anwyay.
Also Microsoft: It's a feature!
----
This is clearly documented and can be explained even to non-technical managers.
From my POV calling that vulnerability is trying to build a hype.
I think that having quote from here on visibility changing settings page would be even more clear: https://docs.github.com/en/pull-requests/collaborating-with-...
... yeah if <Do Work> is push your keys to GitHub.
"Private repositories" were never private as I said before. [0]
Well, duh. That's not a reason to avoid every "private" feature in every product on the planet.
A failure in the system is still surprising. I could equally say "all software has bugs, so it's not surprising if your self-hosted solution leaks data". But that would be too dismissive, as you are being.
Very cool that it is not surprising to you.
But to others (some are even in this thread!) it is both new and surprising. They unfortunately missed your 4 year old comment, but at least they get to learn it now.
And if that entity has a complex system of storage and retrieval of data by and for many users, that changes frequently, without public scrutiny - it should be assumed that data breaches are likely to occur.
So I don't see it as very problematic that GitHub's private repositories, or deleted repositories, are only kind-sorta-sometimes private and deleted.
And it's silly that the article refers to one creating an "internal version" of a repository - on GitHub....
Still, interesting to know about the network-of-repositories concept.
If you know the hash of some data, then you either already have the data yourself, or you learned the hash from someone who had the data.
If you already have the data, there is no vulnerability - since you cannot learn anything you don't already have.
If you got the hash from someone, you could likewise have gotten the data from them.
People do need to be aware that 'some random hex string' in fact is the irrevocable key to all the data behind that hash - but that's kinda inherent to gits design. Just like I don't tell everyone here on HN my login password - the password itself isn't sensitive, but both of us know it accesses other things that are.
If github itself was leaking the hash of deleted data, or my plaintext password, then that would be a vulnerability.
From the article, you do not need to have the data nor learn the hash from someone who had the data.
>Commit hashes can be brute forced through GitHub’s UI, particularly because the git protocol permits the use of short SHA-1 values when referencing a commit. A short SHA-1 value is the minimum number of characters required to avoid a collision with another commit hash, with an absolute minimum of 4. The keyspace of all 4 character SHA-1 values is 65,536
The solutions are:
* Force people to use the full hash.
* Get use to a lot of dead links.
* Claim that it's a feature, not a bug.
Don’t think so - the article mentions you can use the short prefix on GitHub, so you have a search space of 65536.
You need to read to the end of the article where they show the brute-force way of getting the hashes.