qupath
Please consider posting hash information for .msi and standalone .exe
Organizations who would like to use your tool might want to verify the binaries you distribute are not being tampered with in transet. One easy way to make that easy (as opposed to have such organizations build your tool from scratch) would be to publish the binaries with MD5/SHA1 hashes on the releases page.
You would make the life of IT employees in such organizations a whole lot easier!
Thanks,
Kris
One easy way
Do you have any advice on how to streamline that, while using GitHub releases?
I recently found resources like this:
Release hash: https://github.com/MCJack123/ghaction-Generate-Release-Hashes
Release signing: https://wiki.debian.org/Creating%20signed%20GitHub%20releases (which equally allows one to verify a given download)
Is an sha256 hash available for the current Qupath (0.3.2) release? (specifically the windows distribution?)
@mezwick Hashes aren't currently generated or made available.
Making a release remains a fairly laborious and manual process. Although the builds themselves are now generated automatically using GitHub Actions, I have to download and check these run on each platform and then upload again. And write all the release notes, tag the version etc. There can also be some extra renaming required, since jpackage (used for the build) has some awkwardness connected to artefact naming and 0.x.x versions that affects some platforms but not others (e.g. I think macOS forbids 0.x.x versions, so this needs worked around; also, it needs to be possible for people to have multiple versions installed for reproducibility).
It's already a real pain to do, and I don't want to add any more manual steps if I can avoid it.
It would be strongly preferable to automate the whole process a bit more, using Upload to Release to avoid the download/upload requirement, and somehow include hashes (e.g. using the links from @KrisJanssen's last post) at that point.
This seems to me at least a bit awkward to set up though, since the upload action is only triggered when a release is made. The build workflow would have to be quite a bit more complex (e.g. to handle cross-platform filenames/content types for the builds, as well as different artefact compression methods). I'd also still need to retain the ability to check the release manually on each platform before the release itself is created, because creating the release is what triggers any update notifications... and after the release has been tagged is a bad time to identify some platform-specific breakage. These tend to happen with every release, e.g. because some dialog ends up misbehaving on Ubuntu but looks fine everywhere else.
I strongly suspect I'd mess it up quite a few times before (hopefully) getting it right, and potentially make several 'accidental' releases along the way... confusing the version numbering.
Therefore while I'd like to be able to explore this before the next release, but there's a very strong chance I won't have time to set up or debug the whole pipeline.
If anyone else wants to work on improving the workflow, and contending with its messiness by checking the proposed solution really does work properly on all platforms, suggestions or PR's welcome!
Sidenote: A related concern is that I've been asked several times for signed distributions. Much as I like the idea, I don't really like the associated admin (the cost doesn't help either)...
@petebankhead : I can certainly understand you need to carefully balance workload. As our organization is somewhat rigorous regarding this topic I have looked into things further and it seems you mercifully use an accessible installer solution and as such I have been able to build it from source in full.
This way, we can perform static code review and use an internally built binary, currently removing the need to obtain the hash from you.