This is my best guess on what's happening based on the limited information linked.

1) Apt downloads first package (unmodified)

2) apt checks signature -> signature checked and remembered as valid

3) apt downloads second package, http redirect to the same url as package 1

4) the second package overwrite first one due to sharing URL. The temporary storage name or download cache key is derived from URL.

5) signature for package 2 fails but first one (already overwritten by bad one) is still considered good

6) Package 1 gets executed because the signature check already passed in step 2

Note sure where exactly resuming an HTTP download fits in. Maybe step 4 also requires pausing and resuming the update process. Which could involve some state serialization/deserialization vulnerable to conflicting URL confusion.

based only on the wording in the notice:

> APT can merge two different package downloads after an HTTP redirect gives them the same URI

It sounds like the verification is ran but there is some deduplication or caching involved keyed on the destination of the url redirect, not the original source.

So could imagine a malicious server that:

Responds for a request for foo.deb with a redirect to evil.deb containing the original foo.deb. This validates properly.

Responds with a second request for bar.deb with a redirect again to evil.deb that now returns a malicious package. The downloading code thinks it has already validated evil.deb