GPG key error in scripted installation of RVM

[chrispomeroy]

I'm having a problem adding the new GPG key. Trying to fix to a scripted installation of RVM which stopped working after this key requirement.

The script fails when I use curl -sSL https://get.rvm.io | sudo bash -s stable

even though I placed gpg --keyserver hkp://keys.gnupg.net --recv-keys D39DC0E3 right before it.

I also tried using --batch --exit-on-status-write-error flags with gpg

Any ideas?

gpg exists with a status code of 1

The funny thing is, adding the gpg key works fine when I manually paste the line into the terminal, just not in a shell script.

[chrispomeroy]

I was able to fix this by adding --homedir /root/.gnupg to the gpg command.

[jhsu802701]

Shouldn't this fix be integrated into the code?

[chetanagrawal]

How to fix this issue permanently? Its bad idea to download new keys everytime there is change in signature. Can't we fix this without the need to download new key using gpg?

[mpapis]

@sfunk1x are you using as the root user? you know that it is the worst thing you could do to your server?

[mpapis]

ah I missed the part for sudo - will need to think about it for documentation

[tbagger]

I run 'sudo gpg --keyserver hkp://keys.gnupg.net --recv-keys D39DC0E3' the key downloads, but I'm still getting this error.

gpg: failed to create temporary file /home/admin/.gnupg/.#lk0x1318050.tjsites.5741': Permission denied gpg: keyblock resource/home/admin/.gnupg/pubring.gpg': general error
gpg: Signature made Thu 30 Oct 2014 03:27:39 PM EDT using RSA key ID BF04FF17
gpg: Can't check signature: public key not found

[AlmogBaku]

This is new problem.
I just created a new vagrant instance, which worked a few days ago and this error thrown to me.

I running this command from the root user:

curl -sSL https://get.rvm.io | bash -s stable --quiet-curl --ruby=1.9.3

[mpapis]

@AlmogBaku what part of the problem is new? did you read the message and follow instructions?

[AlmogBaku]

@mpapis I read it, but this problem wasn't appeared a few days ago with the same provisioning scripts. so, I guess something changed in the RVM script..

(I have pre-configured vagrant node with puppets recipes that configuring my server)

[AlmogBaku]

