concepts: GnuPG-replacement: Handle stakeholder feedback

Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>

content/concepts/gnupg-replacement.md

@@ -14,6 +14,7 @@ This is problematic in the long term: the purpose of this document is to investi
 The use cases for Apertis target images only depend on GnuPG for verification purposes, not for signing or encrypting. This is usually done through the `gpgv` tool or through the `libgpgme` library which invokes the `gpg` tool and interacts with it via the [`--with-colons` machine parsable mode](https://github.com/gpg/gnupg/blob/master/doc/DETAILS) or the  [Assuan](https://www.gnupg.org/documentation/manuals/assuan/index.html) IPC protocol.
 
 Newer `GPL-3`-licensed versions of GnuPG can be provided in the `development` package repository for any additional need outside that do not affect targets.
+Until `Ed25519` support is officially implemented in APT, the upstream version is imported in Apertis and our infrastructure is reworked to use it rather than OpenPGP signatures, we will need GnuPG to sign and install packages on development images. This does not affect production devices as APT is not meant to be used there.
 
 # Terminology and concepts
 
@@ -80,7 +81,7 @@ Current packages using `GnuPG` or `gpgv` are:
  ostree                  | gnupg, libgpgme11(1)
  volume-key              | gnupg, libgpgme11
 
-(1) Currently `OSTree` in Apertis does not depend on `GnuPG` as it exclusively uses `Ed25519` signatures. However, the reintroduction of OpenPGP signature verification support may be requested in the future to be able to install applications from third-party Flatpak repositories that only provide OpenPGP signatures.
+(1) Currently `OSTree` in Apertis does not depend on `GnuPG` as it exclusively uses `Ed25519` signatures. However, the reintroduction of OpenPGP signature verification support may be requested in the future to be able to verify the provenance and install applications from third-party Flatpak repositories that only provide OpenPGP signatures.
 
 ## apertis-archive-keyring
 
@@ -133,7 +134,7 @@ The following alternative replacements have been considered:
  library                      | License                                  | language | comment
  ---------------------------- | ---------------------------------------- | -------- | ----
   RNP                         | BSD-2-Clause + BSD-3-Clause + Apache-2.0 | C++
-  rpgp                        | Apache-2.0 or MIT                        | Rust
+  rPGP                        | Apache-2.0 or MIT                        | Rust
   Sequoia                     | GPL-2+                                   | Rust     | uses Nettle/GMP but with the GPL-2 licensing it should match the Apertis license expectations
   golang.org/x/crypto/openpgp | BSD-3-Clause                             | Golang
   gpgrv                       | Apache-2.0 or MIT                        | Rust     | only provides gpgv
@@ -154,12 +155,13 @@ Used by:
 - Thunderbird
 - [EnMail](https://github.com/riboseinc/enmail) ruby gem
 
-## rpgp
+## rPGP
 
 https://github.com/rpgp/rpgp
 
 Started in 2017.
 
+Project description from rPGP site:
 > rPGP is the only full Rust implementation of OpenPGP, following RFC4880
 > and RFC2440. It offers a minimal low-level API and does not prescribe
 > trust schemes or key management policies. It fully supports all
@@ -213,11 +215,11 @@ Project status:
 > There is a mostly feature-complete command-line verification tool for
 > detached messages called 'sqv'.
 
-`Sequoia` uses [Nettle](https://git.lysator.liu.se/nettle/nettle) which is dual licensed LGPL-3.0 and GPL-2.0. This is compliant with the Apertis [Open Source License Expectations]({{< ref "policies/license-expectations.md" >}}) since Sequoia itself is licensed under the GPL-2.0 terms.
+`Sequoia` uses [Nettle](https://git.lysator.liu.se/nettle/nettle) which is [dual licensed LGPL-3.0 and GPL-2.0](http://www.lysator.liu.se/~nisse/nettle/nettle.html#Copyright), see COPYING.LESSERv3, COPYINGv3, and COPYINGv2 files in the [Nettle source repository](https://git.lysator.liu.se/nettle/nettle). This is compliant with the Apertis [Open Source License Expectations]({{< ref "policies/license-expectations.md" >}}) since Sequoia itself is licensed under the GPL-2.0 terms.
 
 Version                         | # commits | # contributors | CI  | gpgv replacement | C API
 -------                         | --------: | -------------: | :-: | :--------------: | -----
-library: 1.0.0<BR>other: 0.23.0 |      3948 |             33 | yes | yes              | yes
+library: 1.0.0<BR>Command line tools: 0.23.0 |      3948 |             33 | yes | yes              | yes
 
 Used by:
 - Pijul, KIPA, Radicle, see https://sequoia-pgp.org/projects/
@@ -265,7 +267,7 @@ The `golang.org/x/crypto/openpgp` package only provides a Go interface and would
 
 `RNP` and `Sequoia` provide C interfaces and CLI interfaces to encrypt, decrypt, sign or verify files. They have both received a lot of commits, and have many contributors.
 
-`rpgp` does not provide any CLI interface and a C interface would require a Rust shim, but its licensing terms are much more flexible than the Sequoia ones. It is actively developed. but it has fewer commits and contributors than Sequoia.
+`rPGP` does not provide any CLI interface and a C interface would require a Rust shim, but its licensing terms are much more flexible than the Sequoia ones. It is actively developed. but it has fewer commits and contributors than Sequoia.
 
 Red Hat removed the OpenPGP support from Thunderbird in Red Hat Enterprise Linux (RHEL), which uses `RNP`, due to not wanting to distribute [Botan](https://botan.randombit.net/), which has inadequate side-channel protection, see Red Hat bugs [1837512](https://bugzilla.redhat.com/show_bug.cgi?id=1837512) and [1886958](https://bugzilla.redhat.com/show_bug.cgi?id=1886958).
 
@@ -281,6 +283,8 @@ Adopting a solution which is aligned to the upstream goals would save maintenanc
 
 # Recommendations
 
+The split between `rPGP` (more permissive license, more limited goals) and Sequoia (more active, GPL-2.0 only) is unfortunate since `rPGP` would be more suitable for us but is also more risky regarding long term maintenance, with Sequoia being more promising in this regard.
+
 The problems to be addressed are:
 
 1. the use of GnuPG via `gpgv` on the target reference images
@@ -293,15 +297,18 @@ For `gpgv` there are two possible approaches:
 
 For `libgpgme` the situation is more complex because the API surface is way bigger and there are no drop-in replacements.
 In addition Sequoia, by being GPL-2.0 licensed, is not suitable to be directly linked from `GMime`, `OSTree` and `Flatpak` which are LGPL-2.1 and provide libraries that are meant to be linked by applications that may be released under licenses incompatible with the GPL-2.0 or even proprietary.
-`rpgp` may be a better choice in this regard.
+`rPGP` may be a better choice in this regard.
 
 The approach could then be:
 
 1. ship `sqv` on target images and symlink it as `gpgv` so that it gets transparently picked up by APT
 1. patch `apertis-archive-keyring` to install the .asc directly, avoiding any build-dependency on GnuPG
 1. disable OpenPGP support from `OSTree`, replacing it with the use of Ed25519 signatures
+   - this will drop the ability to assert trust when pulling from third party OpenPGP-signed repositories, which has never been a use-case of interest in Apertis
 1. disable OpenPGP support from `Flatpak`, replacing it with the use of Ed25519 signatures
+   - this will drop the ability to assert trust when pulling from third party Flatpak repositories, which is not a use-case of interest for Apertis target devices but at some point is likely to be desirable on the SDK, so we may consider re-introducing GnuPG support only there where the GPL-3 restrictions are not a concern
 1. disable OpenPGP support from `GMime`
+   - this will drop the ability to send/receive encrypted emails when using evolution-data-server, which has never been a use-case of interest in Apertis
 1. disable key escrow support from `libblockdev` so we can drop the `volume-key` package as a whole with its dependency on `libgpgme`
 1. move the `gpgme` source package to the `development` package repository
 1. move the `gnupg` source package to the `development` package repository
@@ -314,12 +321,11 @@ In the longer term, other activities can be undertaken to get rid of the downstr
 
 1. engage with the APT upstream maintainers to help them [move away from OpenPGP signatures](https://wiki.debian.org/Teams/Apt/Spec/AptSign)
 1. engage with OSTree and Flatpak upstream maintainers to dynamically load `libgpgme` that it can be picked up on the SDK where installing GPL-3.0 components is not an issue and where it can be useful to install applications from third-party store like Flathub
+1. engage with Flathub people to support `Ed25519` signatures in addition to the OpenPGP ones
 1. fully re-enable OpenPGP support in the components where it has been disabled by either:
-  1. porting them to use `rpgp` by engaging with the upstream maintainers about implementing minimal Rush shims
+  1. porting them to use `rPGP` by engaging with the upstream maintainers about implementing minimal Rush shims
   1. implementing a `libgpgme` backend that invokes Sequoia externally to avoid licensing issues, either by engaging with the `libgpgme` maintainers or the Sequoia maintainers by providing compatibility with the  [`--with-colons` machine parsable mode](https://github.com/gpg/gnupg/blob/master/doc/DETAILS)
 
 # Risks
 
 Drop-in reimplementations may not be 100% compatible and thus may cause subtle issues.
-
-The split between `rpgp` (more permissive license, more limited goals) and Sequoia (more active, GPL-2.0 only) is unfortunate since `rpgp` would be more suitable for us but is also more risky regarding long term maintenance, with Sequoia being more promising in this regard.