Issue found... Apache detected .gz in the file name and set the encoding to 'application/x-gzip'... Apparently, we already force .asc and .sha1 files to application/binary, but have apparently not added a similar directive for .sha256 files.
Now done. Cheers, Richard On Wed, 11 Sep 2019 22:04:53 +0200, Michael Wojcik wrote: > > I can confirm Carl's issue when I download using Pale Moon (a Firefox fork): > > ----- > $ file openssl-1.1.1d.tar.gz.sha256 > openssl-1.1.1d.tar.gz.sha256: gzip compressed data, from FAT filesystem > (MS-DOS, > OS/2, NT) > > $ file openssl-1.1.1d.tar.gz.sha1 > openssl-1.1.1d.tar.gz.sha1: ASCII text > > $ file openssl-1.1.1d.tar.gz.asc > openssl-1.1.1d.tar.gz.asc: PGP signature Signature (old) > > $ gpg --verify openssl-1.1.1d.tar.gz.asc openssl-1.1.1d.tar.gz > gpg: Signature made 09/10/19 09:13:14 EDT using RSA key ID 0E604491 > gpg: Good signature from "Matt Caswell <m...@openssl.org>" [full] > gpg: aka "Matt Caswell <fr...@baggins.org>" [full] > ----- > > So the .sha1 file and the signature look fine, but the .sha256 file is > apparently a fragment of gzip-compressed data. And ... let's see ... > gunzip'ing it gives us the SHA256 hash in ASCII. So my guess the server is > gzip'ing it (or it's gzip'ed at rest on the server), but the server isn't > setting the content-transfer-encoding correctly. Chrome might be > content-sniffing and decompressing based on that. I haven't looked at the > response headers though. > > (Personally, I always check the signature and don't bother with the posted > hashes.) > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
