They could also do it regardless of whether or not Microsoft owns them or whatever favorite acronym authorizes them, or whatever. I've never understood why people love freaking out about this stuff. If the NSA felt like spying on you, pro tip, they're gonna be able to do it. If you care about keeping your shit secure, it shouldn't be on the internet at all.

>If you care about keeping your shit secure, it shouldn't be on the internet at all.

If only we lived in a world where this was practical.

I don't think it's unreasonable to be concerned about privacy this way, or to take issue with the possibility that this acquisition could make it easier for one to be spied on or surveilled. However, we should also cautious that our tin foil hats do not grow too heavy.

> If the NSA felt like spying on you, pro tip, they're gonna be able to do it.

True, but I suppose it matters how easy/difficult it is for them to do that.

The NSA is not god, they can't break 2048-bit TLS encryption no matter how many computers they have.

There's theory, design and implementation.

Maybe in theory it is safe, but implementations are often not safe.

An oversimplified way to see this is that your software runs on an OS which runs on a processor.

Your processor is backdoored (Intel ME and equivalent), your OS is backdoored, the entropy for your crypto is backdoored (Intel RDRAND instruction), your crypto algorithm implementation is backdoored.

So there are infinite resources for them to hack you at any moment for any reason. You have already gave them the keys to everything.

> The NSA is not god, they can't break 2048-bit TLS encryption no matter how many computers they have.

2048 bit TLS encryption? You mean 2048 bit RSA encryption? Also what source do you have that says the NSA can not crack a 2048 bit RSA key? Last I checked that info was non public and there is no definitive, credible source saying whether they can or can not crack 2048 RSA keys.

Yes I meant RSA key, sorry. My source is that 2^2048 is an enormous number and the time estimate for a desktop computer to crack it is in the quadrillions of years. Yes, I know the NSA has higher computing power than a desktop computer.

Don't need 2^2048 to crack RSA 2048. There's a saying "every time a grad student looks at rsa the recommended key length increases."

So just roll over and become complacent? The last time a gov pushed their bounds too much a new country had to be made to stop it.

