[logicallee]

What do you want them to do? The obvious solution is to change it from "curl|sh" to "curl|{something about whetehr PGP says this is properly signed by the private key belonging to public key blahblahblahblahbalhMETEOR.COMkey. If yes:}|sh"

But the problem is anyone compromising the site can just change the line from "blahblahblahblahbalhMETEOR.COMkey" to "attackerchangedblahblahblahblahbalhMETEOR.COMkey" right on the web page, and people will copy the one verified against the wrong key. So that doesn't work.

Nor do clients have caches of PGP signatures, nor is there some totally obvious third-party that you can verify it with. You can't just go:

curl|{check_if_signed_with_www.this-site.com}|sh (which would pass visual inspection - the attacker would have to change www.this-site.com to something else) because there is no obvious mechanism to do that. Who will tell you whether https://install.meteor.com/ has signed it?

Well, HTTPS will kind of tell you. So "https://install.meteor.com/" is a lot better than nothing...

If you're going to entertain the idea of the HTTPS site being compromised to serve whatever they want, well, there is precious little you can do about it.

[sarciszewski2]

> What do you want them to do?

I want them to not use a one-liner. Step-by-step:

1. Download the files

2. Download the public key

2a. verify the public key if you've never seen it before (publish in the blockchain, have lots of high profile technologists sign it, etc)

3. If the verification matches, then proceed.

Teaching developers to value "clever one-liner hack" over "secure, dependable solution" will lead to bad habits.

[logicallee]

if you're going to include "2a" you can refactor all of your steps into:

1. Google "meteor.com compromised" and decide whether it's currently compromised. If it isn't:

2. Run curl https://install.meteor.com|sh

It saves a few steps and is equally secure - you know, since you're just going to go based on what other people think and include no programmatic check whatsoever. (your 2a).

[sarciszewski2]

2a can be swapped out for a better PKI system at any time. Relying on whether it's public knowledge that Meteor is compromised or not is not nearly as resilient.

[logicallee]

so swap it out for a better PKI system. There is literally nothing in any of your steps that can't be automated, except for the totally nebulous 2a "publish in the blockchain, have lots of high profile technologists sign it" which 9/10 people are not qualified to judge.

There is no reason you couldn't automate your whole suggestion, except for that one, which makes it infeasible and open to all manner of social engineering.