The issue is not that the feature exists and works as documented. The issue is that it deliberately uses misleading terms. "Delete" that doesn't actually delete data should not be labelled "Delete". "Private" that doesn't actually make data private should not be labelled "Private".
How dare you demand that words have a meaning in today's age? If words had meanings, it would mean that nobody could ever twist their previous statements and shift their liability onto the reader. We can't have that!
@@lamjeri I think a big part of why words don't mean anything anymore is DEI hiring and especially hiring non-English speakers to work on English language products. They literally don't know what the words mean and correcting them is racist so no one fixes it.
@@MrBenMcLeanWhat? That's the weirdest rant I've seen this week. Okay maybe the second or third weirdest but still. Companies don't bother with that especially because they'd look unprofessional. They don't bother with corporate talk... No, they don't JUST bother with corporate talk. Nowadays, they lie and create false presentations for their products from Google to the smallest company.
@@MrBenMcLean DEI non-sense started removing meaning from words like gender, that is true, but in this case, it's not about that. Companies are still using words like "delete" and "private" because that's been used for decades. But delete button no longer deletes anything simply because the company wants to sell the data. So delete button nowadays means "stop showing my data to me and keep it for your needs".
You know. Words mean things. So people think things marked PRIVATE are, you know, PRIVATE. Same with deleted. So people don't delve into the bowels of documentation because they know what words mean. The don't think that a 3rd party went and redefined the words out from underneath them. Another example recently is that Ohio has declared that boneless wings are allowed to have bones in them. Sorry, the rest of the world stupidly believes that boneless wings are sans bones. Silly rabbit. GitHub, don't hide behind the fine print. Tell people upfront what your terms mean. Another approach would be for GitHub to provide an ERASE feature. Kinda like when you delete a file, it's not really gone. Just the pointer is gone. But, if you erase it, then the data is gone too.
Well, businesses are already used to use inaccurate terms. For example, if you "buy" a digital good these days usually you don't actually buy it, you just get a license that may become useless as soon as their DRM servers are switched off, which essentially may happen at any time.
Security is a weird beast. It should always be assumed with distribution or central networks that any permissions inherited is difficult and easy to get wrong. It should always be assumed that you should create a new thing and hard copy the information to that new thing. If you want premium features to an open source thing then you should introduce a plugin network and architecture and create a plugin that adds premium features. This allows for complete separation and removes the need for a fork. This is technically true for any network or graph. A new network that is not connected in any way is almost always safer than any connection to be the other network. A segmented network may hinder or slow down a hacker but won't stop the hacker. Only physical separation would prevent the hacker from switching networks at some point. The security concerns are saying that you should create a physical boundary and that GitHub will not assume you wanted to create a boundary. Doing this would probably break and introduce a lot of edge cases and bugs that customers would complain about. Do security right. Be paranoid and assume a breach will happen and mitigate against it. If your repo becomes public through a mistake then how destroyed are you? Best case, not at all. Or use GitLab, mercurial, self hosted. Most enterprises are self hosted with either bitbucket, GitLab, GitHub, homebrew, etc for this reason. They can't afford any exposure and having more control won't remove the risk but reduce it.
Ah, the young learning that there's a whole "class of man" out there subverting the definitions of words (to make them less intuitive). That's how they do "liability shifting" to avoid being blamed for future problems. You start to learn what companies/humans are good and bad, just by recognizing that behavior. The computer science industry is riddled with these types of guys (and professors (and white papers (and politics))).
Especially in the computing world, terms have always been a bit wibbly wobbly, haven't they? Back in the MS DOS days you could delete files, sure. But then you could "undelete" them again, meaning that they haven't really been deleted in the first place. Nowadays the term "delete" has often times been replaced with something like "move to bin", but with how storage devices work, even if you empty the bin and thus "delete" a file, it's usually still there. And it's only getting worse now that everything is being synced into "the cloud" where everything (probably, perhaps not, who knows?) has a backup anyway. Who can tell what the word "delete" even means? 🤷♂
As a gun guy, I took this personally. They say Glocks don't jam but when I watch police videos they jam all the time. Turns out it's hard to hold anything right when you are being shot.
To those saying "this is a git issue": No it's not. Git doesn't have any concept of forks on the same host (unless you consider worktree that, but it really isn't the same). Initially, people sent git repos directly to each other. When you had a fork, you had a copy of the original at the time of forking, but the original has NO knowledge of you. Likewise, the fork has NO information about the original outside of possibly an URI to it. Personally I'd expect that if I delete a repository, it should actually delete the repository. There is really no reason why I'd still need the commits in any other repository, fork or not. Of course it makes sense to store the same commits in multiple repositories together to save space, but unreferenced commits really should not ever be transfered. This just sounds like they did not want the additional risk of fucking this up or of people doing weird shit, like using a commit hash in their scripts, because they don't understand git gc.
How can you start by saying this is not a git issue and the proceed to explain how git screwed up? I don't follow your logic. This totally a git issue. They provide a delete button, it should, you know delete things. your explanation does nothing to address private repositories.
@@CoreyKearney git was invented by Linus Torvalds and open sourced, it's installed by default on many Linux distros. In contrast, Github is just providing servers and a wrapper around git.
You can email support and just politely ask them to move your private repo to it's own fork network separate from the upstream. That's the solution I have used.
@@semmu93it's possible that they do listen to requests like this, but of course with all business they prioritize their enterprise customers first who are most likely the people who care enough to actually go out of their way and raise a support issue like this in the first place
But they do document it if you look closely enough so they're in the clear. edit: the wording itself maybe not when scrutinised legally but I do not know.
this should not be legally acceptable, the least they could do is add a concise note informing people that their code is not actually private or removable
If I understood correctly, if I make private repo from scratch and don't do any fork of it then it still will truly be private? Issue is only when forks are involved?
I still wouldnt trust github for anything REALLY private that you absolutely cant have leak. But for stuff that wont get you sued or your identity stolen it's fine.
Fair enough, make it a feature. But this should show up a a clear explicit warning in the UI at least in the case when you are making public a private repo with forks.
So, to summarize: 1. Data once made public stays public. Perfectly reasonable, this is how Internet works. If you publish a secret, you cannot delete it, only invalidate it. No surprise here at all. 2. Purely public workflow works as intended. 3. Purely private workflow works as intended. 4. Mixed public-private workflow may have some hidden traps. Well, maybe GitHub should put some kind of notice on switching repo form private to public, like “this can expose private data even beyond what is contained in the repo”. Other than that, the behavior is rather reasonable once you read the documentation. (Personally, I would not perform such a switch at all, just to avoid reasoning about the consequences. Creating a new public repo and pushing the necessary commits to it is a viable alternative.)
I think the warning needs to go in the forking action actually. If the person who forks is different from the maintainer of the original repo, then it's outside of the control of the fork owner WHEN the commits potentially become public. Of course, if the original repo is private when the fork is made, that must mean the forker has been invited to the private repo, so there must be some pre-existing connection between them. But this doesn't guarantee that they communicate (if it's a different department of a company). Essentially, if you fork a private repo, you will forever run the risk that your private fork becomes public.
You cannot securely delete data from the internet, because someone could have copied the data. Once published it might be to late, so you have to assume the data is no longer private. Github always deleting the data will not significantly improve the situation, but might more easily break code depending on the repository. Github might still be able to improve warning messages before making stuff public.
@@christopheranderson2100 yes in some cases if you have a repository on an account but you also want same repository in another account but still you want it should be private and can be accessed internally then on that case we may can use private fork
Crazy coincidence that I was just thinking about if private GitHub repos not being private as a random passing thought and this video popped up in my feed shortly afterwards.
Aaand.. that's why anything you want to keep private, just don't put it into the clouds, period. Everything will be made public eventually. You keep it in a loca self-hosted repo etc. Never know when and how, but stuff like that will keep happening.
@@HackerFrosch speak for yourself. Not everyone joined the cloud, um, club, It works for enough people, apparently, so not "anyone". Cloud is just a fancy word for "servers not run or owned by you". Trading convenience for control.
Things like this are the reason why we consider API keys committed to a repo a security incident. Regardless whether it's public or private. Resolving the incident is only possible by revocing the key.
I accidentally pushed some JWT private keys in the repo at my prev. job (no that's not why I was fired), it was a private repo with no forks, and was never intended to be published, it's a closed source laid SaaS product. I still had to delete the commits, force push stuff and ask the GitHub support to actually delete the commits from their servers. apparently it wasn't feasible to invalidate the jwt private key.
My employer's Open Sourcing Guidelines say to make a copy of the latest state of the internal repository when making it public. So no sharing of commits. (We are using an internal Github Enterprise anyways, let's see how this changes when we migrate to Github Enterprise Cloud.)
Thanks, I was not aware of this. IMHO, they should probably change the word "Delete" to something else, and had a short reminder in the "delete verification" dialog, that public repos are never rely deleted (with link to doc). There should be a similar reminder when making a private repo public. Glad that I setup my private Gitea all those years ago...
I accidentally got this video to play and just heard this. Once he writes some code, he'll understand. I may have misunderstood, but I don't think he's teaching his audience to be careful, but he's learning about programming and how git works. Or maybe it's just the tone of his voice that makes is sound like he's blaming Github or whatever.
11:51, what people need to understand is anything you put online is in risk of being made public and might never be able to remove it completely. Does not matter what people "assume", if it is made public by user error or exploit, if you don't want it public, don't put it online.
@@tzebruh google "gitlab security breach" and you might change your mind unfortunately. Self host might be the only way to go for the things you really, really want to control absolutely. :(
With API keys, you can just rotate the key, like you said. What's really scary is when you have a private fork with paid features, this is a big business risk
Well running businesses will rotate the API key but lot of businesses are a complete mess. Add some temporary contractors that get let go, some mergers and acquisitions and you now have a system that no one actually knows how it works -- and sometimes doesn't know that it exists. Those API keys are never rotated or even known about to put in a security audit.
It's not. You will see the private code from the still private fork in the now public root repo, only as a reference in a PR. Meaning at some point you actually was about to merge it. Making a private repo public is sort of dumb anyhow -> the moment you do the link is severed and you can no longer make PRs from the root to the "not a fork anymore" . So why are you sharing all this issues PR and shit. Just start an new bare repo and push your main branch to it.
07:30 deleting the repo is a stupid reaction, they should be rotating the api key or whatever secret and move on, the commits being available after is a good thing
From my understanding, one goal behind this is to allow restoring pull requests to your repository even if the PR author deleted the branch or repository. Plus of course, saving storage space by not duplicating data across forks.
they could at least check if the person has any permisisons to see the contents of the commit by the link. e.g. if I don't have access to a private fork repo, I shouldn't have access to the commits from that private fork repo via a public origin repo.
@@Kitulous The way git data is stored, the individual commits are not linked to repositories they belong to (and most commits are actually in all forks of a network). So doing this needs some extra care.
You explained this super well but that shaky camera literally gave me nausea and i was LAYING DOWN. If you can stabilize it that would be great. Makes it really difficult to watch but I enjoyed the way you explained the situation.
Your example works because when you forked the repository you didn't notice your copy of the repository was public. If you made it private, then commit anything afterwards, it wouldn't be accessible.
I clicked on the video as I saw the StardewValley truffle icon on the thumbnail. I thought this was going to be a security rant by a character in Stardew
In all fairness, anything you make public for a millisecond can remain part of public record forever. Not sure why anyone would expect otherwise. So not a big deal. Also not sure why people are surprised that other forks (including the upstream) have access to your fork (sort of the point). Again theoretically someone can merge your code the moment you make it public, so removing it from your repo means nothing at this point. I would agree that private repo made public exposing code of any forks is weird. But private forks are sort of weird anyhow. I would personally say it's sort of weird making a private repo public -> you sort of share all your messy history and whatever. Most people will rebase a branch and push it to a new public bare repo. Say you have something questionable. Then someone makes a comment in the code review. You remove and force push -> the comment will still be there.
That's why you never push things to GitHub that contain critical information and if it happens anyway the very first thing you'll do is immediately revoke the affected key. Don't even try to cover it up and just delete the repo or commit.
After hearing a lot of such security stuff recently, i begin to consider that private is synonym to offline or to things-that-never-sent-to-3rd-patry. And if there is a public site telling you about how private they are or having "private" features then it's definitely a lie
I did not know it work that way. But the issue with upstream repos not having their commits delete when the repo is deleted AND there is at least 1 fork. Makes absolute sense to me. Since this allows a fork to grab the latest changes that the owner of the fork would like to integrate from the upstream repository.
Well,i think that no one should expect deleting anything from the cloud would wipe the data from their servers,since the data is being tracked or marketed anyway,so maybe just dont commit sensitive info or keep rotating API keys But with the enterprise features,i agree thats a real issue💯
9:01 IDk if I am too late to this but when I tried to fork one of my private repose it said "cannot fork because you own this repository" I think this only applies for organization's repository's.
So from my understanding, you need to create a fork as a prerequisite. What happens if you don't? Also, deleted repos are not fully deleted for at least three months.
I tested this with a private repo that doesn't have any forks. A force push to the GitHub repo only cleans up the previewable commit history, but you can still access old commit links (lost via rebase squash for example). When you clone from this repo, the dangling commits are not reproduced in these local clones, but they still exist on GitHub. The only way to get rid of these dangling commits on GitHub is to delete the repository on GitHub, to recreate it, and then to push from any of your local clones. Only then are the commit links inaccessible from the entrypoint of your repo name. My guess is that the deletion and re-creation assigns a new id to the same repo name in their database, making the old links refer to the new repo which doesn't have a history of dangling commits. The problem here is that any kind of fork off this repository would make it impossible to truly delete on GitHub since they effectively copy it and make a new entry point to all of its commits for each fork. Lord have mercy.
They just need to add an options to disable forks on sensitive repos So orgs can have a setting to say all repos created can never be forked, if a repo is made public it’s public there are no private forks
There is such an org setting letting org admin disable forking of private repos. You can also set it for individual repos. But it currently still allows forking of public repos though.
A lot of this seems like a fundamental misunderstanding of git itself. Same thing would happen if the data was shared on the blockchain. Actually deleting something from git history is challenging and can break anyone referring to the repo, and that's on top of the problem of doing timely deletes in a distributed storage system. You can push all the deletes you want, or delete the repo, or even delete your entire profile, but no matter what you do there is a window where someone could have pulled the repo to their local disk, and there's nothing you can do about those copies. If you pushed a private key, it is burned, no matter what you do going forward. The ordering issue on promoting/demoting repos from private to public does seem like an actual correctness issue, and it would make sense for them to fix things so it works the same regardless of ordering.
Yes, never push private data. Probably also be aware that git history rewrites also do not erase the past. Most notably in pull/merge requests where commits are listed like some kind of audit log. The best would be to be able to trigger some "git gc" but I only think this is possible in gitlab and with higher permissions. If you send data into the www, anyone can intercept it and also record (save) it between it being public and before deletion. Why one would commit and push API keys in example files for repos, I'm not sure. Either test it locally or use throw away keys. Everything else is just an accident to happen.
It’s strange that you can access a commit from a fork on the upstream without being merged in. It sounds like “repo network” is a fancy way of saying it’s really one repo and they do some internal branch renaming. And when you make a repo private they clone it to make it a separate network, but everything prior to that persists. I guess it kind if makes sense as it makes cross repo pull requests easy. I’ve always thought forks were separate cloned repos, and new commits on the fork were only on the fork, not upstream unless you merged something in. But from a data storage perspective it can make sense. Why duplicate commit data if you don’t have to. From early days if GitHub it makes sense. But it makes private repos look like an afterthought.
I knew it for a long time already, it must work this way because of the nature of git, commit chain must exist so once public - always public to make forking possible. It was always clearly stated in docs. Since you can create infinite private repos now, the way to go is to start from private always. If you want to push some code to public, you can copy files into it to not push commit chain or else it will remain public forever
Yes, likely. It’s just dangling commits. This is normal behaviour. You have to clean the repo to remove them but even doing that someone might have them stored locally from a pull
Also if you have code in your repo and you force a push with the initial commit, the repository will only have 1 commit BUT if you know an old commit, you can go and visit it's code. I wanted to delete the code from a repo for a client who didn't paid for my job and I saw that even tho you force the deletion of your own commits, by knowing the commit number you can still access it. My solution was to delete that repo and create a new one.
"deleting" has a relative meaning (I think since forever). On HDs, deleting a file means "forget that this file exists by marking the area where it is allocated as free space", so the file is still there and that's why file recovery software works. Some institutions never delete you data, if one of theirs users request account deletion, they will just mark a field "DELETED" in the database. So, I think is more about we not knowing how things actually work than a problem with GitHub policy or wording.
@@wesley_silva504 i would even say most institutions soft delete (mark stuff as deleted in the db so it's not deleted but effectively acts as deleted) as opposed to hard delete (actually remove the data, be it a file table deletion or actually erasing/wiping the data off of the disk)
@@wesley_silva504 it does not matter, EU policy requires companies to delete data so it can never be restored (and the user can always request it). if you violate it, it's a companies problem. it must be enabled and accessible in some way.
I do see the point. But like, what if you, as someone of a company repo, post a secret, that now seems can't ever be deleted, unless youpurge all parent forks. That redic., I can see that, and I don't even work for a company.
This is why you always revoke the API-key when it's been exposed. Trying to hide the fact it was exposed is dumb -- the only solution is to revoke the credential and create a new one. Also, all API keys/tokens should have expiration dates forcing rotations (ie: 30 days, or a year at most).
So... What's the likely hood that somebody is able to brute force the hash commit on your specific fork targeting the correct commit that has sensitive data? Even at 6 characters, the amount of additional knowledge needed is crazy.
It always amazes me that people think that “private” things on public servers are actually private. I will never understand why people are so trusting.
I think it's about how private it is comparing to other storages. E.g. some Imgur or pinterest where you can store some images are completely public and open unlike github private repo. And, of, you're right. There is no more private thing than your own HDD without any connections to www
This is Git as designed, Everything is remembered and nothing is deleted. That's why education on usage is always: "Never put secrets in version managment" And also If it happens, don't just remove but recreate secrets. It's like putting a sticker on your car with your password and then setting the car in the sun. If you remove them you still see the text so if you where doing a human (bit stupid) mistake of putting your password on your car for everyone to see you don't remove the sticker but you change your password.
Lol, this is definitely not how git was designed. Git was designed to be distributed. Somebody doing something on their version of the repo should never affect yours unless you specifically fetch the changes. And more interestingly a change that is only on your version doesn't just suddenly appear in another version. It's also not true that nothing is ever forgotten. Git has garbage collection to remove unreferenced commits. It doesn't run automatically in the default tools, but it still exists and is sometimes advisable to run.
I didn't but I do agree with their method, mostly. Something at the back of my brain tells me there's a better way to implement the fork system that doesn't involve sensitive data being exposed. What it is I don't yet know but I imagine the 1st step would be adding a feature called "scrub forks" that would involve direct intervention from github. When used you have to highlight the reason why you enacted it and when the employee at github assigned to the task goes through it they will decide on the spot if the srub should be done or if the scrub should be back peddled from it's partial state (having immediately blocked access to the offending data/code/etc in every fork of the project). Deletion or privatisation of a repo in general would not be cause for a scrub to be completed but accidental sensitive data would be. Also if that sensitive data happens to be something like a SSN and one or more users have downloaded those forks then their info would be handed over to the cops upon that sensitive data being used unlawfully.
Almost everything mentioned in this video is in reference to dangling commits. This is a feature in git itself not just GitHub. Help docs on GitHub for removing sensitive data specifically mention contacting them to clean a repo of dangling commits. This whole video and article seems like a lack of understanding of git workings.
I can't understand how big companies didn't think to rebase the history in git when manage sensible data (env keys, etc) 'basic principle of www security, nothing is secure'
It’ll still be a dangling commit. You have to clean the repo to remove them. Help docs on removing sensitive data specifically mention contacting support to do this. This is how git works. Without it there would be no “restore branch” and much more
Ah yes, the modern day "the internet has no delete button, no matter how much corporations want there to be one" moment. Except in this case, it's _a corporation_ that removed the delete button.
I can only feel bad for whoever gets access to my private repos, I privated them specifically so that people don't have to waste time looking at personal horrible code
Delete your commits, force push, delete fork. For public repos it makes sense if you can't reliably delete them. Anyone can fork or clone it at anytime anyways. My experience with GitHub has been that you can't create private forks of public repos. Instead you can clone locally the public repo, create blank private repo, set remote of your local clone to the blank private repo, push. Private forks don't make much sense to me. Last thing I want is someone to make a private fork of my gpl repo
Commits will still be dangling. This is a git feature. You will need to do all this and then clean the repo. For which you need to contact GitHub support. It’s all mentioned in their help doc on removing sensitive data.
Yeah, if I wanted a truly private repo, I would just rent a VPS and set up either just plain git server, or some open source github clone (I'm sure there are such tools) if I worked with a team and cared about stuff like issue tracking and pull requests. But private github repos are still good enough to stop common script kiddies from getting your code.
I always say that intentionally introduced bug is way worse than an accidental one. These are prime examples of intentionally introduced bugs. The takeaway is simple: Github's security is a sham, period.
so brute force really only requires a single 16 bit counter in the absolute best case scenario and in the case showcased all needed is a single 24 bit counter. nice.
enterprises should force checking credentials before commit, and prioritize self-host git server. Source codes now become the most valuable resource that being freely abused by hungry AI companies.
1. You are right, I did not know that GH worked like this. But this is clearly my fault as I did not read that part of the documentation. 2. If I make a stupid commit, then this is also my fault. "Private" or not, dont commit if you cant commit to it. Nothing to see here...
How to make a 15 min video showing you are (or were) clueless how git works. But it’s very important because people who don’t know this can learn from it so I still give it a like.
I would always make a public fork if i wanted to make something opensource. I could just sync the commits I want in that public fork and use the still private upstream fork as a dev version or something.
Wow, this is a disgraceful 'feature' People will jump on the 'don't hardcoded secrets' but it goes well beyond that.. Forking: bad Copy/paste: good Thanks for making this video.
this is not a "deleted repository" this is an audit/history of the commits. and as the header says it, it doesn't belong to any owner, it's a thing for github service, they need this sort of audit or history no matter what, so ofc it's a "feature" and not a bug. that's how audits / history work when you deal with public platforms. they are required to store the history even for deleted accounts for legal purposes
![The moment we stopped understanding AI [AlexNet]](http://i.ytimg.com/vi/UZDiGooFs54/mqdefault.jpg)
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
The issue is not that the feature exists and works as documented. The issue is that it deliberately uses misleading terms.
"Delete" that doesn't actually delete data should not be labelled "Delete".
"Private" that doesn't actually make data private should not be labelled "Private".
Nothing digital is ever deleted, even on your own personal device. Anybody using GitHub should know that.
How dare you demand that words have a meaning in today's age? If words had meanings, it would mean that nobody could ever twist their previous statements and shift their liability onto the reader. We can't have that!
@@lamjeri I think a big part of why words don't mean anything anymore is DEI hiring and especially hiring non-English speakers to work on English language products. They literally don't know what the words mean and correcting them is racist so no one fixes it.
@@MrBenMcLeanWhat? That's the weirdest rant I've seen this week. Okay maybe the second or third weirdest but still. Companies don't bother with that especially because they'd look unprofessional. They don't bother with corporate talk... No, they don't JUST bother with corporate talk. Nowadays, they lie and create false presentations for their products from Google to the smallest company.
@@MrBenMcLean DEI non-sense started removing meaning from words like gender, that is true, but in this case, it's not about that.
Companies are still using words like "delete" and "private" because that's been used for decades. But delete button no longer deletes anything simply because the company wants to sell the data. So delete button nowadays means "stop showing my data to me and keep it for your needs".
i've read somewhere that "Delete" of something in the cloud can be translated to "make it inaccessible for me".
thats soo nasty who tf said that
One man's trash is another man's treasure. lmao "Oh, you don't want it anymore? Well, it's mine now."
@@DZZYGaming good approach to sharing data
@@DZZYGaming
an honest man
@@DZZYGaming but that's true, everyone that made at least one web app will tell you that. Its true for every app, not only cloud.
You know. Words mean things. So people think things marked PRIVATE are, you know, PRIVATE. Same with deleted. So people don't delve into the bowels of documentation because they know what words mean. The don't think that a 3rd party went and redefined the words out from underneath them. Another example recently is that Ohio has declared that boneless wings are allowed to have bones in them. Sorry, the rest of the world stupidly believes that boneless wings are sans bones. Silly rabbit. GitHub, don't hide behind the fine print. Tell people upfront what your terms mean. Another approach would be for GitHub to provide an ERASE feature. Kinda like when you delete a file, it's not really gone. Just the pointer is gone. But, if you erase it, then the data is gone too.
Well, businesses are already used to use inaccurate terms. For example, if you "buy" a digital good these days usually you don't actually buy it, you just get a license that may become useless as soon as their DRM servers are switched off, which essentially may happen at any time.
soft deletion is a b*tch!
Security is a weird beast. It should always be assumed with distribution or central networks that any permissions inherited is difficult and easy to get wrong. It should always be assumed that you should create a new thing and hard copy the information to that new thing.
If you want premium features to an open source thing then you should introduce a plugin network and architecture and create a plugin that adds premium features. This allows for complete separation and removes the need for a fork.
This is technically true for any network or graph. A new network that is not connected in any way is almost always safer than any connection to be the other network.
A segmented network may hinder or slow down a hacker but won't stop the hacker. Only physical separation would prevent the hacker from switching networks at some point.
The security concerns are saying that you should create a physical boundary and that GitHub will not assume you wanted to create a boundary. Doing this would probably break and introduce a lot of edge cases and bugs that customers would complain about.
Do security right. Be paranoid and assume a breach will happen and mitigate against it. If your repo becomes public through a mistake then how destroyed are you?
Best case, not at all. Or use GitLab, mercurial, self hosted. Most enterprises are self hosted with either bitbucket, GitLab, GitHub, homebrew, etc for this reason. They can't afford any exposure and having more control won't remove the risk but reduce it.
Ah, the young learning that there's a whole "class of man" out there subverting the definitions of words (to make them less intuitive). That's how they do "liability shifting" to avoid being blamed for future problems. You start to learn what companies/humans are good and bad, just by recognizing that behavior.
The computer science industry is riddled with these types of guys (and professors (and white papers (and politics))).
Especially in the computing world, terms have always been a bit wibbly wobbly, haven't they? Back in the MS DOS days you could delete files, sure. But then you could "undelete" them again, meaning that they haven't really been deleted in the first place.
Nowadays the term "delete" has often times been replaced with something like "move to bin", but with how storage devices work, even if you empty the bin and thus "delete" a file, it's usually still there. And it's only getting worse now that everything is being synced into "the cloud" where everything (probably, perhaps not, who knows?) has a backup anyway. Who can tell what the word "delete" even means? 🤷♂
Exactly why new coders are advised to **never** hardcode sensitive data
edit: ah, it got worse after I made that comment
never share your secrets
also just rotate api keys, deleting the repo because of a leak is stupid, make the secret not valuable anymore and move on
I never did. And I hardly use github as a repo since I know how to call my local hard drive on the closed network.
@@joeyghostx self hosting gitlab is the way
Watch the third part, about accessing private repos
please... Turn off the face tracker, it's the most distracting thing after tik tok car slides.
True
i am very happy to not know what tik tok car slides are
I barely notice it.
Idiot@@rizzwan-42069
Would be fine if it didn't glitch every 10s
Ah... The "you're holding it wrong" response
As a gun guy, I took this personally. They say Glocks don't jam but when I watch police videos they jam all the time. Turns out it's hard to hold anything right when you are being shot.
"There is nothing you can do to remove that data"
**Laughs in filing a GDPR "right to be forgotten" request**
yeah, that doesn't work in the us...
@@bonniesitessolutions7728it does
Title should be: Private forked github directory are not as private as you think.
Not even that, as the fork is explicitly "public" (1:44)
Completely misleading, tho I can see how new github users can get confused over it
To those saying "this is a git issue": No it's not.
Git doesn't have any concept of forks on the same host (unless you consider worktree that, but it really isn't the same). Initially, people sent git repos directly to each other. When you had a fork, you had a copy of the original at the time of forking, but the original has NO knowledge of you. Likewise, the fork has NO information about the original outside of possibly an URI to it.
Personally I'd expect that if I delete a repository, it should actually delete the repository. There is really no reason why I'd still need the commits in any other repository, fork or not.
Of course it makes sense to store the same commits in multiple repositories together to save space, but unreferenced commits really should not ever be transfered.
This just sounds like they did not want the additional risk of fucking this up or of people doing weird shit, like using a commit hash in their scripts, because they don't understand git gc.
How can you start by saying this is not a git issue and the proceed to explain how git screwed up? I don't follow your logic. This totally a git issue. They provide a delete button, it should, you know delete things. your explanation does nothing to address private repositories.
@@CoreyKearney Git and GitHub are two different things. Git is fine (for this at least), this is a GitHub problem.
@@CoreyKearney git was invented by Linus Torvalds and open sourced, it's installed by default on many Linux distros. In contrast, Github is just providing servers and a wrapper around git.
@@XGD5layer Thanks tips.
@@XGD5layer And we all know how much Linus likes github riiiigt... xD
You can email support and just politely ask them to move your private repo to it's own fork network separate from the upstream. That's the solution I have used.
and they actually respond to requests like this? that is interesting, if they have a solution to this problem why not apply it automatically?
@@semmu93it's possible that they do listen to requests like this, but of course with all business they prioritize their enterprise customers first who are most likely the people who care enough to actually go out of their way and raise a support issue like this in the first place
@@semmu93yes. It’s even mentioned in their help docs on removing sensitive data. They will clean up dangling commits
@@semmu93 why would microsoft do something convenient to users ? they're microsoft
Or you could clone the repo, delete the .git folder, init a new repo and commit all files, push the new repo to github.
TLDR; privacy you want - fork you do not. as separate remote a new GH repo you create
thanks yoda
Or, you know, stop using GitHub.
no tldr is rotate api keys instead of deleting repos for no reason
Grug agree, no need reach for club
@@zBrain0Yes, stop using the most popular version control platform in existence, I'll get right on that and rejoin Linus in his mailing lists 😅
This sounds like a GDPR-bomb waiting to implode upon Github.
But they do document it if you look closely enough so they're in the clear. edit: the wording itself maybe not when scrutinised legally but I do not know.
this should not be legally acceptable, the least they could do is add a concise note informing people that their code is not actually private or removable
@@Bozebo putting a clause in a contract does not overrule the law. It looks like a violation of PIPEDA and the GDPR.
@@Bozebo Just because you document that you break the law doesn't make it any better.
GDPR are only for person data, not private data
If I understood correctly, if I make private repo from scratch and don't do any fork of it then it still will truly be private? Issue is only when forks are involved?
yeah but how will THAT generate clicks on the video?
@@hglbrg yeah kinda clickbait. but at least i know im safe ... for now
Nope. Guaranteed GitHub can still get into your private repos.
I still wouldnt trust github for anything REALLY private that you absolutely cant have leak. But for stuff that wont get you sued or your identity stolen it's fine.
@@airman122469 obviously. But we are talking if ANYONE can access it. and what we know so far, they cant
Fair enough, make it a feature. But this should show up a a clear explicit warning in the UI at least in the case when you are making public a private repo with forks.
So, to summarize:
1. Data once made public stays public. Perfectly reasonable, this is how Internet works. If you publish a secret, you cannot delete it, only invalidate it. No surprise here at all.
2. Purely public workflow works as intended.
3. Purely private workflow works as intended.
4. Mixed public-private workflow may have some hidden traps. Well, maybe GitHub should put some kind of notice on switching repo form private to public, like “this can expose private data even beyond what is contained in the repo”. Other than that, the behavior is rather reasonable once you read the documentation. (Personally, I would not perform such a switch at all, just to avoid reasoning about the consequences. Creating a new public repo and pushing the necessary commits to it is a viable alternative.)
I think the warning needs to go in the forking action actually. If the person who forks is different from the maintainer of the original repo, then it's outside of the control of the fork owner WHEN the commits potentially become public. Of course, if the original repo is private when the fork is made, that must mean the forker has been invited to the private repo, so there must be some pre-existing connection between them. But this doesn't guarantee that they communicate (if it's a different department of a company).
Essentially, if you fork a private repo, you will forever run the risk that your private fork becomes public.
You cannot securely delete data from the internet, because someone could have copied the data. Once published it might be to late, so you have to assume the data is no longer private.
Github always deleting the data will not significantly improve the situation, but might more easily break code depending on the repository.
Github might still be able to improve warning messages before making stuff public.
Yup, I don't even understand how one makes a "private fork of a repo". What is a private fork? There's forks, fullstop.
@@christopheranderson2100 yes in some cases if you have a repository on an account but you also want same repository in another account but still you want it should be private and can be accessed internally then on that case we may can use private fork
I thought this was common knowledge after the linux meme on april fool's day
Crazy coincidence that I was just thinking about if private GitHub repos not being private as a random passing thought and this video popped up in my feed shortly afterwards.
Aaand.. that's why anything you want to keep private, just don't put it into the clouds, period. Everything will be made public eventually. You keep it in a loca self-hosted repo etc. Never know when and how, but stuff like that will keep happening.
Maybe works for you, but doesn’t work for anyone
@@HackerFroschand if you're one of the people it doesn't work for you just accept it. You knew the risks.
Companies often have their own self-hosted Gitlab.
And how exactly do you expect AI to "train" (aka steal) your code unless you upload it to the cloud??
@@HackerFrosch speak for yourself. Not everyone joined the cloud, um, club, It works for enough people, apparently, so not "anyone". Cloud is just a fancy word for "servers not run or owned by you". Trading convenience for control.
Things like this are the reason why we consider API keys committed to a repo a security incident. Regardless whether it's public or private. Resolving the incident is only possible by revocing the key.
I accidentally pushed some JWT private keys in the repo at my prev. job (no that's not why I was fired), it was a private repo with no forks, and was never intended to be published, it's a closed source laid SaaS product. I still had to delete the commits, force push stuff and ask the GitHub support to actually delete the commits from their servers. apparently it wasn't feasible to invalidate the jwt private key.
@@Kitulousit wasn't feasible to replace the private key? I sure hope they don't have a _real_ breach...
My employer's Open Sourcing Guidelines say to make a copy of the latest state of the internal repository when making it public. So no sharing of commits. (We are using an internal Github Enterprise anyways, let's see how this changes when we migrate to Github Enterprise Cloud.)
Thanks, I was not aware of this.
IMHO, they should probably change the word "Delete" to something else, and had a short reminder in the "delete verification" dialog, that public repos are never rely deleted (with link to doc). There should be a similar reminder when making a private repo public.
Glad that I setup my private Gitea all those years ago...
My git hub repos are exactly as private as I think. They're set to public. Seriously though, sharing this at work.
12:03 "The author of the blog post agrees with me" lol, it's you who is agreeing with the author as the blog was written prior to you reading it.
I accidentally got this video to play and just heard this. Once he writes some code, he'll understand. I may have misunderstood, but I don't think he's teaching his audience to be careful, but he's learning about programming and how git works. Or maybe it's just the tone of his voice that makes is sound like he's blaming Github or whatever.
@@OfficialSkankyRichyeah he should learn first and then do videos about it not the other way around
This entire video is just someone reading a blog post written by someone else.
11:51, what people need to understand is anything you put online is in risk of being made public and might never be able to remove it completely. Does not matter what people "assume", if it is made public by user error or exploit, if you don't want it public, don't put it online.
Maybe Self-Host is the answer
gitlab is looking kinda appealing...
Yep. If you actually want your private stuff to stay private, self-host behind a VPN, preferably put behind a beefy firewall.
@@tzebruh google "gitlab security breach" and you might change your mind unfortunately. Self host might be the only way to go for the things you really, really want to control absolutely. :(
good luck
@@tzebruh gitea even better. I have working sync with github without paying premium required by GitLab.
With API keys, you can just rotate the key, like you said. What's really scary is when you have a private fork with paid features, this is a big business risk
Well running businesses will rotate the API key but lot of businesses are a complete mess. Add some temporary contractors that get let go, some mergers and acquisitions and you now have a system that no one actually knows how it works -- and sometimes doesn't know that it exists. Those API keys are never rotated or even known about to put in a security audit.
It's not. You will see the private code from the still private fork in the now public root repo, only as a reference in a PR. Meaning at some point you actually was about to merge it.
Making a private repo public is sort of dumb anyhow -> the moment you do the link is severed and you can no longer make PRs from the root to the "not a fork anymore" . So why are you sharing all this issues PR and shit. Just start an new bare repo and push your main branch to it.
07:30 deleting the repo is a stupid reaction, they should be rotating the api key or whatever secret and move on, the commits being available after is a good thing
Bro your channel is awesome. Keep it up!
From my understanding, one goal behind this is to allow restoring pull requests to your repository even if the PR author deleted the branch or repository. Plus of course, saving storage space by not duplicating data across forks.
they could at least check if the person has any permisisons to see the contents of the commit by the link. e.g. if I don't have access to a private fork repo, I shouldn't have access to the commits from that private fork repo via a public origin repo.
@@Kitulous The way git data is stored, the individual commits are not linked to repositories they belong to (and most commits are actually in all forks of a network). So doing this needs some extra care.
You explained this super well but that shaky camera literally gave me nausea and i was LAYING DOWN. If you can stabilize it that would be great. Makes it really difficult to watch but I enjoyed the way you explained the situation.
Your example works because when you forked the repository you didn't notice your copy of the repository was public.
If you made it private, then commit anything afterwards, it wouldn't be accessible.
I clicked on the video as I saw the StardewValley truffle icon on the thumbnail. I thought this was going to be a security rant by a character in Stardew
In all fairness, anything you make public for a millisecond can remain part of public record forever. Not sure why anyone would expect otherwise. So not a big deal.
Also not sure why people are surprised that other forks (including the upstream) have access to your fork (sort of the point). Again theoretically someone can merge your code the moment you make it public, so removing it from your repo means nothing at this point.
I would agree that private repo made public exposing code of any forks is weird. But private forks are sort of weird anyhow. I would personally say it's sort of weird making a private repo public -> you sort of share all your messy history and whatever. Most people will rebase a branch and push it to a new public bare repo.
Say you have something questionable. Then someone makes a comment in the code review. You remove and force push -> the comment will still be there.
That's why you never push things to GitHub that contain critical information and if it happens anyway the very first thing you'll do is immediately revoke the affected key. Don't even try to cover it up and just delete the repo or commit.
"Github" and "private" now that's funny
Great vid. Very well put together. Glad you showed up in my feed
After hearing a lot of such security stuff recently, i begin to consider that private is synonym to offline or to things-that-never-sent-to-3rd-patry. And if there is a public site telling you about how private they are or having "private" features then it's definitely a lie
4:39 interesting part starts here
and ends verryy shortly after
I did not know it work that way. But the issue with upstream repos not having their commits delete when the repo is deleted AND there is at least 1 fork. Makes absolute sense to me. Since this allows a fork to grab the latest changes that the owner of the fork would like to integrate from the upstream repository.
Well,i think that no one should expect deleting anything from the cloud would wipe the data from their servers,since the data is being tracked or marketed anyway,so maybe just dont commit sensitive info or keep rotating API keys
But with the enterprise features,i agree thats a real issue💯
9:01 IDk if I am too late to this but when I tried to fork one of my private repose it said "cannot fork because you own this repository" I think this only applies for organization's repository's.
Woah. This... is scary.. also, you deserve more subs!
So from my understanding, you need to create a fork as a prerequisite. What happens if you don't? Also, deleted repos are not fully deleted for at least three months.
I tested this with a private repo that doesn't have any forks.
A force push to the GitHub repo only cleans up the previewable commit history, but you can still access old commit links (lost via rebase squash for example).
When you clone from this repo, the dangling commits are not reproduced in these local clones, but they still exist on GitHub.
The only way to get rid of these dangling commits on GitHub is to delete the repository on GitHub, to recreate it, and then to push from any of your local clones.
Only then are the commit links inaccessible from the entrypoint of your repo name.
My guess is that the deletion and re-creation assigns a new id to the same repo name in their database, making the old links refer to the new repo which doesn't have a history of dangling commits.
The problem here is that any kind of fork off this repository would make it impossible to truly delete on GitHub since they effectively copy it and make a new entry point to all of its commits for each fork.
Lord have mercy.
They just need to add an options to disable forks on sensitive repos
So orgs can have a setting to say all repos created can never be forked, if a repo is made public it’s public there are no private forks
There is such an org setting letting org admin disable forking of private repos. You can also set it for individual repos. But it currently still allows forking of public repos though.
This is already a thing.
A lot of this seems like a fundamental misunderstanding of git itself. Same thing would happen if the data was shared on the blockchain. Actually deleting something from git history is challenging and can break anyone referring to the repo, and that's on top of the problem of doing timely deletes in a distributed storage system. You can push all the deletes you want, or delete the repo, or even delete your entire profile, but no matter what you do there is a window where someone could have pulled the repo to their local disk, and there's nothing you can do about those copies. If you pushed a private key, it is burned, no matter what you do going forward.
The ordering issue on promoting/demoting repos from private to public does seem like an actual correctness issue, and it would make sense for them to fix things so it works the same regardless of ordering.
Yes, never push private data. Probably also be aware that git history rewrites also do not erase the past. Most notably in pull/merge requests where commits are listed like some kind of audit log. The best would be to be able to trigger some "git gc" but I only think this is possible in gitlab and with higher permissions.
If you send data into the www, anyone can intercept it and also record (save) it between it being public and before deletion. Why one would commit and push API keys in example files for repos, I'm not sure. Either test it locally or use throw away keys. Everything else is just an accident to happen.
It’s strange that you can access a commit from a fork on the upstream without being merged in. It sounds like “repo network” is a fancy way of saying it’s really one repo and they do some internal branch renaming. And when you make a repo private they clone it to make it a separate network, but everything prior to that persists. I guess it kind if makes sense as it makes cross repo pull requests easy.
I’ve always thought forks were separate cloned repos, and new commits on the fork were only on the fork, not upstream unless you merged something in. But from a data storage perspective it can make sense. Why duplicate commit data if you don’t have to.
From early days if GitHub it makes sense. But it makes private repos look like an afterthought.
when you see it (by it i mean the osu repo at 1:33)
The documentation doesn't even seem to mention the fact that deleted commits are still accessible. That's a pretty big oversight.
I knew it for a long time already, it must work this way because of the nature of git, commit chain must exist so once public - always public to make forking possible. It was always clearly stated in docs. Since you can create infinite private repos now, the way to go is to start from private always. If you want to push some code to public, you can copy files into it to not push commit chain or else it will remain public forever
told 4o to inform itself about it and it said best practice is to avoid storing any sensitive data on github. that's wild
Why is there a truffle in the thumbnail?
haha same question
Is that the same on gitlab and bitbuchet?
Yes, likely. It’s just dangling commits. This is normal behaviour. You have to clean the repo to remove them but even doing that someone might have them stored locally from a pull
wow. this is clearly a design flaw, i'm really surprised at the github's response
Is the purely a Github issue or Git? And does BitBucket have the same issus?
Also if you have code in your repo and you force a push with the initial commit, the repository will only have 1 commit BUT if you know an old commit, you can go and visit it's code. I wanted to delete the code from a repo for a client who didn't paid for my job and I saw that even tho you force the deletion of your own commits, by knowing the commit number you can still access it. My solution was to delete that repo and create a new one.
Bru, im f'ed.
Why it called delete if not delete?!
Is that not against privacy policy??!
"deleting" has a relative meaning (I think since forever). On HDs, deleting a file means "forget that this file exists by marking the area where it is allocated as free space", so the file is still there and that's why file recovery software works. Some institutions never delete you data, if one of theirs users request account deletion, they will just mark a field "DELETED" in the database. So, I think is more about we not knowing how things actually work than a problem with GitHub policy or wording.
@@wesley_silva504good luck explaining that to GDPR
@@wesley_silva504 i would even say most institutions soft delete (mark stuff as deleted in the db so it's not deleted but effectively acts as deleted) as opposed to hard delete (actually remove the data, be it a file table deletion or actually erasing/wiping the data off of the disk)
@@wesley_silva504 it does not matter, EU policy requires companies to delete data so it can never be restored (and the user can always request it). if you violate it, it's a companies problem. it must be enabled and accessible in some way.
I do see the point.
But like, what if you, as someone of a company repo, post a secret, that now seems can't ever be deleted, unless youpurge all parent forks.
That redic., I can see that, and I don't even work for a company.
This is why you always revoke the API-key when it's been exposed. Trying to hide the fact it was exposed is dumb -- the only solution is to revoke the credential and create a new one. Also, all API keys/tokens should have expiration dates forcing rotations (ie: 30 days, or a year at most).
So... What's the likely hood that somebody is able to brute force the hash commit on your specific fork targeting the correct commit that has sensitive data?
Even at 6 characters, the amount of additional knowledge needed is crazy.
It always amazes me that people think that “private” things on public servers are actually private. I will never understand why people are so trusting.
I think it's about how private it is comparing to other storages. E.g. some Imgur or pinterest where you can store some images are completely public and open unlike github private repo.
And, of, you're right. There is no more private thing than your own HDD without any connections to www
This is Git as designed,
Everything is remembered and nothing is deleted.
That's why education on usage is always: "Never put secrets in version managment"
And also If it happens, don't just remove but recreate secrets.
It's like putting a sticker on your car with your password and then setting the car in the sun.
If you remove them you still see the text so if you where doing a human (bit stupid) mistake of putting your password on your car for everyone to see you don't remove the sticker but you change your password.
exactly my point
Lol, this is definitely not how git was designed. Git was designed to be distributed. Somebody doing something on their version of the repo should never affect yours unless you specifically fetch the changes.
And more interestingly a change that is only on your version doesn't just suddenly appear in another version.
It's also not true that nothing is ever forgotten. Git has garbage collection to remove unreferenced commits. It doesn't run automatically in the default tools, but it still exists and is sometimes advisable to run.
@@SourceOfViewsyes and guess what because it’s distributed, if someone downloaded it at the right point in time then he has the information.
Also it needs to be kept in mind that it works probably similar also on gitlab pr bitbucket.
@@mudi2000a I mean no shit. If you put something online and somebody else downloads it, they still keep it.
But that's not what happens here.
Are alternative platforms like gitlab or codeberg also affected?
I didn't but I do agree with their method, mostly. Something at the back of my brain tells me there's a better way to implement the fork system that doesn't involve sensitive data being exposed. What it is I don't yet know but I imagine the 1st step would be adding a feature called "scrub forks" that would involve direct intervention from github. When used you have to highlight the reason why you enacted it and when the employee at github assigned to the task goes through it they will decide on the spot if the srub should be done or if the scrub should be back peddled from it's partial state (having immediately blocked access to the offending data/code/etc in every fork of the project). Deletion or privatisation of a repo in general would not be cause for a scrub to be completed but accidental sensitive data would be. Also if that sensitive data happens to be something like a SSN and one or more users have downloaded those forks then their info would be handed over to the cops upon that sensitive data being used unlawfully.
Almost everything mentioned in this video is in reference to dangling commits. This is a feature in git itself not just GitHub. Help docs on GitHub for removing sensitive data specifically mention contacting them to clean a repo of dangling commits. This whole video and article seems like a lack of understanding of git workings.
So... it's not accessible if the fork is not deleted?
Does with also work on GitLab?
Yes.
Best GitLab ad ever
Will work in the same way. This is just how dangling commits work in git.
I was always taught and have taught others, never to use forks for this exact reason
I can't understand how big companies didn't think to rebase the history in git when manage sensible data (env keys, etc) 'basic principle of www security, nothing is secure'
It’ll still be a dangling commit. You have to clean the repo to remove them. Help docs on removing sensitive data specifically mention contacting support to do this. This is how git works. Without it there would be no “restore branch” and much more
Ah yes, the modern day "the internet has no delete button, no matter how much corporations want there to be one" moment. Except in this case, it's _a corporation_ that removed the delete button.
would GH event actuly contain private fork commit event?
No. What he was referring to about archived commits is only for public ones
And this is just another justification for why I now host my own gitea instance that is truly private.
this is shocking! i definitely did not know or expect this
Why is there a SDV truffle in the thumbnail?
thank you. thought i was the only one who noticed
This was so random hahaha
wow imagine the amount of API keys that are currently being farmed by bad actors.. amazing
I didn't know that - and it makes me rethink my usage of github.
It never made sense to me why commits in forks were in the url of upstream
Who would have thought Microsoft owned software would be trash
13:01 The enterprise uses self-hosted or gh on premises under different domain, completely not accessible to the "normal" gh
I can only feel bad for whoever gets access to my private repos, I privated them specifically so that people don't have to waste time looking at personal horrible code
Delete your commits, force push, delete fork. For public repos it makes sense if you can't reliably delete them. Anyone can fork or clone it at anytime anyways. My experience with GitHub has been that you can't create private forks of public repos. Instead you can clone locally the public repo, create blank private repo, set remote of your local clone to the blank private repo, push. Private forks don't make much sense to me. Last thing I want is someone to make a private fork of my gpl repo
Commits will still be dangling. This is a git feature. You will need to do all this and then clean the repo. For which you need to contact GitHub support. It’s all mentioned in their help doc on removing sensitive data.
Yeah, if I wanted a truly private repo, I would just rent a VPS and set up either just plain git server, or some open source github clone (I'm sure there are such tools) if I worked with a team and cared about stuff like issue tracking and pull requests.
But private github repos are still good enough to stop common script kiddies from getting your code.
correct words should be forked private repository?
I read something about forks, it said that you cant private fork since it would be easy to leak private data anyways. Whats the point!
I always say that intentionally introduced bug is way worse than an accidental one. These are prime examples of intentionally introduced bugs. The takeaway is simple: Github's security is a sham, period.
This isn’t a bug. It’s called dangling commits.
why is your camera stuck in 2009
They dont even need to brute force bc they can prob access via internet archives.
what about if you degit the repo?
so brute force really only requires a single 16 bit counter in the absolute best case scenario and in the case showcased all needed is a single 24 bit counter. nice.
enterprises should force checking credentials before commit, and prioritize self-host git server. Source codes now become the most valuable resource that being freely abused by hungry AI companies.
1. You are right, I did not know that GH worked like this. But this is clearly my fault as I did not read that part of the documentation.
2. If I make a stupid commit, then this is also my fault. "Private" or not, dont commit if you cant commit to it.
Nothing to see here...
This only works on forks right?
This seems like an oversight, delete should delete, private should be private, who would want to create a private fork just for it to be public?
Your video is blowing up in views! Thanks for the info :)
this camera is giving me nausea... plz take off that tracker, else, good video :)
How to make a 15 min video showing you are (or were) clueless how git works.
But it’s very important because people who don’t know this can learn from it so I still give it a like.
I would always make a public fork if i wanted to make something opensource. I could just sync the commits I want in that public fork and use the still private upstream fork as a dev version or something.
Wow, this is a disgraceful 'feature'
People will jump on the 'don't hardcoded secrets' but it goes well beyond that..
Forking: bad
Copy/paste: good
Thanks for making this video.
this is not a "deleted repository" this is an audit/history of the commits. and as the header says it, it doesn't belong to any owner, it's a thing for github service, they need this sort of audit or history no matter what, so ofc it's a "feature" and not a bug. that's how audits / history work when you deal with public platforms. they are required to store the history even for deleted accounts for legal purposes
No. It’s just dangling commits.
What if a repo is created as private and kept private?
Randomly got recommended this video…is the thumbnail a pic of the truffle from stardew valley?
How about amended commits?
I'm at a lost for words. This is not something the average user would expect and I can't believe that this would be compliant with GDPR.
I think GDPR mostly does not apply here. Git repos should not contain sensitive personal data
@@ultramoxx1148 commits contain my name and email and that is personally identifiable information no?
@@ultramoxx1148 Commits have a name and e-mail address attached to them. How is that not personally identifiable information?