search

ostreedev / ostree

Operating system and container binary deployment and upgrades
https://ostreedev.github.io/ostree/
Other
1.3k stars 296 forks source link

Replace GPGME with Sequoia-PGP #2304

Open dbnicholson opened 3 years ago

dbnicholson commented 3 years ago

If you've ever had to work with the GPGME code in ostree you will know that it is pretty painful. Furthermore, the implementation of GPGME is that it literally just runs the gpg CLI, and the gpg CLI is very much built around a user with a persistent GPG home directory. It is not built around applications using PGP. For instance, you can't just hand GPGME a keyring. You have to create a GPG homedir on the fly and import the keyring into it.

I haven't looked into this at all, but a while ago I saw Sequoia-PGP, which is a new PGP library written in rust. It seems the authors were people that worked with GnuPG for a long time before deciding that they needed to do something different. There's obviously a native rust interface, but there's also a C FFI. It seems that the basic things we need are in there.

Keyrings - https://docs.sequoia-pgp.org/sequoia_openpgp/cert/struct.CertParser.html Signing - https://docs.sequoia-pgp.org/sequoia_openpgp/serialize/stream/struct.Signer.html Verifying - https://docs.sequoia-pgp.org/sequoia_openpgp/packet/enum.Signature.html#method.verify_direct_key

I didn't look that hard, but I do see the package in debian and arch but not fedora:

https://packages.debian.org/source/sid/rust-sequoia-openpgp https://archlinux.org/packages/community/x86_64/sequoia/

The debian package does not seem to install the C FFI, but the arch package does.

cgwalters commented 3 years ago

I think if I could go back I'd drop the extensive C API wrapping we have for gpg and basically just expose "commit OK/not-OK" where "not OK" just gives you a string for things like expired keys etc.

That would make this way easier, including forking the verifier off as a separate unprivileged sandboxed process.

dbnicholson commented 3 years ago

Certainly maintaining the public API would probably be difficult with a different underlying implementation. I haven't looked closely, but I don't think it would be impossible, though. Presumably all the details about the keys and signatures are still available with a different PGP implementation. I was actually thinking more about the internal implementation, which is pretty nasty.

Forking off the verifier in a sandbox is interesting. I'm pretty sure you could do it now with GPGME if you wanted. Once you have the GPG homedir setup then there's nothing that it needs from the outside world besides the data to validate AFAIK.

So, without looking closely I think both maintaining the public API and sandboxing the verifier would be possible regardless of the underlying implementation. Not that I'm planning on working on this anytime or anything.