Comment by lilyball
2 years ago
Really the only semi-interesting part of this is "if you make a private repo public, data from other private forks might be discoverable", but even that seems pretty minor, and the best practice for taking private repos public is to copy the data into a new repo anyway.
Is that a best practice in hindsight, or because it was known to some, that this issue exists, or for what other reason do you consider it a best practice? Git history?
When making a private repo public, there's a high chance that there was stuff in the private repo that isn't necessarily ok to make public. It's a lot easier to just create a new public repo containing all the data you want to make public than it is to reliably scrub a private repo of any data that shouldn't be there.
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 worked in Professional Services at AWS for a little over three years. There was a fairly easy approval process to put our work out on the public AWS Samples (https://github.com/aws-samples) repository once we removed the private confidential part of the implementation.
I always started a new repository without git history. I can’t imagine trying to audit every single commit.
You’ve completely missed the most dangerous thing mentioned, namely that private forks are not private.
> You’ve completely missed the most dangerous thing mentioned, namely that private forks are not private.
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.
Even after a private repo is made public, it's common practice for new functionality to be worked on in private until it's ready.
And according to TFA that case is not affected.