Building with SCIFIO module enabled fails with 'file DOWNLOAD HASH mismatch'

[codeling]

Description

Since a few days, a build with the SCIFIO module enabled fails with:

CMake Error at /workspace/itk/bin-rel-4.13.1/Modules/Remote/SCIFIO/src/DownloadJRE.cmake:13 (file):
  file DOWNLOAD HASH mismatch

    for file: [/workspace/itk/bin-rel-4.13.1/Modules/Remote/SCIFIO/src/jre.tar.bz2]
      expected hash: [4c75412942f7d36c5e8b8fb38ba975bc]
        actual hash: [d41d8cd98f00b204e9800998ecf8427e]
             status: [22;"HTTP response code said error"]

Steps to Reproduce

1. Configure itk with Module_SCIFIO enabled in CMake
2. Build

Expected behavior

The build should run through.

Actual behavior

The build will fail with above error message when downloading the jre.tar.bz2, said file will be empty (0 bytes).

Reproducibility

Always.

Versions

Release version 4.13.1.
The jre.tar.bz2 is the same in 4.13.0 as far as I can tell (see workaround note below) - MD5 hash 4c75412942f7d36c5e8b8fb38ba975bc

Environment

Happens on:

• Ubuntu 18.04 with CMake 3.10.2, clang 6.0
• Debian 7 with CMake 3.8.1, g++ 4.7.2

Additional Information

The actual URL that is used in the download is https://midas3.kitware.com/midas/api/rest?method=midas.bitstream.download&checksum=4c75412942f7d36c5e8b8fb38ba975bc&name=[build-path]/jre.tar.bz2&algorithm=MD5

That URL returns 404 when opened in a browser. For fixing this issue, the jre.tar.bz2 file with the mentioned MD5 hash needs to be be made reachable under that URL again.

As a workaround, a file from a previous build can be copied over into the Modules/Remote/SCIFIO/src directory, then the build will run through. (I had it from a 4.13.0 build, the file has not changed since then apparently).

Side note - information leakage

Is it intentional by the way that this URL includes the full build path in the name parameter? There is no need for the server to know in what folder the user has built ITK; indeed, information about the person building ITK might leak that way. Whatever the intentions behind this name parameter are exactly, I don't think the way this is implemented at the moment is a good idea...

[blowekamp]

This patch should address this issue:
http://review.source.kitware.com/#/c/23780/1

[dzenanz]

I don't think the name matters. It is supposed to give the user's browser a name of the file when it is downloaded. What matters are algorithm and checksum. Name can be empty, I think. Passing the full path was probably an oversight by whoever wrote the script.

[thewtex]

@codeling The patch from @blowekamp is now available in ITK Git master and release-4.13. Please try again with either and let us know how it goes.

[codeling]

Unfortunately I won't have the time to test until mid of November. I would have one question though - and please excuse my ignorance - will (or has) this change result(ed) in an update to the 4.13.0 and 4.13.1 source releases? Or will one have to get a future release (4.13.2) or the source from one of the two mentioned branches to be able to build again?

[dzenanz]

ITK version 4.13.2 is planned to be released. It will be based on release-4.13 branch.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[blowekamp]

I believe this specific issue was addressed in patch: http://review.source.kitware.com/#/c/23780/1 and is available for both 4.13 and 5 branches.

If there are other issues with SCIFIO, please create a new issue.

[codeling]

Sorry for the late reply.
Yes, I can confirm that the build of the release-4.13 branch with SCIFIO module enabled now works again without errors 👍 !