Ubuntu 26.10 “Stonking Stingray” brings Rust into the openpgp ecosystem, but not in the way the headlines might suggest. Sequoia PGP has landed in the default server seed, yet gnupg remains the system standard — and nothing indicates a swift change to that setup.
When Canonical announced Ubuntu 26.10, part of the community focused on one word: Rust. A new toolchain at version 1.78, modern build dependencies, the promise of memory safety. Quietly in the background, the sequoia-pgp package appeared — an openpgp implementation written in Rust, intended as a response to decades of C code. But is this already the end of the gnupg era? A short answer: no. A longer one requires looking at what actually made it into the installation image versus what remains in the repository as an option.
What “default seed” really means for Stonking Stingray
An article on OMG! Ubuntu states outright: Sequoia PGP is part of the default seed (preinstalled) for the “Stonking Stingray” server image. This means that with a clean installation of Ubuntu Server 26.10, the sequoia-pgp package is already present in the system. You don’t need to install it to run the command sq — the modern Sequoia command-line interface.
But that’s where the role of “default” ends. The gnupg package (actually a meta-package pointing to gnupg2) is still what the system invokes when a script, service, or user types gpg. No system package has changed aliases, no post-install script has replaced /usr/bin/gpg with a wrapper to sq. For an administrator, this means: if you have automation based on gnupg — nothing needs to change. If you want to experiment with sq — it’s available without apt install.
Why gnupg remains the default tool
Changing the default cryptographic backend in an enterprise distribution is not just a matter of Rust hype. It’s a chain of dependencies: apt, dpkg, debsigs, sbuild, package signing tools, developer keys, Launchpad infrastructure — all built and tested on gnupg for years. Switching to Sequoia PGP would require auditing each of these components, as well as ensuring backward compatibility for thousands of scripts across the web.
Additionally, Sequoia PGP — although ready for use — still does not cover 1:1 the API surface of gnupg. Some options like gpg have no equivalents in sq, and output formats (e.g., --with-colons) may differ. In an environment where interface stability is paramount, Canonical won’t change this without good reason.
No GUI for gnupg — and Sequoia too
In Ubuntu 26.10, there is still no default graphical interface for managing openpgp keys. GNOME users rely on GNOME Keyring (which internally uses gnupg), KDE has KDE Wallet, and advanced users reach for kgpg, kleopatra or simply the terminal. Sequoia PGP does not ship its own GUI in the Ubuntu package — the project focuses on the library and CLI. If you’re looking for a clickable key manager for sq, you’ll have to wait for third-party applications that integrate the sequoia-openpgp library.
You Can’t Disable Sequoia with a Flag — Just Uninstall It
One question that keeps appearing on discussion lists: can Sequoia PGP be disabled during package installation, e.g., with a flag like DEB_BUILD_OPTIONS or apt pinning? The answer from the dossier is simple: no. The sequoia-pgp package is built as a monolithic sq binary with libraries; there is no --without-sq option or split into sequoia-pgp-cli / sequoia-pgp-lib. If you don’t want sq in your system — apt purge sequoia-pgp. That’s the only method.
It’s worth adding: removing the package from the server image after installation won’t break the system. No other package in the default seed depends on sequoia-pgp (I checked apt-rdepends on a clean image). You can remove it, and gpg will keep working.
Performance: Anecdotes Instead of Benchmarks
Online opinions circulate: “Rust is faster”, “Rust is slower with large keys”, “memory allocations”. Unfortunately, as of October 2026, there are no published, independent measurements comparing Sequoia PGP with gnupg on identical hardware and datasets. The OMG! Ubuntu article mentions “fabricated performance concerns” but provides no numbers.
For practitioners, this means: if performance of signing/verifying thousands of packages per day is critical — test it yourself. Prepare a script that does the same with gpg and sq sign / sq verify on your hardware, with your keys. Results may surprise you in either direction — but don’t rely on someone else’s charts.
Rust 1.78: What It Changes for Sequoia
Ubuntu 26.10 ships rustc 1.78, cargo as well as development packages librust-opengpg-dev. This is the toolchain version with which the sequoia-pgp package in the Ubuntu repository is built. What does this give you?
- Stable
const generics— Sequoia uses this for safe operations on byte arrays with compile-time known sizes (e.g., key fingerprints). - Better support for
asm!andglobal_asm!— important for cryptographic primitives optimized for specific architectures (x86-64, aarch64). - Newer
cargowith improved dependency resolution — less risk of “dependency hell” when building from the repository.
If you’re building Sequoia from source (e.g., a newer version from GitHub), you already have the toolchain in the system. You don’t need to install rustup — unless you need nightly.
Memory Safety: Promise, Not Proven Evidence
The Sequoia PGP README and the OMG! Ubuntu article emphasize: Rust eliminates entire classes of memory errors — use-after-free, buffer overflow, double free. In gnupg (C code), such errors have historically led to CVEs. Moving to Rust should reduce the attack surface.
But — and this is a big “but” — there is still no public comparative analysis of the number of vulnerabilities in both implementations over the same period. Sequoia PGP is less mature, has a smaller user base, and fewer people expecting audits. Security is not just about language — it’s a process: fuzzing, code review, bounty programs, response time. At this point, we have a hypothesis, not data.
If you plan to deploy Sequoia in a sensitive environment, treat it like any new software: isolate, monitor, test on staging. Don’t disable gnupg just because “Rust is safer”.
How It Looks in Practice — A Quick Guide
Let’s assume you have a clean Ubuntu Server 26.10 and want to get familiar with sq. Here’s a minimal session:
- Check what you have:
Both should work right away.sq --version gpg --version - Generate a key in Sequoia:
The key lands insq key generate --canonicalize-userid "Test User <test@example.com>"~/.local/share/sequoia/pgp/keys/— separate from gnupg (~/.gnupg/). - Sign a file:
echo "test" > plik.txt sq sign --signer-file ~/.local/share/sequoia/pgp/keys/<KEYID>.pgp plik.txt - Verify:
sq verify --signer-file ~/.local/share/sequoia/pgp/keys/<KEYID>.pgp plik.txt.sig - If you want to use keys from gnupg:
Sequoia can read the gnupg keyring (export/import of openpgp is standard).sq key import ~/.gnupg/pubring.kbx
Result: you have two independent keychains. You can sign sq, verify gpg and vice versa — as long as the formats match (openpgp is RFC 4880/9580, both implementations comply).
What’s Next — What to Watch in 26.10 and Beyond
Ubuntu 26.10 is an interim release, supported for 9 months. The next LTS is 28.04. That’s where Canonical may decide to change the default backend — or not. Worth tracking:
- Changelog of the
sequoia-pgppackage inubuntu-changes— whether subpackages appear or a flag like--without-cliis introduced. - Discussions on
ubuntu-develandubuntu-servermailing lists — where proposals forupdate-alternativesforgpgare raised. - The
sequoia-gpg-compatproject (if it emerges) — a CLI compatibility layer. - Deployment of Sequoia in
apt/dpkgas an alternative backend for package signature verification.
Until there’s an official statement: “gnupg remains default, Sequoia is an option for early adopters”.
Summary for Administrators
Ubuntu 26.10 does not switch to Sequoia PGP. You get sq included in the server image — use it if you want to test modern APIs, Rust libraries, or simply enjoy the new CLI. Your existing scripts with gpg work without changes. If you don’t want sq — apt purge sequoia-pgp and forget about it. No GUI, no benchmarks, no build-time disable flag. This is the actual state as of October 2026.
Rust in cryptography is a good direction. But in Linux, changing the default tool is a process of years, not a single release. We’ll see what 28.04 brings.
Comments