RVM signature verification failures due to not using same gpg/gpg2 as RVM installer uses

[pjnagel]

The rvm.ruby role uses the gpg command when importing keys, i.e. 'gpg --batch --keyserver {{ item }} --recv-keys {{ rvm1_gpg_keys }}'.

The RVM installer itself will, however, use gpg2 in preference to gpg if gpg2 is available.

In many (most?) cases that is not a problem, since both programs use the same ~/.gnupg/pubring.gpg keyring.

However, in some installations, gpg2 actually uses ~/.gnupg/pubring.kbx instead, and in those cases the RVM installation fails when trying to check the signature on the RVM installer because the public key was not imported to the same keyring as gpg2 will use.

The solution would be import the keys using the exact same gpg/gpg2 program as RVM itself will use.

[tisba]

I think I ran into the same issue. Do you have a workaround, @pjnagel? I'm not sure I fully understand what is going on and I'm a bit lost on what I could do to solve this.

[tisba]

For me, this issue is not clearly reproducible. Sometimes it fails, sometimes it works. Very frustrating :(

[pjnagel]

@tisba

As workaround, I run the following before importing the rvm.ruby galaxy role:

  # The keyservers that rvm.ruby uses are very brittle. Plus their fetching of gpg keys is not idempotent,
  # exposing ansible to network failures even when the key is already imported. Also, there is
  # https://github.com/rvm/rvm1-ansible/issues/196
  - name: Import GPG keys from rvm.io
    shell: |-
      if ! gpg2 --list-keys {{item.id }}; then
        curl -sSL https://rvm.io/{{ item.file }} | gpg2 --batch --import -
      fi
    become_user: '{{ rvm1_user }}'
    with_items:
      - id: 409B6B1796C275462A1703113804BB82D39DC0E3
        file: mpapis.asc
      - id: 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
        file: pkuczynski.asc
    register: gpg_result
    changed_when: '(gpg_result.rc == 0) and ("imported: 1" in gpg_result.stderr)'

  - name: 'Trick rvm.ruby role into not importing keys from keyservers again'
    command: 'true'
    changed_when: false
    register: gpg_import

As far as reproducing the issue goes, the only clue I have is my earlier comment on ~/.gnupg/pubring.kbx. Something one does with gpg2 makes it decide to create a new pubring in a new format. Whatever that thing is, it must be something that is not supported by the pubring format that gpg1 used. Beyond that, I have no clue.

[tisba]

Great, thanks! I'll give this a try in the next couple of days!

[tisba]

I think this is still an open issue and not addressed in 2.2.0, right?