So the https://www.openssl.org/source/openssl-1.0.2t.tar.gz.sha256 file still has the issue. All the other files from the main download page are OK Carl -----Original Message----- From: Richard Levitte [mailto:levitte@xxxxxxxxxxx] Sent: Wednesday, September 11, 2019 4:41 PM To: Carl Tietjen <Carl.Tietjen@xxxxxxxxxxxxxx> Cc: Richard Levitte <levitte@xxxxxxxxxxx>; Michael Wojcik <Michael.Wojcik@xxxxxxxxxxxxxx>; Matt Caswell <matt@xxxxxxxxxxx>; openssl-users@xxxxxxxxxxx Subject: Re: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc Thanks for the heads up. For some reason, the information at our CDN remained incorrect for the "BAD" files, so I purged all the current release files there, so their cache for them would rebuild from scratch. They look better now. Cheers, Richard On Thu, 12 Sep 2019 00:25:40 +0200, Carl Tietjen wrote: > > > 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:levitte@xxxxxxxxxxx] > Sent: Wednesday, September 11, 2019 2:41 PM > To: Michael Wojcik <Michael.Wojcik@xxxxxxxxxxxxxx> > Cc: Carl Tietjen <Carl.Tietjen@xxxxxxxxxxxxxx>; Matt Caswell > <matt@xxxxxxxxxxx>; openssl-users@xxxxxxxxxxx > 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 <matt@xxxxxxxxxxx>" [full] > > > gpg: aka "Matt Caswell <frodo@xxxxxxxxxxx>" [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 levitte@xxxxxxxxxxx > > OpenSSL Project http://www.openssl.org/~levitte/ > > -- Richard Levitte levitte@xxxxxxxxxxx OpenSSL Project http://www.openssl.org/~levitte/
