Add SHA-2 (sha256 / sha512) to checksum #113
Comments
|
Blocked by at least chocolatey/checksum#1 |
|
@TomOne Agreed. But it's not my option to deprecate the use of those checksums. That is going to be a change over time coming from the official sources that publish those hashes in many cases. We can start pushing on the world of those that offer the downloads to be more secure, but we should not fully deprecate until those locations offer it. SHA1, while still having the ability for file collisions is tremendously more secure than MD5. In some cases where the sites are HTTPS, someone would need to break into the site AND put a malicious file that matches checksum. Hard, but not impossible. For packages where the user is calculating those checksums (i.e. not offered by the site), we should definitely enforce a more secure checksum as a requirement. |
|
You’re right. I haven’t tought about that this further. 😄 If we ever plan an (at least partially) automated moderation (what I would very much welcome), it should definitely check if MD5/SHA1 was used and give a warning to the maintainer with the message to use a stronger hash algorithm if available and perhaps encourage the software authors to to switch to SHA256/SHA512. But these hash algorithms still have a drawback: If an attacker breaks into a site, replaces the file with a malicious file including its checksum before the corresponding Choco package is created, the checksum becomes useless for security purposes. GPG signatures wouldn’t have this problem, because to replace that file on the server with malicious code, an attacker would have to steal the private key of the signer, which is normally harder than breaking into the server. 😈 Please consider supporting GPG signatures too and make that the first choice for maintainers if available. I can remember that once a Chocolatey user asked for that, but I cannot find an issue on GH about it. Can I create an issue about that? Even better would be to integrate GPG signatures for Chocolatey packages itself. Other package managers in the *nix world do that already. |
|
Actually plan to set GPG signatures on the packages themselves. That's part of the keys for the moderators conversation we've talked about. Ultimately a moderator signing a package will result in a GPG key on the package. We'll also want to explore if we want to go further and have maintainers sign the packages as well (my vote is yes on this). |
Excellent, but actually we need support for both package signing and for the ability to provide a signature for the downloaded files. Package signing on it’s own doesn’t increase the security for externally downloaded files, it only verifies the integrity of the package itself. |
|
Agreed. Yup. Best of both worlds is ultimately for packages to have no external downloads. |
Sure, but I doubt if that will ever happen, especially with proprietary software. If Chocolatey establishes as de-facto package manager for Windows, it is about to jeopardize the business model of adware/crapware authors and ads on download sites for Windows software. 😈 But now back to the topic: To keep track of this topic, we should create issues for adding GPG signatures for packages and for external downloads, shouldn’t we? |
|
Packages without external downloads? Binary stored where? |
In the package itself, otherwise it would still be external. |
Yes, for packages. How would you create one for external downloads for applications you don't control? |
this breaks version control. This reminds me, we need a url environment variable for package portability. |
@ferventcoder am I not right in saying that going forward, the intention would be to offer a CDN style service for packages, so that we (Chocolatey) grab the MSI/EXE/Zip and store it "somewhere" then re-write the package download URL to point at the cached version. Granted, a premium offering, but something that is being looked into, as per, kickstarter. |
Yup, still have it in mind. :) |
Yes, a premium offering. |
What is being referred to here? Not sure I follow. |
That was mentioned there. @rismoney had a |
What I was getting at is, what is, what is a |
|
We should open a new ticket about this - allows the package download files to be overridden. |
|
Is SHA-256 supported as Very few packages use |
|
@rednoah SHA2 is not in there yet. Only sha1 and md5 at the moment. |
|
I have played with |
|
First version was v4 - https://technet.microsoft.com/en-us/library/dn520872(v=wps.630).aspx |
ferventcoder
changed the title
ferventcoder
changed the title
This adds two SHA-2 encryption algorithms, SHA256 and SHA512 to choco to verify Checksums.
* stable: (chocolateyGH-113) Add SHA-2 support for checksum # Conflicts: # src/chocolatey.resources/helpers/functions/Get-ChocolateyWebFile.ps1
is this is mildly alarming? chocolatey#113 >> https://help.github.com/articles/github-security/ this sounds awesome: https://github.com/chocolatey/choco/wiki/DevelopmentEnvironmentSetup
Although MD5 and SHA1 are still very common as checksums for files, both of these hash functions are considered insecure in cryptography. This is epecially true when these algorithms are used to hash passwords, which is a gross negligence.
When used as file checksums, an attacker could compromise a server and put a malicious file with the very same MD5 or SHA1 checksum as the original file onto that server. Although I know no real world case such an attack, it is still theoretically possible.
The solution is simple: deprecate MD5 and SHA1 as checksums and encourage maintainers to use the more recent SHA256 or SHA512 algorithms. Perhaps Chocolatey should give a warning message if one of the deprecated hash algorithms is used.
MD5 and SHA1 have really no place in modern cryptography and therefore it’s better to also not use them as file checksums.
The text was updated successfully, but these errors were encountered: