Still seeing the issue for SOME of the SHA256 files... I waited for a while thinking it might be a cache issue, but no change.
https://www.openssl.org/source/openssl-1.0.2t.tar.gz.sha256 -- BAD https://www.openssl.org/source/openssl-1.1.0l.tar.gz.sha256 -- OK https://www.openssl.org/source/openssl-1.1.1d.tar.gz.sha256 -- BAD https://www.openssl.org/source/openssl-fips-2.0.16.tar.gz.sha256 -- OK https://www.openssl.org/source/openssl-fips-ecp-2.0.16.tar.gz.sha256 -- OK -----Original Message----- From: Richard Levitte [mailto:levi...@openssl.org] Sent: Wednesday, September 11, 2019 2:41 PM To: Michael Wojcik <michael.woj...@microfocus.com> Cc: Carl Tietjen <carl.tiet...@microfocus.com>; Matt Caswell <m...@openssl.org>; openssl-users@openssl.org Subject: Re: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc 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<mailto:m...@openssl.org>>" [full] > gpg: aka "Matt Caswell > <fr...@baggins.org<mailto: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<mailto:levi...@openssl.org> OpenSSL Project http://www.openssl.org/~levitte/
