The website mentions this towards the end (Replay attacks) : To mitigate this problem, APT archives includes a timestamp after which all the files are considered stale
The time stamp is described here[1], but it is not clear how the expiration date is decided.
1: https://wiki.debian.org/DebianRepository/Format#Date.2C_Vali...
Re:Why does APT not use HTTPS?
by julian-klode on Monday January 21, 2019 @05:06AM
(#18959196)
Well, defining the expiration date is up to the server. Debian picks a week. Ubuntu does not use it, I have started a launchpad branch last year, but um, I don't know launchpad, so it might take some more years ;)
They cover this - timestamps are embedded in the packages, and also signed. If they're too old it won't update and you'll know something is amiss.
More precisely, an expiration timestamp is embedded in the repository metadata.
Packages in debian and derivatives are not signed. Instead, the manifest that lists all the available packages and their checksums is signed. That's also where the expiration data is stored.
Even more precisely still, not even the lists of packages are signed. Only InRelease and Release are signed, and they only contain the list of Package files. It's FreeBSD that has the approach of just one signed file containing everything. APT has moved closer to it over the years, but it is not there yet.
A man-in-the-middle attack could simply work by serving you a signed, but outdated packages list, preventing your distribution from updating and leaving you vulnerable to security holes. It's the same attack an evil mirror could do as well.
So if you want to be really sure you should probably use two independent mirrors over an HTTPS connection.