GitHub publishes DMCA deletion notifications sent by Bilibili (opens in new tab)

The only sad thing here is a fraudulent DMCA takedown for a trademark violation.

What harm? It's nice to have the source.

> dumb enough to put secrets in the code.

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?

Much of it is api keys they would distribute in the deployed app anyway. Not really ‘secret’.

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.

> dumb enough to put secrets in the code.

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...

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

We built https://www.envkey.com to solve this problem in a secure and developer-friendly way—perhaps it can help!

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.

"我不清楚这些是啥… 道德心泛滥的麻烦出门右转关注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.

The practice of requiring employees to work from 9 to 9 6 days a week.

I first heard of it last week from this article:

https://www.bbc.co.uk/news/business-47934513

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.

According to this repo Symantec just filed a DMCA notice to Android source code about a week ago:

https://github.com/github/dmca/blob/master/2019/04/2019-04-0...

Crazy.

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

> illegally laid off for this part, I can't give credible sources, I know it from hearsay

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.

oh, you can ask the same question to those millions of Chinese developers forced to work 996. surely that is the solution to the problem.

That's the saddest poem I've ever read.

These keys don't have anything to do with copyright protection circumvention though.

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.

I think more specifically this is referring to heroes from Dota (which of course links back to Warcraft III as you said)

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.

Everyone creates their account at some point, probably in order to respond to something...