APT 3.3.5 Released: Faster Solver and Signed-By Key Changes

Debian’s package manager has a new release. APT 3.3.5 came out on October 28, 2026, with a faster dependency solver and changes to how repository signing keys are declared. The speed-up is welcome, but if your servers pull packages from third-party repositories such as Docker, PostgreSQL, Node.js or a monitoring vendor, the signing-key changes deserve more of your attention. This post covers what changed, when you are likely to see it, and how to get your repository definitions ready.

What is new in APT 3.3.5

The main improvement is in dependency resolution. The APT developers report that the solver is now 10 to 20 percent faster and causes 65 percent fewer page faults. Keep in mind that this covers only the step where APT works out what to install, upgrade or remove. Downloading and unpacking packages takes as long as before. You will notice the gain most on large upgrades, on installs that pull in long dependency chains, and in CI pipelines and container builds that call APT over and over.

Other changes in this release:

• SAT solver split out: the core of the SAT-based solver now lives in its own component, which should make it easier to maintain and test.
• Consistent package removals: APT now handles removals of unprotected packages the same way in its internal solver and its API. Previously the two could disagree.
• Better performance data: new counters record stalled CPU cycles, data TLB activity, page faults and scheduling events, and a new perf-eval.py script helps developers analyse these logs.
• Smaller fixes: AC adapter detection on Debian, bounded parsing of build-profile restrictions, test fixes for big-endian architectures, and corrected wording around GPG and OpenPGP.

The Signed-By changes: what admins should care about

The Signed-By option ties a repository to one specific key or keyring. This stops a key you trusted for one vendor from being accepted for packages from another repository. APT 3.3.5 changes it in two ways:

1. Key fingerprints in Signed-By are deprecated. APT is moving towards Signed-By naming a keyring file directly, rather than a fingerprint that points to a key stored elsewhere.
2. Signed-By in repository Release files is no longer supported. A repository can no longer declare its own signing key in its Release file. The key must be set on your side, in the source definition.

Most administrators who added repositories using current vendor instructions already point Signed-By at a file in /etc/apt/keyrings/ or /usr/share/keyrings/, and they have nothing to change. Older setups, hand-written source files and some automation templates are the ones to check. Because fingerprints are deprecated rather than removed, they should keep working for now. Treat this release as advance notice and clean them up before a future APT version stops accepting them.

Find your current Signed-By entries

grep -rn 'Signed-By' /etc/apt/sources.list /etc/apt/sources.list.d/

Each value should be a file path. If you see a long hexadecimal string instead, that entry uses a fingerprint and should be converted.

Switch to a keyring file

Download the vendor’s public key from their official installation instructions and store it as a dedicated keyring:

sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://repo.example.com/key.asc | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg
gpg --show-keys /etc/apt/keyrings/example.gpg

Check that the fingerprint shown matches the one the vendor publishes. Then point the source at the file. In the deb822 format used by current Debian and Ubuntu releases, /etc/apt/sources.list.d/example.sources looks like this:

Types: deb
URIs: https://repo.example.com/debian
Suites: stable
Components: main
Signed-By: /etc/apt/keyrings/example.gpg

Run sudo apt update and confirm the repository loads without signature errors before you move on to the next server.

When will you get APT 3.3.5?

For now, APT 3.3.5 is only in Debian unstable (sid). Debian stable and Ubuntu releases keep the APT version they shipped with, so normal updates will not install it on your production servers. You can check what you have with:

apt --version

To try the new version without touching a real system, use a throwaway sid container:

docker run --rm -it debian:sid bash
apt update && apt --version

Never pull APT from sid onto a stable or Ubuntu server. Mixing suites like this is a common way to end up with a broken package database. Expect these changes to reach future Debian and Ubuntu releases through the normal release process instead.

A short checklist

1. Run apt --version across your fleet so you know which versions you are running.
2. Audit Signed-By entries on every server and in your configuration management templates (Ansible, Puppet, cloud-init, Dockerfiles).
3. Replace fingerprints with keyring file paths and verify each key’s fingerprint against the vendor’s documentation.
4. Move each third-party key into its own keyring file rather than a shared trusted keyring.
5. Test your provisioning scripts against a debian:sid container to catch problems early.

How TechProvidence can help

TechProvidence manages Debian and Ubuntu servers for businesses of every size. We can audit your repository and key configuration, update your automation, and plan distribution upgrades so changes like this never cause a failed deployment. If you would like a hand, contact us.

Source: Linuxiac