Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Which comes with its own problems. What if I just published something I wanted to be secret? Then I need to be able to switch it back to private, and it has to be quick, not after five minutes. Distributed systems with eventual consistency already make fixes like that hard, not to mention caches and whatever.


The GP didn’t mean “wait 5 minutes before making any action”, they meant “stage the change so the user can see the result of their action but they still has a grace period to undo it”.


Or, have there be no need to undo anything. Why should ticking the "private" flag have any effect on anything else? If you wanted an effect on something else, a separate button "Nuke all 53,675 star from this repo", with its own protections, would suffice.


How would stars and watchers work on a private repo, though?


Could just make them inactive for a while, but still registered.

Stop sending notifications to watchers, and replace the repo in the stargazer's starred list with a "The following starred repos are currently private and cannot be viewed:" and make the stars be remove-only for a while.


Just don't show them. Filter out private repos before showing a user's stars, notifying them of issues, etc.


Right, just more work. More tests. More edge cases. More time.


Well, they put in the time to test a massive cascading delete operation. Surly a flag would have offered far less possibility of catastrophic outcomes and therefore would been significantly easier to confidently develop and test.


Cascade delete is a less risky operation from a security stand point. There are so many edge cases where potentially sensitive information could get leaked with regards to subscribed private repos if not handled correctly. In fact I have personally filed a bug bounty with GitHub after discovering just such a bug.

I’m not saying there isn’t a better way Github could handle this situation. Just that I do sympathise with the decision to cascade delete.


If they are using a database's built in support for cascading deletes, and if the star tables are simple m2m tables (basically just 2 fk's per row), the work to implement and test cascading deletes is trivial.


Sure. But that’s the cost of good UX.


There is no undo there. 5 mins seems like a long time to you but to the bots that scrape GitHub repos for secret things, the time it took you to notice and reverse something yourself was already the time they needed.

If you made something public on GitHub that shouldn’t have been, it was immediately compromised, you just might not notice.


Making a private repo public could also be delayed.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: