Vault: GPG Init Docs Issue with base64 encoding

[jantman]

Hello,

I'm standing up a Vault and attempting to use GPG keys with it, but kept getting the error message: Error decoding given PGP key: illegal base64 data at input byte 1604. I'm using the API to do this from a Python wrapper script, but that should be irrelevant as the Python wrapper simply calls gpg --armor --export KEYID.

I've identified my problem, but the documentation really wasn't clear on these points:

1. The API accepts the actual base64 string, so the ASCII armoring needs to be stripped.
2. More important point: Go's encodings/base64 only accepts the "standard" RFC4648 base64 encoding, which uses "-" and "_" characters. However, GPG at least as of 2.0.22 through 2.1.11 exports ASCII-armored keys using the "alternate" character set ("+" and "/"). Therefore, to use GPG keys (at least via the API, and I'm assuming through the command line as ASCII), gpg's output needs to be unencoded and then re-encoded using the "standard" character set.

[jefferai]

The docs specifically say:

The keys must be base64-encoded from their original binary representation

which is not the same as armoring.

Note that the docs are careful to use "PGP" rather than "GPG". Non-standard GPG behavior must be worked around by the user. If you have suggestions on clarifying them, feel free to open a PR.

[jantman]

I'm aware that armoring and base64-encoding aren't the same thing.

I'll open a PR when I figure out how to actually get this working. So far, I've come up with a workable way to do GPG keys (FWIW, is it really expected that people who use Vault will use a proprietary application that's not even available in normal repos?) but only 4096-bit keys. If I try to pass it a 2048-bit key, it barfs on the packet header.

[jefferai]

(FWIW, is it really expected that people who use Vault will use a proprietary application that's not even available in normal repos?)

What does this mean?

If I try to pass it a 2048-bit key, it barfs on the packet header.

What error are you getting?

[jantman]

My comment about PGP vs GPG is essentially that, in my opinion, most people who are choosing Vault (or HashiCorp products in general) are likely doing so either because they're F/OSS or because they're easy to download and install (no licenses, forms, etc.). Most systems that Vault will be installed on have GPG easily accessible - either usually installed already in the case of Linux, or relatively easily installable on other systems. That's not the case with PGP. Unless I'm missing a big portion of Vault's userbase (banks maybe), my guess would be that there are many systems running Vault that don't have PGP installed and licensed. The gist of my feeling is: even if GPG isn't considered the default use case, it should be considered highly enough to have docs for it, and not just "figure it out yourself, bro." (In other words: I'm on Linux; I use many Hashicorp products and chose them first and foremost because they're F/OSS. GPG is not "non-standard" in the Linux world.)

The error I'm getting is:

Error parsing given PGP key: openpgp: invalid data: tag byte does not have MSB set

This is clearly coming from the Go openpgp library, and I can reproduce it locally using similar code.

[jefferai]

@jantman All of our testing is done with either the Golang openpgp library, which attempts to adhere to https://tools.ietf.org/html/rfc4880, or gpg. No proprietary binaries are used or required.

As for the error, a reproduction case would be useful since you are saying you can reproduce it locally.

[jantman]

@jefferai I'm unable to reproduce the issue using the Vault CLI, so I'm guessing that the issue with 2048-bit keys was either a problem with my code.

I've tried to make my doc clarifications as minimal as possible, and have opened https://github.com/hashicorp/vault/pull/1551 for them.

[jantman]

Sorry for taking up your time on this.