... 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...
I don't know what to make of this, but this all feels like a deliberate attempt to damage this company.
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.
I've always wondered, how it could be that someone can be smart enough to write what on the surface is some fairly clean Golang, and yet at the same time, dumb enough to put secrets in the code.
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?
> You just have to remember it before pushing anything on github.
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.
The best thing to do is assume the secret is fully compromised the second it hits GitHub, and consider it worthless to protect with these measures. Get a new secret immediately and trash the old one.
I think they examples you've listed are different, and more acceptable than pushing secrets and private keys to Github because you had dozens of them hard-coded.
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
What if I accidentally contributed a little bit too much code to the Linux kernel? What if that code had been in the last 10 releases? What about the users and distributions running those versions?
I'm not sure the answer is, or should be, as simple as "derp - delete immediately, this was never meant to be Open Source".
That said, if the code was stolen, and then published under an OS licence - it's not OS. The "publisher" never had the rights to make it OS, so the "contract" is null and void...
This is what I was thinking. If it's something that wasn't meant to be published, I assume your right as the owner hold.
How you'd solve this, logistically in an example like yours (Linux kernel) I have no idea, but I presume by the time it's been made public long enough to be cloned/forked (a la the company in question in OP) all of your efforts should be focused on damage control.
That’s how it starts though. If everything is provided at deploy and nothing is ever embedded in source code there’s no way you can end up in this situation.
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.
> Add an OAuth-style negotiation for the key as the first startup process.
How does this possibly work? You must have some “bootstrap key” that you would use to fetch the API key. You’re going to ship something in the app that says “hey, I’m really your app” or else you’re doing to allow anyone to fetch your API key. All you can do is obfuscate the process of getting the API key. You cannot actually keep it secret when you need clients to have access to it.
Case in point: valid user credentials and it doesn’t matter what app is trying to authenticate. Issue a different key for every user (or every user per login or device) and your problem is solved.
Even if your app doesn’t require any login there’s no reason you shouldn’t go through the same process. Every device gets its own key and then you apply limits to it...
OK, this depends on what you mean by an API key. If you are referring to a security token that identifies the user, then yes, you should always be creating a new key per user, and often per session.
However the term API key may also refer to an App key, intended to identify all users of a given app. The intention there is to be able to engage and widespread revocation or throttling in case an app is misbehaving or compromised. You cannot keep this sort of API key secret because it must be shared and must be available.
In the non-user device scenario you mentioned, I’m pretty sure you would actually be better off simply having the device generate a random GUID instead of going through a pointless negotiation to hand out a random GUID.
I was actually referring to both, and I think the same process applies. Even if the API key is not for your service (like, say, a Google Maps key) there isn't any reason you can't fetch that dynamically from your server. There are also various solutions for secret storage on every platform (iOS and Android at least) that you could use to store it, rather than it being "public" in the app package.
You need an api key if you show Google Maps in your app. The api key allows your app, running on the users device, to get the map tiles. Is it possible to do that without the users device having access to the key? No. Does that require user login? No. Does ‘OAuth style negotiation’ have anything to do with that? No. Is it security? No. Can you change how Google Maps works? No.
It’s one of those things that you dangerously start when your project is small then when you balloon in size, you find that everyone is hard coding secrets in code and standing up some secrets infrastructure would take weeks to get right. It’s easier now with tools like Vault but let’s say you joined bilibili today - where do you even begin? You have a massive cultural problem before you even begin to tackle the technical one. Even a smart engineer may just resign to doing things the wrong way than trying to fight a huge political battle.
>> you find that everyone is hard coding secrets in code and standing up some secrets infrastructure would take weeks to get right.
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.
>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.
Huh? Amazingly you make it sound so easy when it's anything but. Where is this file? How is it deployed? How is it rotated? If I have 10,000 VMs, how do I deliver that file to those machines? If my VMs aren't persistent, how do I ensure new VMs are deployed with this file?
Or were you thinking that they would just ssh into production and scp the file into there? To me you glossed over so many details that you hardly solved the problem at all. Replacing the secrets in source code is the _easy_ part. Deploying secrets is the hard part.
There are tools out there to make this easy, but (1) they almost always make things harder for developers and (2) they almost always require a large infrastructure change. Sure, if your deployment is small enough where you could just SSH into a single prod server and scp a file - then you are likely miles ahead - in terms of both security and culture, but changing the culture is harder than it looks.
I don't want to sound like I am making excuses for them - but I only want to show how shortcuts when you are small can snowball into a culture where you have a gaping wound that may be difficult to fix.
My honest answer to that is; get it in writing, because WHEN the shit hits the fan, you've got evidence in your favour.
Managers always want compromises for cost or speed, is up to us to make them understand which compromises they really don't want to make. If they want to make it anyway, get proof that it was done on their orders.
Oh you're absolutely right, but there are some fairly straightforward steps to take to mitigate the risk with little effort.
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.
For reference, here is my getConfig which uses the environment for configuration options. It's really easy enough to start with something like this, and add it in at the baseline.
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.
I'm a new developer (an intern, actually). I just started writing a system that requires a couple secret strings. Currently I just have them as constants with my code, with the idea that I'll figure out something to do with them once I make sure everything is working.
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 read them from a config file and fill them into the config by hand while deploying. Never push secrets embedded into code or portions of the config file to your source repo.
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.
The long standard for lots of software is to have a blank "file.conf.example" file (with only the variable names but blank values) which you commit to git, and have the code look for a file named "file.conf" which you explicitly exclude from git using gitignore. This allows you to have a template config file while still preventing the secrets from being written to git. Then you can have the software provide some sort of alert when it is launched for the first time saying "config file not found, please duplicate file.conf.example, fill in your details, and name it file.conf."
How to handle organizational secrets is definitely your concern, however, you are probably too junior to be making decisions on implementing security best practices in production. Likely your company has methodologies in place to deal with deployment secrets. Ask a senior dev how they handle secret management. In many companies there are key management tools such as Hashicorp Vault or Ansible vault. Basically without knowing your environment its hard to tell you what to do, but there are lots of options out there, and your company may have already implemented some of them.
At the VERY least, extract them to Environment Variables... ensure .env is on your .gitignore, and have your localized/dev configs in your local .env ... production environments should have them set. For more complex environments you can set via a secure key service, or build from there.
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
Heard about this a couple days ago, crazy stuff. For those who don't know, bilibili is a massive video hosting platform in China aimed toward the younger generation.
So the question is who leaked it and why? Just a disgruntled employee or the effect of 996?
I'll never understand what market cap has to do with company size. Stock prices are basically an arbitrary value mostly determined by how much people buying stock think the stock is worth, are they not?
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.
Market capitalization = share price * number of shares
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.
> If the stock price falls, these investors lose money, not the company.
The stock price is entirely speculative and detached from the company's actual performance. At best it's informed by a perception of the company's performance and an expectation of how the stock price might change in the future in reaction to the company's future performance.
While shares will be worthless if the company goes bankrupt, the company won't be directly affected if the stock market plummets -- except in situations where (additional) stock can be used as a currency in lieu of actual cash, like buying out competitors.
So to answer my own question: market cap (but mostly share price really) is only a measure of company size in so far as it indicates how much money the company could generate by selling additional shares. It doesn't provide any indication of how well the company is doing financially, how many employees it has, how much market share it serves or any other measure of size BUT generally people are willing to pay more for shares of companies that are likely to grow or at least outperform their competitors in the short term.
EDIT: In other words, yes, an overhyped two man operation running at a financial loss could end up with a massive market cap but in practice it's unlikely to happen because hype rarely works that well.
"Enterprise Value" is one of the legitimate measures of company size, and is defined as market capitalization + net debt.
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.
Don't forget to subtract cash in the EV formula. Otherwise you could take out a gigantic loan and magically get bigger, when really all you've done is shuffle some money from debt into cash.
Well if your company only has one product with all the secrets leaked on github, it matters whether the company was worth 10 Million or 6 Billion before bad things happen.
Among other things, market cap gives an indication of the future value investors place in the company. Your 2-man shop would unlikely have a similar market cap unless they can demonstrate some blindingly simple strategy to take over the world. Your big corp already has access to a large userbase (100m users in Bilibili's case if the previous poster is to be believed). That makes future growth and profits much more likely.
Bilibili was also criticised by the Chinese government last week for the 'quality' of some hosted content (read: pornography, satire). The next day its foothold in younger generations was praised by the same relevant organs (read: being told to focus or educational and 'moral' content).
"我不清楚这些是啥… 道德心泛滥的麻烦出门右转关注996.icu！" means "I don't know what these are... I hope those with an overflowingly moral heart won't be too bothered to go out and turn right to star 996.icu"
The original repo was taken down, so I don't think you can attribute that message to the leaker.
I suspect the commenter you’re responding to means ~”who leaked the source code referenced in the DMCA, and why”. The DMCA takedown request refers to a repo that it claims contains internal information and data from the claiming company.
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.
As far as I know, an employee who was illegally laid off by bilibili put part of the company's background code on GitHub to vent his anger.
And then GitHub has directionally shielded the keywords "bilibili" and "go-common",
But it can be bypassed by typing only one character less. there are still a lot of projects alive.
It is not yet known who leaked it.
Also for the reason.
You can find some reports here by using Translation software(If this report hasn't been deleted yet)。
BiliBili once made a statement on Weibo， but delete in a few minutes.
https://www.heibai.org/post/1214.html
You could link to the hearsay, assuming it was online.
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.
Sure, Bilibili's copyright must be respected, no question on that whatsoever. That being said, let's have a look on how this multi-billion company treats its programmers -
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.
I think you are taking a moral high ground by attacking the company's practices.
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.
> $700 is about 10% of the fair market rate in China for skills like that.
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.
As clearly mentioned in the reply, $7,000/month is the fair market rate for someone who can propose/promote/complete such a project with visible impact on the community.
Code base is fair game DMCA-wise. I wonder about the private keys though. I don't think they are copyrightable (although it would cool to have a poem as the private key). So, does DMCA cover that too?
> (although it would cool to have a poem as the private key)
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.
They are copyrightable as works, and even if they arent then they are as devices protecting works.
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.
Since recipes are not protected under copyright law [1] it's unlikely mathematical parameter lists have sufficient "literary expression" for protection.
OTOH, a passphrase of substantial creativity [2] may be protected by copyright. Crucially (for any takedown), this would cover transformations by key derivation functions.
A purely random number is almost certainly always beyond copyright, but as soon as someone puts limitations on that randomness a court may find that enough.
And what matters for a takedown is not the number, but the actually document being published. Github is not hosting the random number. It is hosting that number in the context of a larger document and it is that document that is subject to the takedown request. Things might be different if github hosted only the number without the associated labels and code.
A key is just a long number. The AACS encryption key controversy was the subject of DCMA take downs because the key could be used to strip DRM, not because it was a number.
nah, they are just the default heroes that exist in Warcraft 3 Reign of Chaos and Frozen Throne, which is easily discerned by the names and the fact the races are listed as titles and the Neutral heroes doesn't have a race mentioned in English
Also there are a lot more heroes in the Dota map for Warcraft 3 than on that short list
An example configuration file is also acceptable. It is also less prone to leakage if your application runs other untrusted (or simply less trusted) code and does not sanitize the environment first.
Apart from the storing secret in repository, I'm quite impressed by their repository structure. It looks a lot better than the mess I often see in our internal projects.
You would think it would be faster to just change the keys. Although looking at the repo the credentials they are worried about getting leaked are "admin" "admin"
Why do you think that the DMCA would lead to some sort of deletion of repositories that was sent over a wire to a website that the DMCA was meant to be into?
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.
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
I'm not sure the answer is, or should be, as simple as "derp - delete immediately, this was never meant to be Open Source".
That said, if the code was stolen, and then published under an OS licence - it's not OS. The "publisher" never had the rights to make it OS, so the "contract" is null and void...
How you'd solve this, logistically in an example like yours (Linux kernel) I have no idea, but I presume by the time it's been made public long enough to be cloned/forked (a la the company in question in OP) all of your efforts should be focused on damage control.
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.
1. api key is publicly readable in a configuration files you ship
2. api key is compiled into the binary you ship.
There is only obfuscation. Then again api keys are not security keys.
Even including an API key into the binary build is avoidable. Add an OAuth-style negotiation for the key as the first startup process.
Start digging deeper and there are fewer and fewer reasons.
How does this possibly work? You must have some “bootstrap key” that you would use to fetch the API key. You’re going to ship something in the app that says “hey, I’m really your app” or else you’re doing to allow anyone to fetch your API key. All you can do is obfuscate the process of getting the API key. You cannot actually keep it secret when you need clients to have access to it.
Even if your app doesn’t require any login there’s no reason you shouldn’t go through the same process. Every device gets its own key and then you apply limits to it...
However the term API key may also refer to an App key, intended to identify all users of a given app. The intention there is to be able to engage and widespread revocation or throttling in case an app is misbehaving or compromised. You cannot keep this sort of API key secret because it must be shared and must be available.
In the non-user device scenario you mentioned, I’m pretty sure you would actually be better off simply having the device generate a random GUID instead of going through a pointless negotiation to hand out a random GUID.
4. You use a secret service that has pk or secure access from the service machine to retrieve secure configs/settings from.
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.
Huh? Amazingly you make it sound so easy when it's anything but. Where is this file? How is it deployed? How is it rotated? If I have 10,000 VMs, how do I deliver that file to those machines? If my VMs aren't persistent, how do I ensure new VMs are deployed with this file?
Or were you thinking that they would just ssh into production and scp the file into there? To me you glossed over so many details that you hardly solved the problem at all. Replacing the secrets in source code is the _easy_ part. Deploying secrets is the hard part.
There are tools out there to make this easy, but (1) they almost always make things harder for developers and (2) they almost always require a large infrastructure change. Sure, if your deployment is small enough where you could just SSH into a single prod server and scp a file - then you are likely miles ahead - in terms of both security and culture, but changing the culture is harder than it looks.
I don't want to sound like I am making excuses for them - but I only want to show how shortcuts when you are small can snowball into a culture where you have a gaping wound that may be difficult to fix.
Managers always want compromises for cost or speed, is up to us to make them understand which compromises they really don't want to make. If they want to make it anyway, get proof that it was done on their orders.
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.
https://gist.github.com/tracker1/fcc39f40a0d14648501d329c7bd...
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.
After some googling it seems that my intuition about the relevance of stock prices is mostly right:
https://eu.usatoday.com/story/money/columnist/krantz/2012/10...
> If the stock price falls, these investors lose money, not the company.
The stock price is entirely speculative and detached from the company's actual performance. At best it's informed by a perception of the company's performance and an expectation of how the stock price might change in the future in reaction to the company's future performance.
While shares will be worthless if the company goes bankrupt, the company won't be directly affected if the stock market plummets -- except in situations where (additional) stock can be used as a currency in lieu of actual cash, like buying out competitors.
So to answer my own question: market cap (but mostly share price really) is only a measure of company size in so far as it indicates how much money the company could generate by selling additional shares. It doesn't provide any indication of how well the company is doing financially, how many employees it has, how much market share it serves or any other measure of size BUT generally people are willing to pay more for shares of companies that are likely to grow or at least outperform their competitors in the short term.
EDIT: In other words, yes, an overhyped two man operation running at a financial loss could end up with a massive market cap but in practice it's unlikely to happen because hype rarely works that well.
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://www.bbc.co.uk/news/business-47934513
[1] https://github.com/github/dmca/
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.
[1] https://github.com/Bilibili/flv.js
[2] https://www.zhihu.com/question/53686737
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...
And what matters for a takedown is not the number, but the actually document being published. Github is not hosting the random number. It is hosting that number in the context of a larger document and it is that document that is subject to the takedown request. Things might be different if github hosted only the number without the associated labels and code.
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 \
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?
0: https://12factor.net/config
Ownership of the code could belong to the leaker.
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.