I must be wrong, but apparently there is no well tooled standard way to manage trust for digital artifacts. Consider an example: the instructions for installing Ruby’s rvm tool look like this:
curl -sSL https://get.rvm.io | bash
That’s wonderfully simple, although it implies a lot of trust in get.rvm.io!
I run into this problem a lot. For example I have scripts that help me configure virtual machines. Here’s one that installs a hyperdex that I run as I’m setting up a new machine.
cat <<'EOF' > /etc/yum.repos.d//hyperdex.repo [hyperdex] name=hyperdex baseurl=http://centos.hyperdex.org/base/$basearch/$releasever enabled=1 gpgcheck=0 EOF yum clean all ls -l /etc/yum.repos.d/ yum --assumeyes install hyperdex ls -l /etc/yum.repos.d/
I then do something like this on a fresh machine:
curl http://example.com/install-hyperdex.sh | bash -
I can share these scripts, but I’d be loath to entice people into the bad habit of running such things.
And this bad habit is becoming very common. For example Continuum Analytic’s amazingly cool python data tool suite and it’s extremely useful tools for managing python versions and packages is conveniently installed by downloading a 16 megabyte shell script which you then cheerfully hand off to bash.
Of course there are systems that help with this mess. Yum will check gpg signatures, and it’s lame that says “gpgheck=0”. But why am I unaware of any tools that make it straight forward to check signatures on scripts like my install-hyperdex.sh script, or Ruby’s script for installing rvm. What I want is a tools that lets me tell users something like this:
To install Awesome-Software do this:
run-remote-script http://example.org/install-awesome-softwareIf you don’t have run-remote-script see how to install it by visiting …
Obviously we could ask users to step thru longer instructions.
To install our awesome software first be sure you have installed gnupg. Then download our signing key into your keyring.
curl https://example.org/our-signing-key.asc | gpg --importNow you can download our install script and check that we signed off on it.
# Get the script. curl -o /tmp/foo http://example.com/install-thing.sh.asc # Verify it's signature looks ok. gpg --verify $/tmp/fooIf that looks ok, then extract the script and run it.
sed -e '1,3d' -e '/-----BEGIN PGP SIGNATURE-----/,$d' /tmp/foo | bash -
That will work … if you don’t want users.
Why is this so damn hard? As I said at the start: we have “no well tooled standard way to manage trust for digital artifacts”. For heaven’s sake I had to use sed to extract the script!
One part of the answer would seem to be that systems like homebrew, ports, rpm, yum, etc. etc. are all trying to solve a larger problems. Which is fine, but they fail to address my problem, or the problem the rvm team has, or the problem that the python data guys have.
I have tooled up some of this, for my own needs when building virtual machines. But, it’s hardly a useful tool for others. And, it’s very much a work in progress.
Gosh, I feel like somebody must have already written a tool analogous to “run-remote-script.”
Maybe the problem here is your identification of “trust” with “verify a digital signature?” When I (or rather apt-get or pacman) verify the signatures on packages, it is not the signer as a person that I am trusting. I have never met the people behind Ubuntu or Arch and even if I had I would not be in a position to do a full background check on them, or to demand to do a personal security audit.
To be honest, it wouldn’t bother me even if it turned out that some of them are using false names. Instead, I am checking that the digital signature is consistent with previous releases, so that I have justification for having a level of trust in the new/upgraded package that is the same as my existing system – no higher or lower. I have a reasonable level of assurance that the new package was uploaded by the project team and was not introduced by someone who has compromised the website or FTP server.
For one-shot installations this justification doesn’t work. If run-remote-script validates a downloaded file against a key from the same website the attacker will just replace both. If run-remote-script gets the key from some sort of central key authority, my question would be “Authority according to whom? And for what?”. HTTPS CAs are not well thought of, and they are only trying to certify that a server found at a domain name belongs to the person who owns that domain name. If the central key authority provided you with a key for a download of ‘Acmeproject’s Stats-alizer’, what exact security claims are they making about that key? Have they audited the software or just checked that an email address provided in the sign-up process works? How will they decide who the “real” leader of an open source project is? How will the economics work?
Ultimately digital signatures are only a mathematical tool to help manage existing trust relationships that exist between people. A problem that is fundamentally about the existence of the latter – whether to trust a file downloaded from the website of people I don’t know much about – cannot be solved with the former.
JH – Trust in this context is the act of deciding to let the script run. The signature allows us to know that somebody with control over that key signed off on the script. We of course can’t know much more than that about the person(s) (or if you think it helps entity) in question, nor much more about what the phrase “sign off on” implies.
As you point out there are plenty of questions about the provenance of the key. And there are schemes to help with that. For example run-remote-script might check on the key. It could look to see if it has been revoked. It could look to see if there are any outstanding critiques related to the key. It could check the web of trust ties of the key. It can to this when the key is obtained and when it is used.
All of those things, and others, would improve things. But none of them address the problem I’m having. That there is no such tooling. That the absence means that if you want to make it easy for your users to install some software then you are strongly tempted to invite them to behave in a stupidly unsafe manner.
The easy install scheme used by the examples I gave don’t even, for heaven sakes, protect against corruption on the wire, let alone middleman attacks.
Back in the days of my misspent youth on Usenet, we never piped anything into sh. The practice was to use shar/unshar to make archives, and the unshar program had some level of paranoia built in to avoid obvious problems.