This "feature" is probably outright illegal under GDPR regulations, the spirit of which says "delete means delete." Security considerations aside, I suspect this might be the result of a design oversight-a.k.a. cutting corners-from GitHub's early days, that is now very hard to change due to how it might have made its way into how the data is stored. Changing this might require some monster data migration. Let's not forget that GitHub was once a startup run by young people with little experience, not one of the backbones of the global software and internet industry that it is today.
The most serious part is the private repos. with public stuff, at least you know that once you make something public online, it's out there. but making a repo private and having all intellectual properties and secrets be still available publicly is a big NO-NO for enterprises. The commits done on the private repo AFTER it's been made private are still public. whose brilliant idea was this?
Screw the forkpocalypse. The thing I've been missing in Github over the years was a super simple feature. Let me group my damn repos by category or by tag like you do with with issues!!!
I don't believe that deleting the repository should be our first step for safety. Our first step should be revoking the API key as soon as possible. Why would we assume the damage hasn't already been done before we deleted the repo?
@@MrVanshajSaxena well If some one already has it, its not privet anymore. and I said " its not the 'first' step". ofc we should remove something like that from github.
wow, I had no idea. But, if you fork a public repo and keep it public, then there is really no harm done. But I agree, this is a surprising 'feature' of github
you don't need to keep it public for this to work, it'll also work if you fork form a private repo and make a branch public (including things pushed to the still private repo post fork)
Looks like github did it to save storage. So that they dont have to store the old commits of original repo in new forked repo. So when you search any branch or commit in forked repo, github goes to the original repo to find that branch and commit, instead of searching forked repo because it doesnt exist. And they forgot to stop this in other way around.
@@TheDrunkenAlcoholicanother radical idea: when it does get leaked, change it instead of wasting time trying to purge it from the internet. this is only *one* way that secrets can remain public, and its not the toughest one. this is like complaining about spilled milk on a ship that hit an iceberg instead of getting on a damn life boat
@@jotch_7627 I don't think that's so radical, its common sense, of cause you are going to change it....once you know about it..., but like I said no one intentionally pushes API's to github
@@TheDrunkenAlcoholic We have all done it at one time if we're long enough in the game. But we feel bad for a while, revoke the key, remove it from the repo, vow to never do it again (till the next time). Most of us do not blame the technology or the technology providers because they are not cleaning up fast enough behind our messes.
You made a Fork, Fork are public, Fork cannot be made private, Fork are part of the original project. I dont see any issue being able to see Public code related to a project, whatever is from the original or the forked one. I dont understand the issue?
GitHub cannot be trusted to never disclose or use your source code. If you want to keep your intellectual property private, then NEVER upload it onto a server that isn't under your direct control.
Oh I ran into this problem without noticing. I cloned a repository with a subrepository and despite never changing the URL of the subrepository to my own fork it just worked. Maybe that is why they have this "feature" in the first place?
So the leads me to the next question. Would this apply to on-prem version? I guess not, but then would an evil disgruntled internal developer be able to do something similar?
So you revoke the key. You should never commit API keys of course and if you do you should always revoke the key. The fork behavior is surprising but if you fork an open source project but don’t want to contribute to the project you can just clone the repo and push to a new remote.
@@2005sty more like to be able to quickly fork massive repos in minimal time. You would want to wait 10-20-60 min for a fork to complete just to update the readme. Also once it is public it is public. You cannot just delete it and call it a day. Deleting it is absolutely the wrong way of thinking.
Is it related to a GNU license? if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL. I don't know if your repository was public or private. edit: yes, it's public, so github is forcing you to comply with GPL. Edit 2: no, whisper is MIT license
this is a non-issue because the moment a secret is leaked, it is forever leaked. there is no going back. it does not matter how long the commit is visible or whether it goes away when you delete the forked repository because it is *leaked*. github is quite clear that theyll only bother with manual intervention when rotating the secret is not feasible.
I don't understand. You fork a public repo, which creates a public copy, and then you complain that the data is public? lol BTW the right thing to do after exposing a key is to disable/revoke the key, that's it
This "feature" is probably outright illegal under GDPR regulations, the spirit of which says "delete means delete." Security considerations aside, I suspect this might be the result of a design oversight-a.k.a. cutting corners-from GitHub's early days, that is now very hard to change due to how it might have made its way into how the data is stored. Changing this might require some monster data migration. Let's not forget that GitHub was once a startup run by young people with little experience, not one of the backbones of the global software and internet industry that it is today.
@@benjiro8793you published the data and gave github a license to publicly host it. its not illegal for them to host it. what a reactionary take...
Is this even personal data under the GDPR?
Now that's sticking by your principles, that's true open source
Wow, it really is by design …
This is crazy, it really is Open Source !
😂😂😂😂😂
& now your forked :)
I very much appreciate your new Vid, thanks!
The most serious part is the private repos. with public stuff, at least you know that once you make something public online, it's out there. but making a repo private and having all intellectual properties and secrets be still available publicly is a big NO-NO for enterprises.
The commits done on the private repo AFTER it's been made private are still public. whose brilliant idea was this?
Screw the forkpocalypse. The thing I've been missing in Github over the years was a super simple feature.
Let me group my damn repos by category or by tag like you do with with issues!!!
I don't believe that deleting the repository should be our first step for safety.
Our first step should be revoking the API key as soon as possible.
Why would we assume the damage hasn't already been done before we deleted the repo?
What if it's not a password nor api key, but still private information?
@@MrVanshajSaxena well If some one already has it, its not privet anymore. and I said " its not the 'first' step". ofc we should remove something like that from github.
That's crazy. So basically we shouldn't fork if we're not contributing to a project. Clone down and then create your own remote repo
Sounds like a fork is a branch. You can also not change visibility of certain clones
wow, I had no idea. But, if you fork a public repo and keep it public, then there is really no harm done. But I agree, this is a surprising 'feature' of github
you don't need to keep it public for this to work, it'll also work if you fork form a private repo and make a branch public (including things pushed to the still private repo post fork)
Thanks for the information. Unbelievable it has such kind of bug…
Looks like github did it to save storage.
So that they dont have to store the old commits of original repo in new forked repo.
So when you search any branch or commit in forked repo, github goes to the original repo to find that branch and commit, instead of searching forked repo because it doesnt exist.
And they forgot to stop this in other way around.
Radical idea: do not store secret and personal information in a version control system?
it can happen unintentionally, I have done it myself when testing API's local on my PC and forgot all about it and pushed to the remote repo
@@TheDrunkenAlcoholicanother radical idea: when it does get leaked, change it instead of wasting time trying to purge it from the internet. this is only *one* way that secrets can remain public, and its not the toughest one.
this is like complaining about spilled milk on a ship that hit an iceberg instead of getting on a damn life boat
@@jotch_7627 I don't think that's so radical, its common sense, of cause you are going to change it....once you know about it..., but like I said no one intentionally pushes API's to github
@@TheDrunkenAlcoholic We have all done it at one time if we're long enough in the game. But we feel bad for a while, revoke the key, remove it from the repo, vow to never do it again (till the next time). Most of us do not blame the technology or the technology providers because they are not cleaning up fast enough behind our messes.
You made a Fork, Fork are public, Fork cannot be made private, Fork are part of the original project.
I dont see any issue being able to see Public code related to a project, whatever is from the original or the forked one.
I dont understand the issue?
Didn't know it before, thanks for telling...
Great video Alex !
Thanks!
GitHub cannot be trusted to never disclose or use your source code. If you want to keep your intellectual property private, then NEVER upload it onto a server that isn't under your direct control.
does this work on private repos also?
Remember, God's temple (temple os) doesn’t do this. What happens in temple os stays on temple os.
Oh I ran into this problem without noticing. I cloned a repository with a subrepository and despite never changing the URL of the subrepository to my own fork it just worked. Maybe that is why they have this "feature" in the first place?
So the leads me to the next question. Would this apply to on-prem version? I guess not, but then would an evil disgruntled internal developer be able to do something similar?
Any safety in clearing things using a git forced push? Does that leave history?
I mean...you gotta rotate the key
what’s the use of having it upside down? 🙃
@@AZisk 😂😂😂
I use ROT12.
@@AZiskLMAO
😂 😂 😂
Microsoft always have to fuck things up…
Is the commit visible from other accounts?
Alex, was your fork private or public...?
the title should be "How get OpenAI secret keys for free" lol
because we can make a program that catch all the events that has some 'secrets', then use them 💀
jk we should never do this
I think git guardian already does this
This happened to me as well 😂
So you revoke the key. You should never commit API keys of course and if you do you should always revoke the key. The fork behavior is surprising but if you fork an open source project but don’t want to contribute to the project you can just clone the repo and push to a new remote.
OH MY LORD
I am shocked
All forks of public repositories are public, by DESIGN!!
What is the purpose of this design decision? To protect the owner of the repo?
@@2005sty more like to be able to quickly fork massive repos in minimal time. You would want to wait 10-20-60 min for a fork to complete just to update the readme.
Also once it is public it is public. You cannot just delete it and call it a day. Deleting it is absolutely the wrong way of thinking.
@@yodamastera I get your point
I would compare git commands generated for github and gitlab.
Is it related to a GNU license? if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL. I don't know if your repository was public or private. edit: yes, it's public, so github is forcing you to comply with GPL. Edit 2: no, whisper is MIT license
since gitlab didn't follow the same steps I guess it's not related to open source licenses but incompetent from github team.
Oh, wow!
this is a non-issue because the moment a secret is leaked, it is forever leaked. there is no going back. it does not matter how long the commit is visible or whether it goes away when you delete the forked repository because it is *leaked*. github is quite clear that theyll only bother with manual intervention when rotating the secret is not feasible.
what about the private repos that the post goes into
oh nooo, i love gitlab
API keys should be in a . git ignore anyway when deployed, of you're learning its easy to not do it but pros shouldn't have them accessible anyway
it's unfair, you tell the source in the last fifth of the vid, in effect usurping that person's find while still covering your a*
That is what "fork" means. It creates a branch
Who even pushes their secrets?
Even in an accident, you can just regenerate the token
This is just an example of that flow
Plus there are many people who accidentally put secrets on GitHub
It happens more often than it should... Even happened to me
@@Mempler Did you later regenerate your secret or made a video about it?
@@ramsey2155 nah, i let people use it
F 😂😂 k man.. 🤣🤣🤣🤣🤣
4:50 Hash is F000 so if you start on 0000 you only need 16 tries to get here? What?! 😂
I don't understand. You fork a public repo, which creates a public copy, and then you complain that the data is public? lol
BTW the right thing to do after exposing a key is to disable/revoke the key, that's it
W
When microsoft bought it i lost hope