You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there's no way of checking if an official file was downloaded or a malicious one. Checksums help with that. Since the files are on 3rd party server (bintray.com), it would make sense to provide the checksums on easymock.org in plaintext. This way even if bintray.com is compromised, users who verify the files would know not to use them and to report that.
Adding the same checksums to GitHub as well would enhance the security even more. Then, if either GitHub, easymock's GitHub account or easymock.org is compromised, people would still be able to realize that. So people who download files from GitHub would check the checksum from easymock.org and the other way. I'd put the checksums in plaintext (instead of files) in each release description for easy copy.
As for which checksums should be used, I'd recommend both SHA256 and SHA512. For MD5, it's theoretically possible to do a preimage attack, so it's not the best idea to use it. For SHA1, Google were able to create 2 different files that give the same SHA1. SHA256 might be provided in plaintext and SHA512 displayed after clicking a link (as it's longer and might break the page).
The text was updated successfully, but these errors were encountered:
Currently there's no way of checking if an official file was downloaded or a malicious one. Checksums help with that. Since the files are on 3rd party server (
bintray.com
), it would make sense to provide the checksums oneasymock.org
in plaintext. This way even ifbintray.com
is compromised, users who verify the files would know not to use them and to report that.Adding the same checksums to GitHub as well would enhance the security even more. Then, if either GitHub, easymock's GitHub account or
easymock.org
is compromised, people would still be able to realize that. So people who download files from GitHub would check the checksum fromeasymock.org
and the other way. I'd put the checksums in plaintext (instead of files) in each release description for easy copy.As for which checksums should be used, I'd recommend both SHA256 and SHA512. For MD5, it's theoretically possible to do a preimage attack, so it's not the best idea to use it. For SHA1, Google were able to create 2 different files that give the same SHA1. SHA256 might be provided in plaintext and SHA512 displayed after clicking a link (as it's longer and might break the page).
The text was updated successfully, but these errors were encountered: