MD5 password hashing: https://github.com/swituo/openbilibili-go-common/blob/8866d1...
Hardcoded credentials: https://github.com/swituo/openbilibili-go-common/blob/8866d1...
More hard coded secrets: https://github.com/swituo/openbilibili-go-common/blob/8866d1...
This configuration is my favourite: https://github.com/swituo/openbilibili-go-common/blob/8866d1...
And of course, RSA keys which they use for all of their RSA encryption: https://github.com/swituo/openbilibili-go-common/blob/8866d1...
... their problem is not that the source code is all public over the internet now... their problem is the engineering team. If source code leaks the worst outcome should be some IP leakage, but not a compromised live system. That can and should be easily avoided by not having everything in your source code, especially when you are such a big company with so many employees...
Here are some interesting things I noticed:
- GitHub has a lot of DMCAs each month and going through them it seems that all repos have been taken down by GitHub, but in this case the entire source code is still online despite it being posted here on HN for hours now and after they have been notified.
- None of the other DMCAs (some of them really interesting) have ever trended on HN
- The above linked repo has been forked more than 5k times, which is so much more than what any other DMCA reported repo has been ever forked from what I could see
- The repo with the source code put a link to https://996.icu in the description
- The person who posted the DMCA here on HN seems to be a new user who has only posted or commented on topics related to 996. Potentially the person/group has also gamed HN to get this link to the front page
There is no proof, but it feels like there is a very coordinated and deliberate attempt to harm Bilibili which is kind of sad.
https://gitlab.com/wkingfly/openbilibili
https://gitlab.com/panxue/openbilibili
https://gitlab.com/efsg/openbilibili
Either way, it's now spread to far and they need to take actions to protect their users.
I can forgive the use of MD5, because they probably just don't know their hashing/crypto but secrets? It's literally in the name.
There is so much material in your 5 links alone, that anyone who desires could utterly own their infrastructure, and then some.
Man, I have tons of auth data in services like AWS just in environment variables. But pushing your rsa key to github must have happened on a bad monday.
I do often have auth info in code, plainly because of time constraints. You just have to remember it before pushing anything on github.
But aside from that, is it possible to file a DMCA for anything that has been forked if it was published under a license that permitted that action?
Do you read commit history looking for, say, relocated secrets? Do you go through the pain of rewriting said history regardless of whether you avoid merges with your current workflow or not? For me, that's too many risky and involving things to do. This advice will only work if you're only going to export squashed commits from private repo to the public one once in a while.
As for the aside, I imagine (with no background knowledge here) that as "owner" if you accidentally published something within that licensed code that does not belong or isn't covered by that license, you should probably have the right to remove it
In some industries it’s also an audit or legal requirement that developers not have access to production credentials, so there’s no other way to reasonably handle that.
Edit: also, rebuilding your source because an API key changed... no thanks.
You open up the code, find all of the secrets (e.g. using high-entropy substring search), replace them with access to a global variable, and set it from a file set by a configuration from a command line.
Done.
You can take arguments or env vars or config files (not added to Git) for your secrets. If you begin with a system of not putting the secrets in the code, ever, it's fairly straightforward to not make this mistake.
A few minutes of setup on a repository and a mindfulness to be sure not to commit any new secret files that may be in use (and add them to the .gitignore) is a great start before getting to secret management a la Vault.
Even Apple has released code doing "dumb" things. goto goto for example [1]. This is a simple mistake, easily caught using proper code reviewing techniques and tools, and yet it still happened. This means they could have prevented someone making this mistake if they invested the time and energy doing things properly. This is Apple here. We aren't even talking about mistakes from Microsoft or Amazon or other major software companies.
And these people aren't dumb. Facebook isn't filled with "dumb" people, and yet, they've done far worse than Bilibili here with just their 'mistakes'.
The reality is, smart people do dumb things all the time because they are trying to get things done.
I'm not going to pass judgement on what other people did. I'm going to assume they did the best they could, and while they made mistakes, it doesn't make them dumb. Maybe someone got lazy, maybe someone was under pressure, and things just piled up.
"It's bad, but we'll get to it later when we have the time."
No one plans to have their code shared out to the public. I wonder how many of us could honestly come out clean for code they've written along the way. To not have someone say "Oh, you are using an older library there that's got a security bug" or "You shouldn't have done this" and what not.
[1]: https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-got...
What should I do with those secrets though? I'm not sure how to store them securely. So far I've been considering putting them in the server configuration so they can be read from environment variables, but that seems inconvenient for me and other developers and also not that much more secure.
You can hardcode the secrets to test stuff, but the first time you push the code to the repo should be the time you change it to reading from config. And add config to gitignore cause even if you don't stage the particular lines with the secrets in them, there will come one time where you'll rush or will have too long of a day when you'll push those secrets by accident. If you've got a public repo, then it's over. On a private repo then you may not notice this or not remember to remove it with a force push.
A point in time when you get tired of juggling config files manually in dev/prod is the point in time you explore the system for secret management and auto build/deployment as clearly your project has become useful/popular enough.
Those are my IMO and what I use as thresholds. Of course, if your environment is more relaxed there's no limit on further improving this practice.
Again,. the LEAST you should do is use environment variables and keep the actual keys out of your code. .env files are a developer convenience measure, and easy enough to use side channels. I go a step further and ensure a fallback that might be the dev environment, but that is not the same as any higher environment
So the question is who leaked it and why? Just a disgruntled employee or the effect of 996?
This is not some small-time shop, as far as social media companies go bilibili is one of the more established companies out there.
Correct me if I'm wrong but theoretically an overhyped two man operation running at a financial loss could generate the same market cap as a much larger company with massive profits? As I understand it, the only somewhat tangible factor is the actual money in the company which again can be bloated by overeager investors.
I'm not being facetious, I'm genuinely curious about the rationale.
As a first approximation, this is how much money it would cost to buy all the shares. You’d pay $SHARE_PRICE for each share and then own the entire company. Therefore the concept is a decent measure for what the market has decided the company as a whole is worth.
A company with 10x the market cap of a competitor is considered 10x bigger, because it would take about 10x as many dollars to acquire.
I say “first approximation” because if you actually tried to buy all the shares on the open market, then increased demand would drive the price up, and not everyone would want to sell right away. In an acquisition, the acquirer offers a deal where all shareholders get, say, 1.25x the current share price, but only if all shareholders sell all their stock. And the board of directors of the company being acquired can compel all shareholders to do so, if that’s in the best interest of the shareholders.
You can think of this as equivalent to the size of the company because it would be the amount of money you'd need (roughly speaking) to buy the entire company outright.
"I don't know if these are embarrassing... The troubles of morality are going out and turning right to pay attention to 996.icu"
The original repo was taken down, so I don't think you can attribute that message to the leaker.
https://github.com/github/dmca/blob/master/2019/04/2019-04-0...
Crazy.
https://github.com/shil99/android_test/tree/master/external/...
literally has their name in the path/package name, so it isn't crazy (unless you know more?) to believe that this was stolen/reverse engineered Symantec code, no? At LEAST it's a very confusing and misleading directory tree for a random repository?
Files below src/ should be sources, not a 3rd party Symantec lib or whatever, so I'd give them the benefit of the doubt here.
This seems to have been the main factor - com/symantec/mobilesecurity - in the code.
Source please?
FWIW, the report you link in your other comment has a screenshot of a conversation where someone claims that the code was leaked by an intern from Nankai University who didn't know how to use git. [1] That they're identified by their university makes me suspect that it's a rumor (edit: making fun of the university), though.
[1] https://www.heibai.org/zb_users/upload/2019/04/2019042306214...
https://ipfs.io/ipfs/QmYiQ5jbtmx24ketNA65MJ3VpSDFWikGmvnBErq...
flv.js is opened sourced by bilibili, it has 14,668 starts on github [1]. Bilibili paid the smart & hardworking programmer who single handedly started this project and made it popular $700 USD per month [2], there is a very long zhihu.com thread [2] on this matter with 4 million views and almost 400 detailed responses. $700 is about 10% of the fair market rate in China for skills like that.
Sorry, but I am not going to take the moral high ground and defend bilibili's rights any time soon. It is a company violating the rights of its programmers on hourly basis.
Shame on you BiliBili.
I think defending corporate legal rights is mostly not about morality which is why speaking about morals in this story is important.
Like in how the legal system it's not what's right or wrong or truth that's important but legal justice, so we need morality to play a part in making sure it doesn't get out of hand.
So you are suggesting $7000 for skills like that? There are still countless PHP / Golang / Rails jobs going for under $2K. While I agree $700 is insanely low even if you are in some Tier 3 cities, I don't think 10% paint an accurate picture of the current state of Programming Paid in China.
Apple does this with Mac OS X. The System Management Controller contains a key, and the "Dont Steal Mac OS X" kernel extension (which checks for that key) contains a poem that must be present for Mac OS X to run.
http://osxdaily.com/2010/03/19/anti-piracy-message-in-mac-os...
https://en.wikipedia.org/wiki/Anti-circumvention#Distributio...
The level of creativity needed for copyright is minimal. A key pair is generated by machine, but at the request of a human according to parameters selected by the human. That is likely enough.
OTOH, a passphrase of substantial creativity [2] may be protected by copyright. Crucially (for any takedown), this would cover transformations by key derivation functions.
IANAL.
[1] https://www.copyright.gov/help/faq/faq-protect.html
[2] https://fairuse.stanford.edu/2003/09/09/copyright_protection...
I have no idea what it means, but I like it.
Most of these probably also appear in World of Warcraft, though I cannot say for sure.
As to why this file is in the top directory of the repo, your guess is as good as mine.
Also there are a lot more heroes in the Dota map for Warcraft 3 than on that short list
This keeps my secrets out of the source code.
go build \
-ldflags="\
-X main.programVersion=`git describe` \
-X main.username=$USERNAME \
-X main.password=$PASSWORD"
This isn't perfect, of course, because you can just use strings(1) to find the secrets embedded in the binary, but it is a step up from what they did.It's fine for our internal go apps. I'm not sure what I would do if the secrets were for connecting to public cloud infrastructure though.
Perhaps encrypt them with a separate key per customer, then feed in the key via an env variable?
Any ideas?
https://github.com/swituo/openbilibili-go-common/blob/8866d1...
It's not a simple case either. But it feels a bit strange that there aren't any links to this kind of DMCA takedown. It seems strange that a company like BitBucket would even have this kind of information without the DMCA notice.
Or maybe I'm just a cynic.