sparskit @2: checksum mismatch

[ryandesign (Ryan Carsten Schmidt)]

We last mirrored distfiles for sparskit back in 2015:

$ curl -IL https://distfiles.macports.org/sparskit/SPARSKIT2.tar.gz
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 1172672
Server: Apache/2.4
Last-Modified: Sun, 30 Aug 2015 14:33:02 GMT
ETag: "11e4c0-51e8831b6c380"
Cache-Control: max-age=2592000, public
Content-Type: application/x-gzip
Via: 1.1 varnish, 1.1 varnish
Accept-Ranges: bytes
Date: Tue, 11 May 2021 15:12:50 GMT
Age: 29512
X-Served-By: cache-fra19123-FRA, cache-dfw18626-DFW
X-Cache: HIT, HIT
X-Cache-Hits: 1, 1
X-Timer: S1620745970.150409,VS0,VE2

But the upstream file is unversioned and was last updated in 2019:

$ curl -IL https://www-users.cs.umn.edu/~saad/software/SPARSKIT/SPARSKIT2.tar.gz
HTTP/1.1 200 OK
Date: Tue, 11 May 2021 15:12:30 GMT
Server: Apache
Last-Modified: Mon, 10 Jun 2019 16:17:08 GMT
ETag: "13a511-58afa8311a1b1"
Accept-Ranges: bytes
Content-Length: 1287441
Content-Type: application/x-gzip

Therefore, if the user happens to fetch from upstream instead of our mirror, ​a checksum mismatch occurs:

--->  Checksumming SPARSKIT2.tar.gz
DEBUG: Calculated (rmd160) is 77a75cd20678b190814084c28e4b72533210e9cd
Error: Checksum (rmd160) mismatch for SPARSKIT2.tar.gz
Portfile checksum: SPARSKIT2.tar.gz rmd160 95554593896300d7823f40956a428e8e7c57bb78
Distfile checksum: SPARSKIT2.tar.gz rmd160 77a75cd20678b190814084c28e4b72533210e9cd
DEBUG: Calculated (sha256) is ecdd0a9968d6b45153a328710a42fe87600f0bba0e3c53896090b8ae1c113b7a
Error: Checksum (sha256) mismatch for SPARSKIT2.tar.gz
Portfile checksum: SPARSKIT2.tar.gz sha256 b355ab934860d345a60d9961e456b0fc2e7681ba9a8c7c3b42c7bf6ff28e34af
Distfile checksum: SPARSKIT2.tar.gz sha256 ecdd0a9968d6b45153a328710a42fe87600f0bba0e3c53896090b8ae1c113b7a
DEBUG: Calculated (size) is 1287441
Error: Checksum (size) mismatch for SPARSKIT2.tar.gz
Portfile checksum: SPARSKIT2.tar.gz size 1172672
Distfile checksum: SPARSKIT2.tar.gz size 1287441
The correct checksum line may be:
checksums           rmd160  77a75cd20678b190814084c28e4b72533210e9cd \
                    sha256  ecdd0a9968d6b45153a328710a42fe87600f0bba0e3c53896090b8ae1c113b7a \
                    size    1287441

The port should presumably be updated to the latest upstream version. The unversioned distfile recipe should be followed. The version number of the port should be amended accordingly.

The upstream web site enforces https so the homepage in the portfile should be updated to match.

On High Sierra I am unable to connect to their web server with macOS curl:

$ /usr/bin/curl -I https://www-users.cs.umn.edu/~saad/software/SPARSKIT/
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.
HTTPS-proxy has similar options --proxy-cacert and --proxy-insecure.

It works fine with MacPorts curl:

$ /opt/local/bin/curl -I https://www-users.cs.umn.edu/~saad/software/SPARSKIT/
HTTP/1.1 200 OK
Date: Tue, 11 May 2021 15:17:14 GMT
Server: Apache
Last-Modified: Mon, 10 Jun 2019 16:17:08 GMT
ETag: "679-58afa83085518"
Accept-Ranges: bytes
Content-Length: 1657
Vary: Accept-Encoding
Content-Type: text/html

Still, this probably means there is a mistake in their TSL configuration that they will need to resolve if we are to be able to mirror the new distfile after you update the port

[dstrubbe (David Strubbe)]

Hello Ryan, the fetch phase works fine for me. If I update the version of the port, would I just make up some derivative of version 2 like "2_2019"?

[dstrubbe (David Strubbe)]

I have reported the configuration issue to the developer.

[ryandesign (Ryan Carsten Schmidt)]

Replying to dstrubbe:

Hello Ryan, the fetch phase works fine for me.

If you're on a newer macOS, I'm not surprised it works. It worked for the Big Sur arm64 buildbot worker above too. But it did not work for me on High Sierra. The machine that does our distfile mirroring runs El Capitan, so I suspect it will also be affected by the problem.

An ​SSL/TLS testing web site shows that the problem is that the intermediate certificates that the server is delivering for "USERTrust RSA Certification Authority" and "AddTrust External CA Root" expired May 30, 2020. This problem may not affect newer OS versions that already have newer versions of those CA certificates in their OS-provided CA bundle.

If I update the version of the port, would I just make up some derivative of version 2 like "2_2019"?

I tend to add a "-YYYYMMDD" suffix (e.g. "2-20190610") when I update such port, if upstream doesn't otherwise assign separate version numbers to their releases.

[dstrubbe (David Strubbe)]

I have managed to fix some things and get this new version to build properly. Do I need to wait to commit until the website certificate issue is fixed?

[ryandesign (Ryan Carsten Schmidt)]

Feel free to commit it now and I can manually mirror the distfile.

[dstrubbe (David Strubbe)]

Fixed in [1e2d1313a591b04ba5c60510563abf8836b5eac7/macports-ports]

[dstrubbe (David Strubbe)]

Ryan, according to the TLS check website, it seems they have a non-expired certificate now. Can you check if it works now on High Sierra?

[ryandesign (Ryan Carsten Schmidt)]

No, the certificate is still expired. You can verify this using a web-based checker like the comprehensive one I posted earlier or this simpler one:

​https://whatsmychaincert.com/?www-users.cs.umn.edu