Whenever I read these kinds of posts on this website I think of Sterling Hayden in Dr. Strangelove. (The crazy SAC commander who thinks the Russians are plotting to steal Americans' precious bodily fluids).

I understand that people don't trust the NSA/US government. And they shouldn't: the US government will always put its interests above yours and mine, and above those of allied countries.

At the same time, this stuff is bordering on parody. Very few of us (maybe none of us) need to worry about "the NSA MITM-ing our NPM packages". If you're that paranoid then you shouldn't be using github, NPM, or non-local dependencies. And of course you should be reviewing everything manually.

I didn't mean that this is going to happen. I wanted to give an example of a potential threat. My idea was to show one of many problems with centralization and relying so much in GitHub and GitHub SSL certs.

Maybe we can start signing our commits to increase security giving the potential threat. The same way that after the Snowden revelations we started using more and more HTTPS.

We can also think of better ways of sharing/releasing open source code. Debian has a pretty neat system with keys so it's pretty safe to install software from their repos [1]. Maybe there is a better system to be develop than just grabbing whatever from GitHub[2] and running it in your machine.

[1] https://en.wikipedia.org/wiki/Debian#Development_procedures

[2] https://github.com/mklement0/n-install/blob/master/bin/n-ins...

There's definitely a need for a better system. Some would argue that we have package managers specifically to help solve this problem. Yet, for many developers who just want a "good enough" install system without thinking or working at it much, curl-and-exec gets the job done.

That so many people aren't thinking about security at all is a sad comment on the state of software engineering. But perhaps inevitable, given our cultural history of favoring freedom over security.

> I wanted to give an example of a potential threat.

I really don't like this line of thinking. It's the same one used by news organizations to plump up their stories, or by politicians to make an improbable threat seem more real. In both of those cases, I think the long-term effect is to cause the public to think that very rare events are a lot more common. The result is not a culture of wariness but a culture of fear.

I'd much rather people present "worst-case potential threats" instead as "likely potential threats."

In security many things are "potential" threats. Just being unlikely doesn't mean that the threat doesn't exists. For example, a guy found a potential threat in rails[1], and rails developers dismissed his findings as unlikely exploitable. Then the guy go and hacked GitHub to prove that the issue was real[2][3] and that even the best rails developers were vulnerable.

[1] https://github.com/rails/rails/issues/5228

[2] https://github.com/rails/rails/commit/b83965785db1eec019edf1...

[3] https://arstechnica.com/information-technology/2012/03/hacke...

OK. Let's not talk about potential threats. That's the language of fear, control, and paralysis. It's the language of liars and demagogues and exaggerations.

Let's talk about risks and goals. The language of opportunities.

An approach of `curl | bash` takes a needless amount of risk to accomplish its goals. It can do far too many things, of which it actually needs to do a small subset. It offers a lot of opportunity for bad things to happen to seize the opportunity for the things we want. Maybe there are ways to do the same things, to get the same ends, without taking on so much risk.

How do you feel about this subject?

Good question. The specific problem that I'd like to tackle is sharing code as safe as possible.

The happy path is that you have some code to share and I want to get it exactly as you wrote it.

Right now the current issues with just using GitHub to share your code are the following:

1. GitHub app gets hacked and let's someone else do a commit (like the rails hack mentioned above).

2. GitHub employee modifies files in prod servers.

3. GitHub cloud provider gets hacked

4. State actor with lots of resources MITM GitHub.com domain and internet traffic and you fetch something else.

I think all this problems could be solved if:

1. Git enforces that all commits must be signed.

2. There is a decentralized list of usernames and keys.

This feature doesn't exists in git but it would be great if you could run `git clone` and it rejects the cloning if not all commits and tags has been signed.

But what If someone hacked GitHub to add a commit and she or he signed the commit. We need some kind of CA to only accept signed commits from the right people.

So there should be a fixed list of committers allowed in the repo and git would have to enforce that as well.

Then you have the problem that if all public keys are stored in GitHub then you almost get back to all the problems again of GitHub getting hacked. It would be great to have as many copies of usernames and public keys as possible. Something like a blockchain would be a good fit.

To recap, by having a decentralized system of users and public keys, and making git validate that the commits are signed and from the right people, we could have a much more reliable way of sharing code.

Additionally, we could have an "audit" system on top of all this were users can review code and mark it as "good". Then if you have a repo with a tagged version that has 5 reviews you can hope that it's pretty safe to run that version. Because it's a single system of usernames, you can check who are the reviewers.

It might be a bad idea to `curl | bash` a script from an stranger but at least you remove the risks of your code being delivered by a third party.

> To recap, by having a decentralized system of users and public keys, and making git validate that the commits are signed and from the right people, we could have a much more reliable way of sharing code.

I can see that you've put some thought into this. I can also see you don't generally spend most of your time thinking about security. This is not a bad thing! Most people don't!

But it does occasionally show up in sloppy thinking about system design, such as when you reflexively conflate a commit being signed by a key with a commit being from the person who is expected to own that key. It means you didn't stop and think about how to integrate rapid key revocation in case of compromise, or how to rotate keys over time.

Or how social review systems tend towards unreliability, as reviews are left by those who are not experts and users trust aggregate numbers from such. How meaningful is a 4.5-star average from five reviewers on a cryptography library, if the reviewers are five random people whose expertise you know nothing about and are ill-equipped to judge?

Have you looked at git-ssb?

https://git.scuttlebot.io/%25q5d5Du%2B9WkaSdjc8aJPZm%2BjMrqg...

I haven't. Thanks for sharing!

It also used to be considered paranoia to think that the NSA might do all the things in the Snowden leaks, but here we are.

I personally am not worried. If I was running some nuclear centrifuge in Iran/N.Korea/etc. then I'd be worried.

This is another phrasing of the worn-out "If you have nothing to hide, you have nothing to fear" argument, and it doesn't have any place here.

Sure if I am the moral equivalent of an authoritative gov't seeking nuclear arms.

That’s why I only drink rainwater and pure grain alcohol. Purity Of Essence.

Why would Github be any harder for the NSA to coerce than Microsoft?

Because Github, unlike Microsoft is not particularly dependant on US government contracts.

Well hello there, I'd like to share a story with you. I'm the maintainer of butterproject.org and have been maintaining popcorntime.io for a while, we had there 2 issues with GitHub a few years ago, both related to (unfounded) copyright claims on the butter and popcorntime code (we absolutely own the right to every single line there), when we tried to make our case we were ignored once and asked to 'keep things quiet' by side channels the second time. Most likely, the mpaa, didn't want us to exist and GitHub complied with shutting down our repos and sending a cese and desist to all our 800ish forks (at a time where we were trying to transform BitTorrent media streaming into a viable business plan).

Maybe it's time we build our core infrastructure on something else than companies that act irrationally when threatened to be sued ?

popcorntime was strictly confrontational, and was blatantly illegal. "Transforming BitTorrent media streaming" can be a good goal, but doing it illegally will cause you to be shut down. Remember grooveshark? They tried the same thing -- to create a legit service that disrupts and industry. But there's a reason they failed and spotify succeeded, and I think it's because they partnered with existing companies instead of tried to act in direct opposition.

But their source code wasn't illegal.

NSA doesn't have to ask, so this is a moot point.

Exactly. This is why there's no point in encryption, or any sort of obfuscation.

They now have access to private projects so can use that to help create exploits to closed source products that are hosted on GitHub or use it to create their own products or patents.

Who has this access. The NSA? They didn't have this access when GitHub was independent? Says who? Backed up by which facts?

Fact is Microsoft is a hostile company and will have access to private repositories.

Fact? How do you define whether Microsoft is hostile? What are your criteria?

Look, I hated Microsoft in the '90s and '00s. I was there. I grew up in a world where IBM dominated the market though. They've both changed. The market has changed and both of these companies had to deal with that.

The reality is that nowadays people pay with their privacy instead of with currency for a product; they are the product. Does it matter much who owns the product (independent US company, big player like Amazon, Microsoft, Facebook, Amazon, or Apple?)

My criteria is based on how they treated me on several occasions.

Very vague description of your anecdotal evidence. I mean, for starters, which time period are you referring to?

The most recent is a month or two ago when I upgraded my motherboard and cpu and my retail Windows 10 deactivated and I was unable to activate it myself, so I had to contact support. "Support" was rude and insisted on invading my privacy by remotely accessing my system to do "something". It took several days of exchange and they treated me like a potential scammer and I even had to send scan of receipt to prove that I indeed bought a motherboard. Utter scum.

Why MS cares your private repositories? give a reason? Maybe using your code to train their programming robot, lol

This is a much more concrete possibility than people might realize: https://www.microsoft.com/en-us/research/blog/deep-learning-...

public repositories contain enough data to learn, private repositories only a small part

I agree with the concern around too many things depending on Github for real time builds and deployment.

In regards to MITM, that can happen regardless of who maintains the repositories. If an NSL is issued, compliance is mandatory. A gag order is included. AFAIK there are no large organizations that would fall on that sword.

It is on the individual organizations that utilize public resources to do proper certificate and checksum validation, along with code diff reviews to reduce the risk of tainted packages.

There was a great post about this as a hypothetical attack vector and how CSP can help mitigate a large percentage of that surface, can’t find it now.

> If Microsoft shares SSL certs with NSA they could do MITM attacks.

There is zero reason to believe they do.

Your intention is correct, but your details are not (as are the OPs). Microsoft share's it's SSL certs with the entire planet. Microsoft protects it's private keys and does not share them with the NSA.

The NSA forges Microsoft's SSL keys, they do not need to ask for them.

https://en.wikipedia.org/wiki/Flame_(malware)

Even with the mitigations provided by moving away from MD5, simple integration with a CA would be much more strategically beneficial.

Thanks. I skimmed GGP's comment and assumed it said something slightly more correct than what it actually said and then copy-pasted his error.

> Even with the mitigations provided by moving away from MD5, simple integration with a CA would be much more strategically beneficial.

Returning to the point, this attack would be unaffected by Microsoft purchasing anything.

> Returning to the point, this attack would be unaffected by Microsoft purchasing anything.

I was agreeing with you :)

and the NSA wasn't spying on American citizens. Oh. Wait.

Yes! The Internet is a giganto conspiracy theory! No, you're wrong, it's the CIA! They asked DARPA to develop ARPA net, remember?

"The NSA is after me" should be your least point of concern in evaluating a product to buy.