3 ms·

It being a common thing is the problem. It's teaching insecure habits.

by joepie91_ 11y ago

sarciszewski 11y ago
People are downvoting this and being too much of a coward to state why they are.
- vdaniuk 11y ago
  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.
  - sarciszewski2 11y ago
    Sure it's relevant. 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".
- maratd 11y ago
  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.
logicallee 11y ago
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? Better than the current system?
- joepie91_ 11y ago
  > 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.
  - logicallee 11y ago
    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.
    - joepie91_ 11y ago
      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/ 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.
      - logicallee 11y ago
        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" 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 https://install.meteor.com | sh). It would be a marked improvement over just passing anything from a potentially compromised server straight to bash though!
rimantas 11y ago
Ok, I wonder how many do bother to check checksums after downloading binaries?
- joepie91_ 11y ago
  Many do, likely without even realizing it. It's common functionality in Linux package managers.

It being a common thing is the problem. It's teaching insecure habits.

sarciszewski 11y ago

People are downvoting this and being too much of a coward to state why they are.

vdaniuk 11y ago
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.
- sarciszewski2 11y ago
  Sure it's relevant. 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".
maratd 11y ago
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.

logicallee 11y ago

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? Better than the current system?

joepie91_ 11y ago
> 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.
- logicallee 11y ago
  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.
  - joepie91_ 11y ago
    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/ 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.
    - logicallee 11y ago
      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" 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 https://install.meteor.com | sh). It would be a marked improvement over just passing anything from a potentially compromised server straight to bash though!

rimantas 11y ago

Ok, I wonder how many do bother to check checksums after downloading binaries?

joepie91_ 11y ago
Many do, likely without even realizing it. It's common functionality in Linux package managers.