Thanks for the run down John, I see your point. I’ll use the Github/gnucash.org hashes from now on. I had heard SourceForge was sketchy a while back and I agree one can’t be too careful.
Regards, Adrien > On May 9, 2018, at 8:58 AM, John Ralls <jra...@ceridwen.us> wrote: > > > >> On May 8, 2018, at 8:42 PM, Adrien Monteleone >> <adrien.montele...@lusfiber.net> wrote: >> >> Thanks John, >> >> I knew they were there. I only pointed her to SourceForge because she’d been >> there already. >> >> I should have also pointed out the announcement thread and/or the posting of >> the announcement directly on the GnuCash site. There’s always more than one >> way to tackle something. >> >> Since you brought it up, I know you’re really good about syncing info, but >> is there a ‘best place’ to pull the hashes from, just in case one source >> might be errant? And, not that you need to, but I know some publishers >> (Canonical comes to mind) also publish a hash file with a gpg signature. If >> you do that somewhere, certainly, that would be the first stop for users to >> make. >> >> --------- >> >> I see also on SourceForge that the ‘i’ button-link on the right of that >> screen (if you have JavaScript active) shows the sha1 and md5 hashes for >> each file which is also an option for anyone interested. >> >> As well, there are more methods than the one I listed in my reply on how to >> verify. (with MacOs in particular there is also the ‘shasum’ command.) >> Personally, I use a download plugin for Firefox (Downthemall) that offers >> the option to input the hash, specify the algorithm, and it verifies when >> the download is done. >> >> If you’re downloading via torrent, the Transmission client (as I’m sure >> others) also offers a verification option, though I’ve yet to figure out how >> it does it since I don’t specify the hash file or sequence. (perhaps the >> hash is referenced by the torrent file itself?) > > Adrien, > > Since it’s a manual process I’m no more likely to screw up one place than > another. I do try to fix any mistakes on all three as soon as someone > notices. The exception is the email, which is immutable, so I’d suggest not > looking there. > > SourceForge has been accused in the past of changing downloads, which is why > we started hashing them a couple of years ago. They say they’ve stopped, but > if they ever start up again the hashes they generate would be for their > version of the file while the one in README is created when I upload the > file. Of course they could easily change that too, but then it wouldn’t match > the ones on Github and www.gnucash.org. > > Would a GPG-signed hash file still display on SourceForge and would it > somehow fail to display if it was altered and the signature invalidated? > Unless that’s the case ISTM having the hashes incorporated into the release > announcements affords better assurance. > > Regards, > John Ralls _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
