On Wed, Apr 11, 2018 at 10:44:28PM +0200, Peter J. Philipp wrote:
| On Wed, Apr 11, 2018 at 10:20:37PM +0200, Paul de Weerd wrote:
| > ftp doesn't do this itself, but the error detection in tcp and ssl
| > (ok, so that's linked into the ftp binary) do.
| >
| > The file is unlikely to have been changed in flight.
|
| OK, odd. What I find odd is that the SHA256.sig file I got (which
| was downloaded after the .iso) differs from the very first time I
| made contact with ftp.eu today with the SHA256.sig that I downloaded
| to verify. Could this be an atomicity thing with the FTP mirror?
So you start your download of the ISO while the mirror is in the
process of updating from upstream. The download takes some time,
maybe five minutes (which would be ~1MB/s). In the mean time the
mirror finishes its update to the latest snap (probably using rsync's
--delay-updates flag), but it keeps sending you the file that was just
deleted (your download is "atomic"). Then you download the (new)
SHA256.sig.
Then the ISO will be from an older snap and it will fail verification.
Snapshots are produced so often (since I started keeping a backlog of
old kernels back in 2011, I've seen 18 days with 4 amd64 snaps *from
the same day*, 170 days with 3 amd64 snaps... I update 4 times a day)
that this is actually not an unlikely scenario.
I think this is what happened to you. The only way I can think of to
guard against this is by downloading the .sig file twice, both before
and after downloading other files. If they're different, you hit this
corner case.
Sorry, no big conspiracy where 3-letter agencies are trying to
sabotage the installs of our favorite OS ;-) Your checking of the
signify signature and the SHA256 checksum does help to detect such
sabotage, but it's still not very likely.
Cheers,
Paul 'WEiRD' de Weerd
--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