==> default: gpg: directory `/root/.gnupg' created
==> default: gpg: new configuration file `/root/.gnupg/gpg.conf' created
==> default: gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
==> default: gpg: keyring `/root/.gnupg/pubring.gpg' created
==> default: gpg: Signature made Wed 29 Oct 2014 12:52:06 PM UTC using RSA key ID BF04FF17
==> default: gpg: Can't check signature: public key not found
==> default: Warning, RVM 1.26.0 introduces signed releases and automated check of signatures when GPG software found.
==> default: Assuming you trust Michal Papis import the mpapis public key (downloading the signatures).
==> default: 
==> default: GPG signature verification failed for '/usr/local/rvm/archives/rvm-1.26.0.tgz' - 'https://github.com/wayneeseguin/rvm/releases/download/1.26.0/1.26.0.tar.gz.asc'!
==> default: try downloading the signatures:
==> default: 
==> default:     gpg --keyserver hkp://keys.gnupg.net --recv-keys D39DC0E3
==> default: 
==> default: they can be compared with:
==> default: 
==> default:     https://rvm.io/mpapis.asc
==> default:     https://keybase.io/mpapis
==> default: Downloading https://bitbucket.org/mpapis/rvm/get/1.26.0.tar.gz
==> default: Downloading https://github.com/wayneeseguin/rvm/releases/download/1.26.0/1.26.0.tar.gz.asc
==> default: gpg: Signature made Wed 29 Oct 2014 12:52:06 PM UTC using RSA key ID BF04FF17
==> default: gpg: Can't check signature: public key not found
==> default: Warning, RVM 1.26.0 introduces signed releases and automated check of signatures when GPG software found.
==> default: Assuming you trust Michal Papis import the mpapis public key (downloading the signatures).
==> default: GPG signature verification failed for '/usr/local/rvm/archives/rvm-1.26.0.tgz' - 'https://github.com/wayneeseguin/rvm/releases/download/1.26.0/1.26.0.tar.gz.asc'!
==> default: try downloading the signatures:
==> default:     gpg --keyserver hkp://keys.gnupg.net --recv-keys D39DC0E3
==> default: they can be compared with:
==> default:     https://rvm.io/mpapis.asc
==> default:     https://keybase.io/mpapis

[mpapis]

@AlmogBaku you need to execute the extra step of trusting my public key, this way - you know that the code was provided by me, and I can sleep safer that nobody impersonated me and provided you malicious code, there are multiple ways of importing the public key, please read on the verification of files signed with GPG

[AlmogBaku]

Hey @mpapis
Thanks, adding the gpg manually by gpg --keyserver hkp://keys.gnupg.net --recv-keys D39DC0E3 solved the problem.. but why it's suddenly not add it automatically?

[mpapis]

because there was no GPG signing before, we trusted the "system", but the truth is you cant trust in system, only adding manually a layer of security like signing with GPG can prove the code you got was the one I intended to provide, that no malicious attempt was made on the way ... before you trusted me and the delivery method with no actual verification who provided the code, right now the verification is there, but it requires you to express the intent of trusting me by importing my public key, this key then is used for the verification and would warn you if the code was tempered with

[AlmogBaku]

I understand.. thanks for the explanation pal.

I guess this change is breaking a lot of automatic scripts(such as puppet, puphpet, bash etc).. so you have any idea how can we solve it?
is it safe to add the D39DC0E3 key to my bash script? or its something dynamic?

[mpapis]

@AlmogBaku there are different levels of security:

1. lack of security, developers use an open CVS server allowing commits from anyone, users download code using http - nobody uses this any more
2. assumed security, developers use git/svn with SSL encrypted & authenticated connections, users download code using https - this is the default model, unfortunately this is not bullet proof, more and more bugs in https are found, there are attacks on servers hosting the data - it's good but not enough to ensure our safety
3. blind security - read 4. + with assumption internet is used to acquire the public key, internet is not a safe place, if everybody would be using the same url to get the key an attacker would only need to hack the extra url to get back to security provided by 2.
4. trust based security, developers use private keys (GPG) to sign their code and artefacts (binaries/packages), users use developers public key to ensure the code they use was indeed created by the developer

any attempt to automate installation of public key would be equal to 3. blind security which is only minimally better then 2. assumed security, as the whole idea is to provide 4. trust based security users need to be aware of the risks and put effort into ensuring the proper public key is installed instead of blindly trusting single url to provide proper key.

[AlmogBaku]

I understand, thanks for the warning.
Sometimes it just necessary... for instance- if you want to use puppet you
must install ruby first- you can do it without RVM, but where is the fun? :)

I think there are some solutions for the problem you raised, for example
you can see what HHVM did with their GPG.
And again- thank you for your kind answer :)

On Sat, Nov 1, 2014 at 3:32 PM, Michal Papis notifications@github.com
wrote:

@AlmogBaku https://github.com/AlmogBaku there are different levels of
security:

1. lack of security, developers use an open CVS server allowing
   commits from anyone, users download code using http - nobody uses this
   any more
2. assumed security, developers use git/svn with SSL encrypted &
   authenticated connections, users download code using https - this is
   the default model, unfortunately this is not bullet proof, more and more
   bugs in https are found, there are attacks on servers hosting the data
3. it's good but not enough to ensure our safety
4. blind security - read 4. + with assumption internet is used to
   acquire the public key, internet is not a safe place, if everybody would be
   using the same url to get the key an attacker would only need to hack
   the extra url to get back to security provided by 2.
5. trust based security, developers use private keys (GPG) to sign
   their code and artefacts (binaries/packages), users use developers public
   key to ensure the code they use was indeed created by the developer

any attempt to automate installation of public key would be equal to 3.
blind security which is only minimally better then 2. assumed security,
as the whole idea is to provide 4. trust based security users need to be
aware of the risks and put effort into ensuring the proper public key is
installed instead of blindly trusting single url to provide proper key.

—
Reply to this email directly or view it on GitHub
#3110 (comment).

[mpapis]

yes indeed I will be increasing security of the key, it still is best for users to manually pick what to do, adding a single command to be ran before RVM installation is usually really easy just copy paste the proposed import command if the 3. blind security is good enough for you

[howardroark]

@mpapis That was a great breakdown of security levels!

Though I think the recent changes do not properly consider how RVM is being used. I get the need to involve a human, but I don't think it is likely in most cases. It seems likely that the majority of cases where the bootstrap script will be used involve 3. blind security. The reality is that less humans are installing rvm via the shell anymore... they are running things like Salt, Chef or Puppet. This change probably sent a good deal of ops scrambling to figure out what was wrong with their automation code. All of whom likely went ahead and automated the signing process despite the caution. This change probably also broke Vagrant setups for many developers who may not be familiar with things like PGP.

I get the desire for this, but the project should keep in mind how this tool is likely being used today. I feel that the issue of trusting a source is unavoidable and must be considered in a rational way. For instance, it could be safer to hand out the github raw url over get.rvm.io. The current key server is likely to experience a spike in traffic if every automation script now has to hit it as well. In the end all this change likely creates is two endpoints becoming potential "risks" .

It would have been nicer if the changes were something that people could have opted into rather than being surprised by. It would be handy if the script offered the ability to run in an "insecure" mode. This way if you are just going to automate the request to get the key, you may as well skip it.

One small issue I did notice is that key signing only seems to work if you do it before running the bootstrap (on ubuntu at least). After the bootstrap runs they key cmd snippet can't just be pasted in and seems to fail unless run prior to the bootstrap. This is probably very confusing to some people.

I say all of this with the best intentions and don't mean to come across as ungrateful in any way. You likely put in a lot of hard work here. This project is awesome and makes my life easier. Thanks!

[todd-a-jacobs]

@howardroark @mpapis There's a middle ground with PGP's web of trust: as long as the user isn't automatically signing the key, the retrieved key's fingerprint can be compared with a value at a well-known URI. For example, RVM could:

• Retrieve the public key. Installing a key requires no trust in the validity of the key.
• Verify the fingerprint against an out-of-band value (e.g. https://rvm.io/gpg-fingerprint.asc) rather than something coded into the script itself.
  • See https://github.com/CodeGnome/packer_installer.sh/blob/master/packer_installer.sh for an example using SHA-256 rather than GPG, but the idea is similar.
  • This is resistant to tampering with the script, but is still vulnerable if both the installer and the out-of-band verification token are compromised at the same time.
• This still forces the user to trust the installer script, since nothing guarantees that the script is properly comparing fingerprints...but it's at least another layer.

In the end, there's really no substitute for exported trust signatures from multiple trusted sources (e.g. key-signing by other well-known developers), but many users simply use GPG signatures the same way they use MD5 or SHA-1 (e.g. without actually trusting the keys), so one might as well support that use case provided that there's a big neon warning for the people who don't really grok security, the OpenPGP paradigm, or the web of trust.

Just my $0.02.

[arlago]

The solution!

https://www.digitalocean.com/community/questions/curl-l-get-rvm-io-bash-s-stable-fails-on-cent-os-on-hostgator

[mpapis]

the solution is to read the message

[arlago]

Actually, I needed to install gpg2.

[dholdren]

is there a plan to document the new signed releases strategy on http://rvm.io ? I don’t see any mention on the home page, or on the install guide: http://rvm.io/rvm/install

[mpapis]

@dholdren - yes I will document it soon, I have put most of the feedback I got into the message, so for those lazy ones and not carrying much about security it will be enough to copy paste the key command

@sfunk1x I could not find anything in the link that would tell something else then the message already says, please quote it in case I'm to blind to find it

@arlago this is odd, rvm checks for gpg2 and gpg and only tries to validate signatures when one of them is installed, the displayed message contains the name of the command found, so it should be enough to read the message and copy paste the command

[Startouf]

I am getting this error on a new install of RVM on Amazon Linux 2, which I did not run into a few months ago with RVM 1.29.4

$ curl -sSL https://get.rvm.io | sudo bash -s stable
...
GPG signature verification failed for '/usr/local/rvm/archives/rvm-1.29.5.tgz'

I have tried to

sudo gpg2 --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
command curl -sSL https://rvm.io/mpapis.asc | sudo gpg2 --import -

And from the RVM website

gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB

But to no avail, is there a bug with rvm 1.29.5 ?

My libs
gpgv (GnuPG) 2.0.22
libgcrypt 1.5.3

I'm still trying to figure out what is the gpg package name on yum to see if an update works

[pkuczynski]

@Startouf we released this version signed by another dev (me) with the second key on the list. You would need to import it via:

sudo gpg2 --recv-keys 7D2BAF1CF37B13E2069D6956105BD0E739499BDB

[kissu]

None of the snippets above works. :(

[dangol]

we are having intermittent success with:
gpg --keyserver hkp://keys.gnupg.net:80 --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
(note the :80 on the address)
however it is Intermittent, and I also get key not found.
Perhaps the new key could be added to a file on https://rvm.io/ like the older:
https://rvm.io/mpapis.asc?

[pkuczynski]

@kissu its all about importing the keys. Try

gpg --keyserver hkp://keys.gnupg.net:80 --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB

[pkuczynski]

@dangol I am working on bringing rvm site to live. Haven't noticed the build is failing. Will ping u as soon as it's done

[pkuczynski]

See also #4457

[pkuczynski]

@dangol done. Try now!

[ndiesslin]

I just started running into this error also and this fixed resolved it for me
gpg2 --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB

[dangol]

@pkuczynski Seems to be working, at the moment thanks

[x-yuri]

This might help.

[kissu]

@pkuczynski Working again, thanks ! 🙏

[MorganaUzhgorod]

I just started running into this error also and this fixed resolved it for me
gpg2 --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB

Works for me! Thanks!

[bumpux]

Still stuck. Mac OS Mojave. Tried various permutations here and elsewhere. Any summary of best solution?

[geerlingguy]

In my case, on Ubuntu 16.04, I ran:

gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB

(gpg instead of gpg2). I'm using the rvm.rvm Ansible role for automation, and it seems to be running into this error duing initial server provision: rvm/rvm1-ansible#186

[peterloeffler]

seems to work when using master:
bash /var/chef/cache/rvm-installer-googlepremiumadapter master
but not with stable or --version ...

[rhizome]

Specifying --keyserver... worked for me.

[dominicsayers]

@mpapis The message when it fails to install/update only mentions the original key. I believe it should also mention the new key you described in #3110 (comment)

Here is the message I'm seeing when I do rvm get stable today:

Warning, RVM 1.26.0 introduces signed releases and automated check of signatures when GPG software found. Assuming you trust Michal Papis import the mpapis public key (downloading the signatures).

GPG signature verification failed for '/home/build/.rvm/archives/rvm-installer' - 'https://raw.githubusercontent.com/rvm/rvm/master/binscripts/rvm-installer.asc'! Try to install GPG v2 and then fetch the public key:

    gpg2 --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3

or if it fails:

    command curl -sSL https://rvm.io/mpapis.asc | gpg2 --import -

the key can be compared with:

    https://rvm.io/mpapis.asc
    https://keybase.io/mpapis

NOTE: GPG version 2.1.17 have a bug which cause failures during fetching keys from remote server. Please downgrade or upgrade to newer version (if available) or use the second method described above.

I think the third line should be

gpg2 --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB

as you implied in #3110 (comment)

[jasonl99]

I tried the suggestion from @dominicsayers to change the command for gpg2 --recv-keys, and it worked for me.

[pkuczynski]

@dominicsayers I updated the message in the latest version, which we will release soon. Thanks for pointing out.

[sblackstone]

I was encountering a problem with Mojave similar to this issue - I think the problem is that if you're upgrading from an old version of RVM the gpg install directions don't include the key thats now required for rvm proper.

Going to the website and using those keys first fixes everything.

gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB