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.
> 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.
But isn't that only the third vulnerability, that private forks are implicitly made public?
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.