What do you think about this solution: introduce a layer on top of SSL that just verifies whether the private key of a certain explicitly stated site has signed a file?
In other words, compromising the server wouldn't be enough, because that doesn't give you the SSL key, so it would still fail "curl|is_signed_by site.com|sh", which they can only pass if they compromise the private key?
> compromising the server wouldn't be enough, because that doesn't give you the SSL key
But it does. The server needs to have the SSL key to be able to serve requests over HTTPS.
It may be encrypted with a password, but at that point you're severely degrading your integrity assurances (compared to offline executable/archive signing). Might as well do it right with offline signing, right off the bat.
interesting. What if a script just uses the SSL infrastructure to get the private key associated with a domain name, without actually needing anything at that domain name to come over SSL? Then the private key does not have to be live/online at all, but could be used to verify the shell script. This is getting complicated, but if there is infrastructure, it should be possible to use it.
Personally I think curl of an https URL is not the worst thing in the world.
I think you need to read up a bit more on how asymmetric key cryptography works :) Verification is done using the public key, the private key is used to sign something. That's why it's so useful. This is a good read if you want to learn more: https://www.crypto101.io/
Basically, the separation between 'server serving the downloads' and 'machine signing the release' is intentional, and should be maintained. Consider it an 'airgap' of sorts, although it usually isn't one in the strictest sense of the word.
Making release signing depend on the SSL infrastructure (which is already rather broken in a number of ways) in any way, is a bad idea. Verification is a different story, but secure code delivery is a hard problem anyhow.
I understand exactly how it works. How do you get a code-signing paradigm down to something as simple as curl | sh though? (Well not as simple, but still a human-readable one-liner that works on nearly all Linux systems.)
I thought maybe a single-line invocation might piggy-back on SSL as follows:
- get a server's public key that is not online or able to answer requests (because if it were it couldn't be airgapped)
- but still use the key to verify the script that's downloaded from the server that is online.
- only pass the code to sh if it was properly signed by the offline server.
Then the offline server could be "https://key.meteor.com" and the private key wouldn't have to be anywhere but an airgapped machine.
I don't know if there is more of the SSL infrastructure that I'm missing though (I'm not an expert) or if this could practically be reduced down to a tamper-evident one-liner (a la curl https://install.meteor.com | sh). It would be a marked improvement over just passing anything from a potentially compromised server straight to bash though!
> How do you get a code-signing paradigm down to something as simple as curl | sh though? (Well not as simple, but still a human-readable one-liner that works on nearly all Linux systems.)
You don't, really. Not currently anyway. Retrieving a binary/archive and doing out-of-band verification are two logically separate steps.
The problem with your suggestion is that SSL is about transport security. It verifies that you are talking to the right server, but does not provide any guarantees beyond that.
It's not really possible to shoehorn release signing into that, without additional infrastructure.
It doesn't matter how you combine things - the server and the signing system are (and should be!) two separate entities, and you cannot rely on the server to tell you who the signing system is (because that'd give you no better security than not having a signing system at all).
> It would be a marked improvement over just passing anything from a potentially compromised server straight to bash though!
It wouldn't, because as far as I can tell, you're still relying on the server to tell you what the correct release signing key is. How else would you obtain it?
I am downvoting them because shell piping is not relevant to Meteor 1.2 announcement, this topic was discussed on multiple occasions and they offer no alternative.
They're announcing "hey we have these new features" and I'm saying "hey look, they still haven't fixed this big glaring problem that is very much relevant to how their software is used".
Downvoting because it's a non-issue. If I'm copying and pasting something from the web into my terminal, it's because I trust the source.
It's not any less secure than downloading a tarball and running scripts inside of it. That's equally insecure and people have been doing that since the dawn of the internet.
