Anyone who uses the BitShares client is trusting their money to the maintainers' cryptography skills.
Signing releases with MD5 does not inspire confidence in those skills.
For security, it is necessary to use an up-to-date hash algorithm like sha256sum. MD5 is insecure; it has a history of published vulnerabilities and successful practical collision attacks.
Using an up-to-date algorithm is not sufficient to guarantee security. An attacker with the capability to replace the binary download with a malicious file would also be able to replace the hash. The hash MUST be signed with a trusted public key!
Here is how releases should be signed:
$ sha256sum BitSharesX-0.4.18-x64.exe | tee BitSharesX-0.4.18-x64.exe.sha256sum
>>> wallet_sign_hash drltc "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
Then publish the two hex values above. (For convenience, we put the first number in a file.) To check, you can run:
$ sha256sum -c BitSharesX-0.4.18-x64.exe.sha256sum
>>> blockchain_verify_signature drltc "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" "20db75781b52d8830b1eb080fc0f130bce8ce76d0cf1b04a4a00a589404085675b2afc812c9847d1656e0504b6bc0a33f2a4f62671a585c1eec6b5f65cb7ef4b1d"
Note, "drltc" in the above commands should be replaced with the name of the DACsunlimited release signing account (it is an implementation detail whether to use the main DACsunlimited account for this, or a dedicated sub-account).
The second step is necessary -- an adversary offering a malicious download can compute their own hash, but cannot produce a signature for the malicious hash without access to the private key of the DACsunlimited signing account. Which can be more thoroughly secured than access to the DACsunlimited Github account (e.g. cold storage). I was going to post this last night, but I noticed that you can't actually do the last step with the current client version because there is no blockchain_verify_signature command. I fixed it in this pull request: https://github.com/BitShares/bitshares_toolkit/pull/822
We should also work on making builds reproducible, so anyone can verify that the released executable was generated from the published source code without any malicious modifications. But this will likely need more than a single Saturday evening of development time.