Comment by dathinab
2 years ago
> For the first two, git is based on content addressable storage, so it makes sense that anything that is every public will never disappear.
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
You're right that I shouldn't have given the impression that content addressed storage means as a technical matter that public content must never disappear. The phrasing was a bit sloppy. GitHub could, as a technical matter, choose to hide content that had previously been made public.
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.
> it is very natural that GitHub would take the "once public always public" line
I don’t think that follows at all. Purging hashes without a link to a commit/repository would be pretty natural.