3 ms·

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 p

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.

zelphirkalt 2y ago
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?
- lilyball 2y ago
  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.
- scarface_74 2y ago
  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 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.
xmodem 2y ago
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.
- account42 2y ago
  And according to TFA that case is not affected.
HL33tibCe7 2y ago
You’ve completely missed the most dangerous thing mentioned, namely that private forks are not private.
- Dylan16807 2y ago
  > 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.

zelphirkalt 2y ago

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?

lilyball 2y ago
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.
scarface_74 2y ago
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 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.

xmodem 2y ago

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.

account42 2y ago
And according to TFA that case is not affected.

HL33tibCe7 2y ago

You’ve completely missed the most dangerous thing mentioned, namely that private forks are not private.

Dylan16807 2y ago
> 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.