Stream: implementers
Topic: MD5 of specification downloads
Brian Kaney (Dec 16 2019 at 16:30):
Is there a place on the HL7 website (that I am missing) that has MD5 checksums of the specification downloads (http://build.fhir.org/downloads.html)?
Lloyd McKenzie (Dec 16 2019 at 16:51):
Nope. At the moment, we don't do that. Is there a reason you think it's needed?
Brian Kaney (Dec 16 2019 at 18:57):
It would be convenient to validate what version of, say fhir.schema.json.zip was used, as there is no explicit version in the artifact itself.
It is also common to have a checksum to make sure what you download is expected by comparing a published checksum to one you compute after download (hl7.org is not https, so there is a risk of man-in-the-middle)
Lloyd McKenzie (Dec 16 2019 at 21:59):
Our downloads aren't executable, so the risk isn't high. @Grahame Grieve, thoughts?
Grahame Grieve (Dec 16 2019 at 22:04):
if you think there's a risk of mitm, you should switch to secure. If you worry about MITM, providing a non-secure checksum is hardly going to make any difference
Brian Kaney (Dec 17 2019 at 07:42):
True, I actually didn't know https was an option (got too used to secure auto-redirect on many sites). But a checksum would be nice to verify what I downloaded before, since the filenames (of the ZIP files) seem the same across FHIR versions on that page.
Lloyd McKenzie (Dec 17 2019 at 14:27):
Rather than storing the MD5 for each of the files, you'd be better off storing the version number. If that changes, you know the site has shifted to the next version.
Grahame Grieve (Dec 17 2019 at 19:09):
I'll think about a checksum. A bigger problem is corrupt downloads, but I suppose the same people who can't figure their way through that won't be helped by checksums
Chris Moesel (Dec 17 2019 at 19:20):
But a checksum would be nice to verify what I downloaded before
We were actually thinking the same thing in regard to the "current" version for IGs. If there hasn't been a new build since the version that is in the fhir cache, we don't want to download again. Right now, it seems there isn't a great way to make that determination.
Grahame Grieve (Dec 17 2019 at 19:22):
do people actually work like that? what would the workflow look like?
Chris Moesel (Dec 17 2019 at 19:24):
Another way though would be a mechanism / place in the fhir cache to store the ETag corresponding to each cached artifact. That would probably be the more appropriate approach.
Grahame Grieve (Dec 17 2019 at 19:30):
that seems like solving a different problem for me. But it can't be a problem that arises anymore. Currency is not an issue for published packages, and current version currency is assessed using inside knowledge of the build system
Jens Villadsen (Dec 18 2019 at 11:42):
We calculate the MD5 of the package.tgz - if it is different from previous seen package.tgz's, then we publish a new npm/maven artifact containing the IG - but our setup does not rely on HL7 Jenkins job
Jens Villadsen (Dec 18 2019 at 11:43):
and this is only to handle the latest versions for bleeding edge development of the IG ... the other IG versions are tagged and are not needed to continuously evaluate the MD5
Grahame Grieve (Dec 18 2019 at 12:09):
current, the time in the package should match the time in https://build.fhir.org/ig/qas.json
Last updated: Apr 12 2022 at 19:14 UTC
