Re: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux