Hacker News Reader

Comment by cxr | Hacker News Reader

> The implication here is that any code committed to a public repository may be accessible forever

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").

View on HN

Sometimes I wonder if all the security features GitHub slathers on top of `git` lull people into a false sense of security when fundamentally they're working in a fully distributed version control system with no centralized authority. If your key is leaked the solution is to invalidate the key not just synthetically alter your version of history to pretend it never happened.

This is more of a problem if you leak private information with a commit by accident. You can't really revoke that.

You can't reach out to any machines that have pulled down that commit and forcibly delete it, either.

But you can prevent anyone from doing so in the future and cross your fingers that no one has done so yet

As per this post, if a lot of people have forked your repo in the past, then you're stuffed.

Unless you specifically know and understand the ramifications of this GitHub idiosyncrasy, you have no way to tell that your key was possibly leaked. GitHub never informs you that someone accessed a commit created in your private fork.

Your key is leaked the moment you leak it.

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.

Reply on news.ycombinator.com