3 ms·

Even though the packages are signed cryptographically, there are possible risks when using an unencrypted connection. A man-in-the-middle attack could simply w

Even though the packages are signed cryptographically, there are possible risks when using an unencrypted connection. 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.

niea_11 8y ago
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_Valid-Until https://wiki.debian.org/DebianRepository/Format#Date.2C_Vali...
- julian-klode 8y ago
  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 ;)
philjohn 8y ago
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.
- na412 8y ago
  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.
  - JdeBP 8y ago
    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. * https://unix.stackexchange.com/a/332441/5132 https://unix.stackexchange.com/a/332441/5132

niea_11 8y ago

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_Valid-Until https://wiki.debian.org/DebianRepository/Format#Date.2C_Vali...

julian-klode 8y ago
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 ;)

philjohn 8y ago

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.

na412 8y ago
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.
- JdeBP 8y ago
  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. * https://unix.stackexchange.com/a/332441/5132 https://unix.stackexchange.com/a/332441/5132