Verify the checksum of a package before installation, and fail if not matched

[donbecker]

What You Are Seeing?

The checksum options in "choco install" validate checksums of external package dependencies downloaded from the internet.

While this can ensure content of the external dependency, it does not ensure content of the package and it's files/content (and therefore does not ensure content of repackaged packages with all included dependencies).

What is Expected?

Suggest new options "packagechecksum" and "packagechecksumType" to validate the checksum of the entire nupkg file after chocolatey downloads it. Suggest supporting all checksum types supported by present external checksum types (md5, sha1, etc etc).

cinst chefdk --version 1.1.16 -y -packagechecksum 'ca1cbfe819128dbd252d53f31e3cfae7' -packagechecksumType 'md5'

I searched quite a bit to determine if this was possible in present functionality. Apologies in advance if I've missed something.

[ferventcoder]

It already does this.

[ferventcoder]

But I get what you mean. Ensuring that the package coming down has an external verification that you can run client side. I like it.

[ferventcoder]

Suggest new options "packagechecksum" and "packagechecksumType" to validate the checksum of the entire nupkg file after chocolatey downloads it. Suggest supporting all checksum types supported by present external checksum types (md5, sha1, etc etc).

You wouldn't need to specify the type. That is determinable based on the value passed through and it's length.

[ferventcoder]

It already does this.

Sorry, what I meant there is that NuGet.Core already gets an expected package checksum and then verifies it received that same size automatically.

Which isn't the same as this request.

[ferventcoder]

@donbecker Recently I reviewed how packagehash was being used locally, and it doesn't appear that is it being used for verifying what was received was what was thought to be received (instead it appears to be only used for checking that a cached version of the package is the same as the remote to choose to redownload the file or not). I think this issue stands then as something that should be addressed.

[ferventcoder]

This could play right into authenticode signatures we are looking at implementing as well.

[donbecker]

@ferventcoder Sounds great. I still think this would be a great feature for Chocolatey to have regarding integrity of packages.

[TheCakeIsNaOH]

After the nuget library uplift, this should be able to be implemented for free as a side effect of implementing validating code signatures on packages, #504

[TheCakeIsNaOH]

After previous discussion with @gep13, this issue depends on #508, as code signing has been added to newer nuget versions.

[miketheitguy]

I'd like to add on to the OP's comments here. There is a valid use case for this even with internal repositories. Particularly when you have systems that span trust boundaries (where you have some environments with higher or lower classification levels) and you don't want to duplicate infrastructure throughout each environment.

In @TheCakeIsNaOH 's comments, you should "trust the infrastructure"--that's not entirely something that is true. Supply chain compromise, even internally, can be a risk in highly secure environments. Utilizing package checksums on the package download provides a really simple way for a critical system to trust packages retrieved from a system seen as less critical, often times because it could be run by an entirely different org within your company.

I could, for example, deploy execution commands on more secure systems that downloads packages from say, a company's singular internal repository for all things repo downloads (think: Artifactory) while simultaneously guaranteeing, that no matter what, under any circumstance, under any compromise of that system, that my higher privileged environments won't execute code from a malicious package by simply providing a command line hash validation argument on the entire nupkg.

Now, an attacker would have to both compromise the target system to modify the integrity check while simultaneously modifying the package--which renders utilizing the package as a privilege escalation or lateral movement scheme pretty much entirely invalid.

There are compensating capabilities here that exist today in Windows--and that's using Windows Defender Application Control to validate code signatures of PowerShell scripts as well as binaries executing on the target system. While this is inarguably the more secure solution, with policies capable of being protected by the TPM and UEFI NVRAM and Hypervisor separation, it's a lot of work to get that capability going on a Windows platform and would require signing all individual scripts and package files (if you don't trust existing authenticode signatures by 3rd party providers).

Implementing such a check in Chocolatey would provide a much lower barrier to entry for simple package validation rather than manually verifying the package prior to execution.

As far as dependency management goes, I think this should absolutely be an opt-in feature, and I don't see anything wrong with providing an option for the end user to checksum all of the dependencies either.

I think it's valid to say that if you can't include a checksum of each dependency in the nuspec file, then instruct the user when the command line argument is added that they must first install the dependencies (no automatic download). In this manner, it's up to the user whether they want to checksum the dependencies or not. My expectation is that users of course would.

[choco-bot]

🎉 This issue has been resolved in version 2.3.0 🎉

The release is available on:

• GitHub Release
• Chocolatey Package

Your GitReleaseManager bot 📦 🚀