LWN: Comments on "OpenPGP in Rust: the Sequoia project"

OpenPGP in Rust: the Sequoia project

cpitrat — Mon, 05 Oct 2020 06:52:50 +0000

"it does avoid the outdated parts of the specification such as the use of MD5 hashes."

Does that mean I may not be able to decipher something I stored on an cd-rom 15 years ago and didn't re-encrypt since? It sounds like being retro-compatible is important at least for decoding.

OpenPGP in Rust: the Sequoia project

oldtomas — Sun, 27 Sep 2020 17:14:58 +0000

Now this is interesting.

I assume it was private communicaton. If not, I'd appreciate a link to that, to learn motivation and background.

OpenPGP in Rust: the Sequoia project

donbarry — Thu, 24 Sep 2020 03:21:04 +0000

It all depends on whether you think the point is to improve software freedom or to give firms ammunition to create fear, uncertainty, and doubt. I'm firmly in the camp of the GPLv3. It addresses problems which arose when billions of dollars of revenues were tied to new ecosystems and methods were developed by their corporate fiefs outside the spirit of the GPLv2 to control those ecosystems, and their fury that they would lose those unprincipled mechanisms back to users.

OpenPGP in Rust: the Sequoia project

Wol — Wed, 23 Sep 2020 23:54:20 +0000

And if your customer is on a metered connection they won't thank you ...

Cheers,
Wol

OpenPGP in Rust: the Sequoia project

flussence — Wed, 23 Sep 2020 23:04:44 +0000

>and some other things which I’ve forgotten

…like remediating the sudden death aspect of GPLv2. The old version certainly is better if you're Patrick McHardy.

OpenPGP in Rust: the Sequoia project

jwilk — Tue, 22 Sep 2020 06:30:41 +0000

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

Comet — Thu, 17 Sep 2020 20:05:07 +0000

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

OpenPGP in Rust: the Sequoia project

alison — Thu, 17 Sep 2020 14:36:57 +0000

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

OpenPGP in Rust: the Sequoia project

mezcalero — Thu, 17 Sep 2020 07:48:59 +0000

Use libfdisk from util-linux for the GPT stuff.

OpenPGP in Rust: the Sequoia project

martin.langhoff — Tue, 15 Sep 2020 14:23:21 +0000

In GPLv2 the social contract is - share and share _code_ alike. The hardware running software was nowhere in the picture.

Good? Bad? That was the social contract under GPLv2.

GPLv3 introduces rules about the User Product. We're trying to leverage _software_ to put rules on _hardware_. That is a new frontier, and a new social contract.

No significant/popular low-level software projects, where this matters, have adopted GPLv3. So on that front, it did not find traction.

And here's the funny thing -- I personally dislike Tivoization. If the current GPLv3 was called T(ivo)GPL, similar to what happened with AGPL, and we had a GPLv2.1, life would be much better.

OpenPGP in Rust: the Sequoia project

cyphar — Tue, 15 Sep 2020 05:06:08 +0000

> No, that does not hold. You get the tools so can build install the executable... somewhere.

Yes, GPLv2 and GPLv3 are obviously legally speaking quite different on this point.

My point is that since the discussion was about "social contracts", it should be noted that the GPLv2 does have a spiritually similar requirement. If you don't see the similarity in spirit between "scripts that control the compilation and installation of the executable" and "any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source", I don't really know what else to say. My point was simply that the new requirements didn't come out of nowhere.

OpenPGP in Rust: the Sequoia project

martin.langhoff — Mon, 14 Sep 2020 21:09:56 +0000

> while folks like to wax lyrical about GPLv3's tivoisation clause, many seem to forget
> that GPLv2 actually had a similar (in spirit) requirement

No, that does not hold. You get the tools so can build install the executable... somewhere.

The _gist_ of GPLv2 is share and share-alike. It's about the source code.

GPLv3 improved on v2 on many aspects, but also brought it a new front: control of the hardware. Applied to software not tightly tied to hw -- a web app -- it doesn't matter. Applied to kernels, device drivers, etc it's a massive problem. As a result, folks who work closely to hardware don't want to use it.

To be clear. I don't intend to re-hash the GPLv3 controversies here. Just to point out -- GPLv3 is different, in a meaningful way. Pick GPLv2 or GPLv3, but know they are different beasts.

OpenPGP in Rust: the Sequoia project

abo — Mon, 14 Sep 2020 10:21:50 +0000

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

