This replaces the current PGP keysource implementation with a modernized
version the Flux project has been using[1].
It includes utilites to configure the MasterKey via other means than
environment variables, to allow SDK users to have extensive control
over what things are decrypted with. This can for example be combined
with an own keyserver implementation.
To be able to contribute it back upstream while keeping it backwards
compatible with SOPS, a couple of changes have been made compared to
Flux:
- Instead of removing the enabling of the agent while making use of
GnuPG, it can now be disabled.
- Support for OpenPGP has been added back. Note however my comments
on this in-code, as I am not quite sure to what extend it is used
at the moment, as it will not work on most setups (GnuPG <2.1 was
released in 2017.)
- The absolute paths to the pub and sec keyrings can now be configured
by SDK users. This would add more reason to keep OpenPGP around, if
they are able to produce the keyring files themselves via other means
than GnuPG.
- When a sec keyring is not detected, a lookup for the pub keyring is
made and loaded instead if found. This to account for GnuPG >=2.1
merging the sec keyring into pub keyring.
- Support for fetching keys from servers has been removed. This can be
added back if we need to keep it around for a little longer.
This has extensive test coverage for GnuPG, but would need coverage for
the re-added OpenPGP implementation before it can be deemed ready.
[1]: ffdda3f3da/internal/sops/pgp
Signed-off-by: Hidde Beydals <hello@hidde.co>
* `golang.org/x/crypto/openpgp` requires keys contain identity information.
* A email address can have only a single key with identity information on keys.openpgp.org.
* Fix tests
* Fix endless loop in x/crypto/openpgp func ReadMessage
This fixes https://github.com/mozilla/sops/issues/665
See also https://github.com/golang/go/issues/28786
In some strange situations it can happen, that openpgp.ReadMessage()
runs into a endless loop. This seems to be triggered by a slightly
inconsistency in key settings.
It happened to me, but I wasn't able to reproduce it with a fresh key.
A proposed solution from the x/crypto community was, to break this loop
in the callback passphrasePrompt.
* Revert "Fix tests"
This reverts commit 285f4dc8a1.
* Improve error description
https://github.com/mozilla/sops/pull/690#discussion_r451630193
since we encode binary data this is generally a good idea
this commit fixes #278 - now both crypto/openpgp and gpg work in a binary
mode, and we can safely use both interchangeably
(e.g. encrypt with crypto/openpgp, and then decrypt with gpg)
In SOPS 1.x, KMS encryption context was stored as a JSON object, but
SOPS 2.0 stored it as a comma-separated list of key/value pairs:
```
$ jq '.sops.kms | .[].context' encrypted-python
{
"a": "b",
"c": "d"
}
> jq '.sops.kms | .[].context' encrypted-go
"a:b,c:d"
```
The two outputs are incompatible with each other and caused a stack
trace when reading files encrypted with SOPS 1.x.
This patch restores read and output compatibility with SOPS 1.x.
Fixes #190.
