r/linux • u/adriano10 • 2d ago
Event Ubuntu's Next Rust Effort May See OpenPGP Replaced By Sequoia PGP
https://www.phoronix.com/news/Ubuntu-Rust-Sequoia-PGP60
u/MVanderloo 2d ago
I found sequoia recently because I was looking for a nicer CLI to interact with PGP than the gpg CLI. Cosmetically the project appears mature but I’m curious if it’s really ready for primetime.
also Ubuntu 26.10 “Stonking Stingray” 😂
14
u/death_by_cormorant 2d ago
I have zero intention of running Ubuntu but Jesus that is one of the coolest names they've ever done
30
u/Irverter 2d ago
How is the emoji in cursive? O.o
19
u/wurnthebitch 2d ago
If you put it in bold, it adds makeup
5
u/Indolent_Bard 2d ago
Does that mean that it's modifying the image or that the italicized version already existed? Because I'm pretty sure you need an italicized glyph before your font will actually italicize.
8
4
7
5
u/MVanderloo 2d ago
idk lol, I copied the text from the article and I guess the style was preserved when i added the emoji. I’m not seeing it on the iOS client though
29
u/FriendlyProblem1234 2d ago
Given every GPG binding's frustrating approach to error reporting, that is "an error has happened somewhere in the operations pipeline", working with Sequoia was a breath of fresh air. No doubt it is easier to use Sequoia correctly, rather than GPG.
14
u/levelstar01 2d ago
Anyone who has ever had the displeasure of interacting with GPG should be happy with this.
15
u/skyb0rg 2d ago
If anyone is curious why GnuPG should be avoided at all costs, I'd recommend taking a look at this talk: https://media.ccc.de/v/2026-728-the-gpg-fail-aftermath-on-responsible-disclosure-gpg-and-the-state-of-security-in-2026
44
u/evmt 2d ago
I'm curious, considering that Sequoia is licensed under GPLv2 only and not MIT, what new insane conspiracy would the Rust haters invent this time.
32
u/FriendlyProblem1234 2d ago
I'm curious, considering that Sequoia is licensed under GPLv2 only and not MIT, what new insane conspiracy would the Rust haters invent this time.
It is LGPL-2.0-or-later, which makes it usable with other non-GPL FOSS licenses.
But yes, let us see how creative they get /s
10
u/berryer 2d ago edited 2d ago
Does rust support dynamic linking these days? Last I looked it really didn't, which would make it GPL in practice.
edit with relevant RFC: https://github.com/rust-lang/rfcs/issues/3075
edit2: looks like they actually do support dynamic libraries via the C ABI these days
6
u/FriendlyProblem1234 2d ago
Does rust support dynamic linking these days? Last I looked it really didn't, which would make it GPL in practice.
edit with relevant RFC: https://github.com/rust-lang/rfcs/issues/3075
edit2: looks like they actually do support dynamic libraries via the C ABI these days
It has supported the C ABI since forever, not just "these days".
And I suppose you can satisfy LGPLs licenses even with Rust unstable ABI. You would be able to replace the shared library, you just need to document which compiler was used to build it.
Also, LGPLs work with static linking, too. But it is more cumbersome, so usually nobody takes it into consideration.
1
u/Booty_Bumping 3h ago
LGPL doesn't require dynamic linking, it just requires a way to meaningfully replace the LGPL-protected module, which could mean providing source code under a source-available license (e.g. how the source code of Unreal Engine is available for users to compile, but is under a nonfree license), but could also be accomplished with a small shim to interface the LGPL component with the binary blob.
looks like they actually do support dynamic libraries via the C ABI
Indeed, you can just write a stable C ABI in Rust to make your library work like an ordinary DLL, which is what you'd want to do for a drop-in replacement of a system library. You do have to contend with writing unsafe Rust to do this, but Rust has a nack for making FFI mistakes very obvious to spot and fix defensively.
There is a way to dynamically link purely Rust ABI components, but due to monomorphization the full source code must be available at compile time. It's mostly useful for monolithic software that has loadable modules, to reduce baseline memory use or only have to download the parts of the software you need. Sorta like how the Linux kernel can load modules at runtime, but for sanity sake you want all of the components to be built as one monolith, otherwise you have to match specific kernel versions the way Nvidia, Virtualbox, and v4l2loopback do.
7
u/Perokside 2d ago
The contributors are sockpuppets from the same dev that will "ask" them to forfeit their rights so they can relicense the tool under MIT-or-worse.
PRs from real people are rejected as to not screw the evil plan.
4
u/FriendlyProblem1234 1d ago
The contributors are sockpuppets from the same dev that will "ask" them to forfeit their rights so they can relicense the tool under MIT-or-worse.
The contribution guidelines allow submitting code for which you have only right to relicense under LGPL-2.0-or-later.
Looks like this completely hypothetical scenario (which you even call "evil plan") suits perfectly the definition of a "new insane conspiracy".
Thanks, it was exactly what I was looking forward to /s
PRs from real people are rejected as to not screw the evil plan.
Do you have a link or some other sources about this?
5
u/Perokside 1d ago
it's... it's a joke buddy, a creative conspiracy from Rust haters :')
6
u/FriendlyProblem1234 1d ago
it's... it's a joke buddy, a creative conspiracy from Rust haters :')
Fair enough.
Poe's law is once again right.
4
15
u/maxshanly 2d ago
The line of argument being pushed by the GnuPG developers appears to be that a) GnuPG & thus OpenPGP are feature complete, so there was no need for a new standard and b) the Sequoia developers desire to rewrite twenty odd years worth of code in Rust was shitting on the work of Werner et al. https://gnupg.org/blog/20250117-aheinecke-on-sequoia.html
It's a sad affair, it is a shame it couldn't have been resolved in-house via a /modern/ branch of the codebase being created for a re-implementation in Rust, rather than a complete split into two separate projects that aren't interoperable. At least that way the current stable branch could've been maintained by those who want to keep it developed and the modern branch could've been developed by those interested in a re-implementation, once the /modern/ branch was mature & bug-free then the stable branch could've become /legacy/ and the /modern/ branch the new stable, and everyone involved would be relatively happy.
25
u/FriendlyProblem1234 2d ago
At least that way the current stable branch could've been maintained by those who want to keep it developed and the modern branch could've been developed by those interested in a re-implementation
Is it not exactly what happened, except that the two branches are in different projects?
The line of argument being pushed by the GnuPG developers appears to be that a) GnuPG & thus OpenPGP are feature complete, so there was no need for a new standard
In my experience, the developer experience working with GPG bindings was abysmal in comparison to Sequoia. Given the frequent complains about how nobody is using GPG due to its complexity, I would say the user experience is also abysmal.
Not that it is somehow inherently GPG's fault, which in its defence is a really old piece of software. But the fact remains: it could be made much more pleasant to use, and therefore it is arguably not feature complete.
8
u/maxshanly 2d ago
Is it not exactly what happened, except that the two branches are in different projects?
Yes, but what I am saying is that ideally that would have happened without splitting into different projects.
In my experience, the developer experience working with GPG bindings was abysmal in comparison to Sequoia. Given the frequent complains about how nobody is using GPG due to its complexity, I would say the user experience is also abysmal.
Not that it is somehow inherently GPG's fault, which in its defence is a really old piece of software. But the fact remains: it could be made much more pleasant to use, and therefore it is arguably not feature complete.
I completely agree.
3
u/ThellraAK 2d ago
It's a command line utility, and there are GUI wrappers available.
It's not commonly used because at the end of the day nearly no one cares about the way it offers authentication and security.
3
u/FriendlyProblem1234 2d ago
It's a command line utility, and there are GUI wrappers available.
It's not commonly used because at the end of the day nearly no one cares about the way it offers authentication and security.
Exactly.
So "GnuPG & thus OpenPGP are feature complete, so there was no need for a new standard" is arguably incorrect.
2
u/maxshanly 1d ago
So "GnuPG & thus OpenPGP are feature complete, so there was no need for a new standard" is arguably incorrect.
I agree, but the GnuPG developers are of the opinion that "GnuPG and OpenPGP are extremely mature and basically "done." Minor updates to the protocol were required (e.g., adopting SHA-256), but that would have been sufficient."
1
u/slanterns 8h ago
it's not just "rewrite it by a new language", it indeed a sub-battlefield of the GunPG (librepgp) vs OpenPGP v6 conflict. So I'm afraid that there's no chance to unify them in one project.
-2
u/Junior_Common_9644 2d ago
None. It wasn't rust we hated. It was non-copyleft licensing and insisting on making replacements that are not 100% backwards compatible... not because it couldn't be done, but because they had a need or inclination that changing the options and or behavior was needed.
-7
u/kryptik-thrashnet 2d ago
I dislike Rust as well, actually. It's a clunky mess of a programming language that barely works and serves no purpose whatsoever.
4
2
2
-3
6
u/Jristz 2d ago
I wonder what else is left to move to rust?
13
u/Business_Reindeer910 2d ago
systemd
8
u/lazy_lombax 2d ago
honestly this is the one that absolutely would be great to have a rust rewrite of or an entirely new project that was systemd compatible like systemd-rs (haven't checked but won't be suprised if it already exists)
5
6
u/yawara25 2d ago
Pretty much the entire machine learning ecosystem is all Python still.
15
u/Coffee_Ops 2d ago
Python is memory safe AFAIK, so the only reasons to move off it would be performance.
11
u/yawara25 2d ago
Which most of the performance critical code is in the (non-Python) kernels anyway.
0
u/Altruistic-Check2334 1d ago
Much of the Python ecosystem has been migrating to rust for good reasons. If you haven't noticed there are a number of ai harness tools in rust. Jcode easily builds and runs and behaves as expected not only on x86_64 but also riscv64. Rust via web assembly seems to have replaced Javascript. There is to love about Rust.
5
u/yawara25 1d ago
I'm talking about machine learning in a boarder sense, not just the LLM space. If you want to train a model, you're going to use Python.
7
2
9
-25
u/Due-Departure-8553 2d ago
Good. People who want code to stay in non memory safe languages are like anti vaxxers.
10
4
-24
-23
u/Maybe-monad 2d ago
Are they testing the software they put in their releases,?
42
u/MatchingTurret 2d ago
Sequoia has been around for almost ten years, so one would assume that it has seen some testing.
12
u/AdventurousFly4909 2d ago
yes
-5
0
-33
u/Ruined_Passion_7355 2d ago
This is getting out of hand.
10
135
u/MatchingTurret 2d ago edited 2d ago
Do they mean replacing the GNU Privacy Guard? Because OpenPGP is the name of the standard, afaik. Sequoia-PGP is another implementation of that standard, so it doesn't replace it.