cyphar — Sun, 13 Sep 2020 23:24:22 +0000

I do want to point out (since I assume your reference to "change in the social contract" is in relation to the tivoisation clause), that while folks like to wax lyrical about GPLv3's tivoisation clause, many seem to forget that GPLv2 actually had a similar (in spirit) requirement:

> For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. [emphasis added]

I don't think it's a stretch to say that if firmware keys were widely deployed in 1991 that GPLv2 would've had a more substantial clause dedicated to making sure that the "scripts used to control compilation and installation of the executable" would've included any firmware signing keys necessary to make it possible to actually use the software you've modified. And yes, the modern interpretation of "scripts used to control compilation and installation of the executable" does include instructions on how to install the software on to whatever hardware you've been sold.

My point is, maybe you disagree with the tivoisation clause -- but GPLv2 clearly had a similar spirit in this area (it's just that the FSF didn't predict that firmware signing was going to be a widespread method for stopping people from being able to run modified software). So it's less a "change in the social contract" and more "updating the legal wording to match the original intent in a world where firmware signing keys exist"

OpenPGP in Rust: the Sequoia project

vadim — Sun, 13 Sep 2020 17:16:24 +0000

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

kushal — Sun, 13 Sep 2020 14:42:25 +0000

I am writing a Python module on top of Sequoia. https://github.com/kushaldas/johnnycanencrypt

OpenPGP in Rust: the Sequoia project

link2xt — Sun, 13 Sep 2020 13:56:00 +0000

If you need a library instead of a command line tool, there is rPGP: https://github.com/rpgp/rpgp

It is licensed under MIT/Apache 2.0, like most of the code in Rust.

OpenPGP in Rust: the Sequoia project

ballombe — Sun, 13 Sep 2020 12:53:11 +0000

Do not bother. Just include a copy of the source in the binary package!

OpenPGP in Rust: the Sequoia project

cyphar — Sun, 13 Sep 2020 08:15:31 +0000

