Hello, There are modern implementations of openpgp-card (https://en.wikipedia.org/wiki/OpenPGP_card) supporting tools, written in Rust. They are easy to use, have less moving parts and are licensed as free software (MIT / Apache). - openpgp-card-tools (https://codeberg.org/openpgp-card) - CLI utility to manage openpgp-cards --> crates.io: https://crates.io/crates/openpgp-card-tools/0.9.4 - openpgp-card-ssh-agent (https://codeberg.org/openpgp-card/ssh-agent) - Lightweight implementation of an ssh-agent to use with openpgp-cards --> crates.io: https://crates.io/crates/openpgp-card-tools - oct-git (https://codeberg.org/openpgp-card/oct-git) - Lightweht tool to sign git commits using an openpgp-card --> crates.io: https://crates.io/crates/openpgp-card-tool-git Using those tools, it is much easier to use a openpgp-card (or Yubikey/Nitrokey etc) to securely work with them and there are was less moving parts in comparison to the full gpg suite. They are already packaged for other modern Linux distributions, but not in the Fedora ecosystem so far. I tried packaging them with rust2rpm for myself and invested two days into that but my technical expertise wasn't enough, to deal with all the rust dependencies that would be necessary. I'd suggest to have those utilities packaged as Fedora packages to have them included in future releases and give users the option to utilize openpgp crypto cards for secure operations, git signing and ssh-authentication to remote systems. Regards, Larvitz Reproducible: Always
The "Package Review" component here is used for reviewing packages, not as a package wishlist. (There is also no official wishlist of things that are not yet packaged for Fedora, though some groups maintain incomplete and / or outdated lists that are specific to their ecosystem.) That said, I would caution against packaging these projects, at least for now. They are in the process of getting ported away from Sequoia-PGP (which we have packaged in Fedora) to rPGP (a competing Rust implementation of PGP), and currently even depend on pre-releases of rPGP. I previously added these OpenPGP card tools projects to the "Rust package wishlist", but with the projects moving to rPGP, I dropped them again (at least for now).
The ticket summary is not in the correct format. Expected: Review Request: <main package name here> - <short summary here> Found: [RFE] Please include Rust openpgp-card utilities as packages As a consequence, the package name cannot be parsed and submitted to be automatically build. Please modify the ticket summary and trigger a build by typing [fedora-review-service-build]. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Hello Fabio, Larvitz, I am a co-author of the crates in question. @Fabio, good point that from a packaging perspective depending on pre-release versions is not ideal, thanks. All current releases of the applications use stable dependencies (and going forward I won't make application releases with stable version numbers and pre-release dependencies). I see no reason why shipping both rPGP and Sequoia-PGP would be any different in principle to shipping both OpenSSL and GnuTLS. If you have additional pointers on why depending on rPGP is a problem for packaging, I'd appreciate your input. As context for onlookers: rPGP is a pure Rust implementation of the OpenPGP standard. It has received independent security audits (see https://github.com/rpgp/rpgp/blob/main/docs/SECURITY_STATUS.md), is loosely affiliated with the Rust Crypto project, and has seen long-term real world use in https://delta.chat/ by a significant user base, including at-risk populations. Thanks, Heiko
> All current releases of the applications use stable dependencies That's great news! This will certainly make it easier for anybody who wants to package these tools. > see no reason why shipping both rPGP and Sequoia-PGP would be any different in principle to shipping both OpenSSL and GnuTLS. > If you have additional pointers on why depending on rPGP is a problem for packaging, I'd appreciate your input. I don't see a specific problem, other than a bit of "duplicated" effort, in the sense that we already have one OpenPGP implementation in Rust available, while the other one will still need to go through packaging + review and will result in additional maintenance burden.