I thought there might be some kind of hash or signature, but I’m assuming that can be forged along with the main payload?

From the short description in the advisory, would seem like the attacker can cause the tool to overwrite the file after signature verification.

Of course not, Debian is one of the most robust pieces of software around. They wouldn't do something idiotic like relying on the hash being sent with the payload through the same channel.

I think the idea is that debian distributes the hash themselves through their domain, and mirrors offer the downloads either through http or https. So that you don't need to trust the mirror, you just verify the debian given hash. Only weakness would be a hash collision or a cve like this.

AFAIK this isn't actually true for any distribution. This would break selfhosted mirrors and their clients hosted on airgapped networks, and create a single point of failure for users.

The way packages are validated actually is through the same channel as you download the packages themselves from (IE your mirror), they just are signed with the Debian package signing key(ring), of which only a select few maintainers have authorized private keys for.

This does mean an adversary (whether a MITM if you're using HTTP or malicious operator on the mirror server itself) can technically serve you old versions of an (officially signed) package indefinitely and your package manager would be none the wiser, but otherwise this approach actually works quite well.

The signatures do expire (which is an annoyance when working with snapshot.debian.org).

An attacker might replace a package with a previous one which has a vulnerability. Downgrade attack. Unclear if the apt client will check if version is the expected one after requesting a package.

Despite with the 'no need for TLS, apt packages are signed' clowns would have you believe, you can usually point to a package mirror with https. This has the added advantage of preventing a mitm from knowing what packages you install or blocking selected packages.

Every mirror will know that because of HTTPD logs.

In fairness to GP, that wouldn't be a man in the 'middle', the mirror is the end destination for your traffic.

well when CA use 4 as key that kinda matters less

They usually don't.

But sometimes do

What's the argument then? Not signing the packages anymore because that has now been faulty?

There's no sensible argument here.

That’s not very typical, I’d like to make that point.

So you're not using internet banking any more?

> preventing a mitm from knowing what packages you install

Package size is unique enough that just seeing the size of the transfer will usually be enough to tell.

Apt uses persistent connections and has multiple requests in flight at once (Acquire::http::Pipeline-Depth). If you acquired the entire history of downloads then you could match it against software updates, and possibly identify by-choice dependency sets, but it would be quite a project.

> Updates for the affected Debian, Debian LTS, Debian eLTS, Ubuntu, and Ubuntu Pro channels are being released. > > An update for apt 1.0.1ubuntu2.24 has been made available to Ubuntu Pro customers running Ubuntu "trusty" through the Ubuntu Pro subscription service, and a 3.3.3ubuntu0.1 for stonking.

From the original disclosure: https://lists.debian.org/deity/2026/11/msg00005.html

For context, Ubuntu trusty and apt 1.0.1 is from 2014.

Ubuntu is affected.