If you want compatibility with Apache-2.0 (which GPLv2 doesn't have), you need to have patent grants.

OpenPGP in Rust: the Sequoia project

neal — Sun, 13 Sep 2020 07:34:55 +0000

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

josh — Sun, 13 Sep 2020 05:35:10 +0000

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

OpenPGP in Rust: the Sequoia project

alison — Sun, 13 Sep 2020 04:43:26 +0000

>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

vadim — Sat, 12 Sep 2020 22:19:35 +0000

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

dbnichol — Sat, 12 Sep 2020 20:17:12 +0000

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

martin.langhoff — Sat, 12 Sep 2020 19:47:38 +0000

I'm with Wol.

GPLv3 is _different_.

Some bug fixes that would be nice to fold into a "GPLv2.1".

And some major changes of social contract, which would be better suited in a different license.

OpenPGP in Rust: the Sequoia project

Wol — Sat, 12 Sep 2020 18:57:40 +0000

But it means that OpenPGP becomes a "code donor" project only - they cannot re-use code from other projects because they need to reach out to the copyright holder - the code hasn't been submitted to the project.

That's the problem with any extension to the GPL - you can't take advantage of other GPL code to include in your own project.

Cheers,
Wol

OpenPGP in Rust: the Sequoia project

Wol — Sat, 12 Sep 2020 18:51:04 +0000

> I actually won't mind a lawyer-proofed GPL exception to allow distribution through app stores, but that won't allow abuse ("my application is a store, so I can distribute GPL-ed app through it!").

Just say "it is acceptable to distribute binaries on a binary-only site, provided the download points the user to the corresponding source on a 3rd-party source distribution site (3rd party as in "not yours, not the app-store"). Note that the GPLv3 permits separate distribution of binary and source without triggering the "binary-only means you must offer source for 3 years" clause. (That was a bug in v2, which at least some people would love to have seen make its way into v3). It's a bug because it means the actions of the recipient change the liability of the provider.

Cheers,
Wol

OpenPGP in Rust: the Sequoia project

vadim — Sat, 12 Sep 2020 16:55:39 +0000

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

neal — Sat, 12 Sep 2020 16:25:48 +0000

The cited text is a bit misleading. It's true that private key operations will normally be executed in a separate process. And, you're right, that is exactly what gpg-agent is used for. What sq and the sequoia's high-level API will encourage, and what is different from GnuPG, is how keys are addressed.

Sequoia's key store firstly uses petnames to address keys. You can think of a petname like an entry in a personal address book: it's controlled by you, not the person who created the key. In this way, address book entries are directly associated with keys. Currently, this is done indirectly: you select a recipient from your address book, your MUA pulls out some information and queries GnuPG's key store for a key with a matching identifier, and uses the returned key. That works okay, as long as you carefully curate your keyring, and don't have multiple keys with the same identifier. But, once that happens, the logic becomes rather unpredictable for most users.

OpenPGP in Rust: the Sequoia project

rvolgers — Sat, 12 Sep 2020 15:40:19 +0000

That's not a problem in this case since contributors are required to assign copyright to the foundation, who can relicense with exceptions as needed, if I understand correctly.

OpenPGP in Rust: the Sequoia project

Wol — Sat, 12 Sep 2020 15:04:27 +0000

I wouldn't call providing patent grants an improvement ...

Yes v3 has a bunch of bug-fixes for v2, and if they'd limited to that it would be a real improvement.

(And I've had people say that - for things that the FSF said were bug fixes - they thought v2 was a feature and didn't WANT the fix!)

So I think a LOT people wouldn't say v3 was an improvement.

Cheers,
Wol

OpenPGP in Rust: the Sequoia project

Deleted user 129183 — Sat, 12 Sep 2020 13:29:47 +0000

> GPLv3 is NOT better...

Please stop spreading FUD. GPL 3 improves upon GPL 2 by fixing the tivoisation loophole, providing patent grants, increasing compatibility with licences like Apache 2 and some other things which I’ve forgotten.

OpenPGP in Rust: the Sequoia project

grawity — Sat, 12 Sep 2020 10:04:50 +0000

> Key storage is one of the areas where Sequoia's plans are unique compared to other OpenPGP implementations. For added security, the project plans to use process separation between the services handling public and private keys; Cap'n Proto will be used for interprocess communication.

Is that significantly different from GnuPG 2.x using gpg-agent for all private key operations?

OpenPGP in Rust: the Sequoia project

neal — Fri, 11 Sep 2020 21:33:51 +0000

We actually originally picked GPLv3+, but someone asked us to change to GPLv2+ and the request was reasonable, so we did.

OpenPGP in Rust: the Sequoia project

Cyberax — Fri, 11 Sep 2020 21:31:09 +0000

> So, the real question is, why did they pick GPLv2 when GPLv3 is better? They want their program embedded in tivoized devices without any legal recourse? They should upgrade their license.
GPLv3 is NOT better...

OpenPGP in Rust: the Sequoia project

IanKelling — Fri, 11 Sep 2020 20:44:35 +0000

*not be in conflict with the GPL

OpenPGP in Rust: the Sequoia project

IanKelling — Fri, 11 Sep 2020 20:43:29 +0000

Why not change the iOS TOS to be conflict with the GPL?

I think there are a few GPL apps on iOS (GNU Jami is the one I know of) that have been there for years, so Apple just doesn't seem to care or enforce their TOS.

So, the real question is, why did they pick GPLv2 when GPLv3 is better? They want their program embedded in tivoized devices without any legal recourse? They should upgrade their license.

OpenPGP in Rust: the Sequoia project

Cyberax — Fri, 11 Sep 2020 19:54:09 +0000

The problem is that the GPL+disclaimer is basically a different license, and every contributor must agree to it.

This is not really sustainable. For example, if Apple is forced to split the Apple Store into a different company and rename it to "Pear Store", the disclaimer will become void. They'll have to get agreement for a new exception from every copyright holder who has ever contributed to the core code.

I actually won't mind a lawyer-proofed GPL exception to allow distribution through app stores, but that won't allow abuse ("my application is a store, so I can distribute GPL-ed app through it!").

OpenPGP in Rust: the Sequoia project

geofft — Fri, 11 Sep 2020 19:48:18 +0000

The copyright holders can disclaim any restrictions of the GPL that conflict with the App Store terms. For instance, Blink Shell is GPL'd and has been available on iOS for a while, relying on a waiver from the mosh developers (since mosh is also GPL'd).

OpenPGP in Rust: the Sequoia project

jazzy — Fri, 11 Sep 2020 19:32:54 +0000

Yes, and it will still be invoked as a command line tool by non GPLv2 projects to avoid the copyleft. Why not adopt MPL 2.0 which is copyleft per file and can be used on iOS like VLC.