OpenPGP in Rust: the Sequoia project

Posted Sep 12, 2020 16:55 UTC (Sat) by vadim (subscriber, #35271)
Parent article: OpenPGP in Rust: the Sequoia project

Very interesting.

This sounds exactly like the sort of thing I needed. Some time back I tried doing a PGP related project, and found GPG's structure very inconvenient. One of the things I want is to go through the archive of a keyserver and parse the data. The need to invoke GPG, feed it a key, and parse the result was slow and painful. What I really want is a library where I can take an ASCII encoded key, feed it to some function and get all the data back -- who it belongs to, who signed it, when it expires, etc, while ensuring the key is fully valid and all the signatures are correct and so on. All of that should ideally happen without needing to launch a million processes and needing to work around GPG's desire for things like a home directory and a keyring.

If this project is usable for such a task, I'm very interested, and Rust sounds like a bonus because there's obvious security concerns in parsing a huge key archive that may well have been attacked in many ways over the years.

OpenPGP in Rust: the Sequoia project

Posted Sep 12, 2020 20:17 UTC (Sat) by dbnichol (subscriber, #39622) [Link] (6 responses)

Completely agree. GPGme tries to fill the role of a library for PGP, but since it's just a wrapper around gpg, you need to do things like have a gnupg homedir even if you just want to examine a keyring. The architecture of the gnupg project as a whole is backwards. GPGme literally invokes gpg and scrapes the output instead of gpg being a frontend to a PGP library. Besides being a crazy way to implement an API, it means that any feature in GPGme has to first be represented as some gpg CLI option.

I saw sequoia a while ago and am excited to see where it goes.

OpenPGP in Rust: the Sequoia project

Posted Sep 12, 2020 22:19 UTC (Sat) by vadim (subscriber, #35271) [Link]

Yeah, back when I was messing with that, I was looking for libraries. Found GPGme, thought "oh yeah, this is what I need. Wait... WTF?"

I think PGP was greatly handicapped by the backwardness of GPG's design. Had it been better it'd be far more pleasant to integrate into other software, would be better supported, more performant, and there'd be a much larger ecosystem of tools built around it. Pity, really.

The bad performance is no joke, by the way. GPG is noticeably slow even on modern hardware. This could probably be avoided with a library that caches data internally, but when you run gpg once per message it requires paying a quite steep startup cost that's very noticeable.

Still, I think this is a fixable problem, because nothing really superseded it as far as I know, so there's still hope that Sequoia and other projects fix this situation.

OpenPGP in Rust: the Sequoia project

Posted Sep 13, 2020 4:43 UTC (Sun) by alison (subscriber, #63752) [Link] (4 responses)

>GPGme tries to fill the role of a library for PGP, but since it's just a wrapper around gpg, you need to do things like have a gnupg homedir even if you just want to examine a keyring.

GnuPG is far from being the only common Linux tool which needs a library in addition to a CLI tool. Two that bit me personally have been mtd-utils and sgdisk. I needed libraries for my own code, so I basically creating what was, in effect, a libmtd and libgpt in a project's build system. I was hoping to have employer support to do a cleaner job of creating libraries and posting patches upstream, but they never agreed. As a result, I finally had to rip all of the code out in order to avoid license violations.

It's great the Sequoia is taking a more sensible approach: make a great library with good test coverage, and then a reference implementation binary that other can try out or even use.

OpenPGP in Rust: the Sequoia project

Posted Sep 13, 2020 5:35 UTC (Sun) by josh (subscriber, #17465) [Link]

For disk partitioning, you could use libparted. The Debian installer uses that for its partitioner.

OpenPGP in Rust: the Sequoia project

Posted Sep 17, 2020 7:48 UTC (Thu) by mezcalero (subscriber, #45103) [Link] (2 responses)

Use libfdisk from util-linux for the GPT stuff.

OpenPGP in Rust: the Sequoia project

Posted Sep 17, 2020 14:36 UTC (Thu) by alison (subscriber, #63752) [Link] (1 responses)

Neither libfdisk nor libparted fully support EFI. For example, no partition labels.

OpenPGP in Rust: the Sequoia project

Posted Sep 22, 2020 6:30 UTC (Tue) by jwilk (subscriber, #63328) [Link]

As far as I can see, libfdisk does support EFI partition labels:

extern int fdisk_partition_set_name(struct fdisk_partition *pa, const char *name);
extern const char *fdisk_partition_get_name(struct fdisk_partition *pa);

OpenPGP in Rust: the Sequoia project

Posted Sep 13, 2020 7:34 UTC (Sun) by neal (subscriber, #7439) [Link] (1 responses)

Here is a small program that iterates over each certificate ("OpenPGP Key") in an SKS dump, and prints a bit of information about the certificate. You can look at the source to "sq dump" to see how to extract other information.

OpenPGP in Rust: the Sequoia project

Posted Sep 13, 2020 17:16 UTC (Sun) by vadim (subscriber, #35271) [Link]

Very helpful, thanks a lot!

I'm a complete newbie in Rust, but been thinking of trying to make something in it for some time.

OpenPGP in Rust: the Sequoia project

Posted Sep 14, 2020 10:21 UTC (Mon) by abo (subscriber, #77288) [Link] (1 responses)

Even something as simple as verifying that file A is indeed signed by the key in file B, an operation that should be quite common, requires a writable home directory and multiple fragile steps.

OpenPGP in Rust: the Sequoia project

Posted Sep 17, 2020 20:05 UTC (Thu) by Comet (subscriber, #11646) [Link]

Isn't that the use-case for the gpgv(1) tool, part of the GnuPG suite?