If you are using a commercial version of Chocolatey (i.e. you have the chocolatey.extension package installed), you will need to first upgrade to version v4.0.0 of the Chocolatey Licensed Extension.
Perhaps the biggest addition this release is the ability to halt installation if a reboot is detected (#1038). Once you turn this feature on, if you are installing some packages and somewhere in the middle of that there is a need for a reboot, Chocolatey will stop and exit with either exit code 350 (pending reboot prior to anything) or 1604 (install incomplete), indicating a reboot is needed to continue. It won't reboot for you, as it is just a package manager - but it will stop execution so nothing that may error on install is attemtped. You'll need to opt into this feature, so see #1038 for details.
The vendored 7Zip had a couple of security findings that necessitated a release. There is also a lot of goodness going into this release as well. We've fixed XDT transforms not to keep extra data around (requiring manual fixes). We've resolved some issues surrounding compatibility with Get-PackageParameters in the chocolatey-core.extension package and what's now built into Chocolatey. That should now work appropriately, and the built-in method should be preferred, so if you are using --package-parameters-sensitive, those will be added as well when you do have the chocolatey-core.extension package also installed.
We've also brought in the long desired logging with no colorization. You can set that as a switch or globally with a feature flipper. With outdated/upgrade, you can now ignore unfound packages along with already skipping pinned packages. That will help you reduce your output to only the things it finds upgrades for that can be upgraded.
With this release, Package Parameters are fully supported from both the user side and the packaging side. Check out the documentation and check out the walkthrough on how to use package parameters in your packaging. Note if you are pushing packages to the community repository, you must continue to take a dependency on the chocolatey-core.extension as a polyfill for older versions until at least six months after a new feature is released.
What you can do with logging has greatly increased your ability to have more power over how it works and deeper output to determine errors (we've expanded --trace #1379). This release also gives packagers and users more power when working with the AutoUninstaller - opt-out (#1257) and passing arguments to the uninstaller (#1133).
This release includes fixes and adjustments to the API to make it more usable. Search / List has also been improved with the data that it returns when verbose/detailed, along with info always returning a package with information instead of erroring sometimes. The search results from the community package repository now match what you see on the website.
We've also made package itself display download progress, which is great when software binaries are embedded in packages. For you folks looking to remove any progress (like when using Vagrant), now you can use --no-progress. When NuGet.Core has issues, those issues will have more visibility into why things are failing without needing a debugging log. Speaking of some extreme visibility, see network traffic with --trace.
When you run choco upgrade all, it never catches the prereleases. However if you run choco upgrade all --pre, it may upgrade some of your stable installs to prereleases. Neither of these situations are desirable. So by default, we've made it so that choco upgrade all just does the right thing, which is to upgrade your stable releases to the latest stable release and your prerelease packages will upgrade to the absolute latest available, whether that be stable or prerelease. If you need to change the behavior back to the old way for upgrade all, simply add the --exclude-prerelease option.
This is a bug fix that was allowing a prerelease to be downgraded accidentally to the last stable version if you ran choco upgrade somepackage --allow-downgrade without a particular version and without --pre. Now while this would be less affected with #686 above, it could still happen. It's a bug. The only reason this was marked as breaking change is that someone could be depending on the buggy behavior. So heads up, this bug is now fixed. If you are attempting to downgrade, make sure you specify the version you want it to go down to.
Starting in v0.9.10, Chocolatey started checking $LASTEXITCODE in addition to the script command success as a way to be more helpful in determining package failures. This meant it offered the ability to capture when a script exited with Exit 1 and handle that accordingly. However that really has never been a recommended scenario for returning errors from scripts and is not seen in the wild anywhere so it is believed that those that may be affected are very few.
Checking $LastExitCode checks the last executable's exit code when the script specifically does not call Exit. This can lead to very perplexing failures, such as running a successful xcopy that exits with 2 and seeing package failures without understanding why. Since it is not typically recommended to call Exit to return a value from PowerShell because of issues with different hosts, it's less of a concern to only look at explicit failures. For folks that may need it, allow failing a package again by the last external command exit code or exit from a PowerShell script. Note that it is not recommended to use exit with a number to return from PowerShell scripts. Instead you should use $env:ChocolateyExitCode or Set-PowerShellExitCode (first available in v0.9.10) to ensure proper setting of the exit code.
A couple of important fixes/enhancements in this release. Most of the improvements are about providing better feedback to you and fixing minor issues. The big one surrounds when packages set a download path for a file using $env:TEMP, choco will ensure that the file can still be found for later use.
We're dubbing this the "Shhh! Keep that secret please" release. We've found that when passing in passwords and other sensitive arguments, those items can end up in the logs in clear text. We've addressed this in #948 and #953. When it comes to passing sensitive arguments through to native installers, you can set up environment variables with those sensitive args and pass those arguments directly through to Start-ChocolateyProcessAsAdmin. If you prefer a better experience, the licensed version allows passing sensitive options directly through choco.exe as --install-arguments-sensitive and --package-parameters-sensitive. Read more in the Licensed CHANGELOG.
Perhaps the biggest improvement in this release is that Chocolatey will automatically look to see if it can download binaries over HTTPS when provided an HTTP url. If so, Chocolatey will switch to downloading the binaries over SSL. This provides better security in downloading and knowing you are getting the binary from the source location instead of a possible man in the middle location, especially when the package does not provide checksums for verification.
Checksums in package scripts are meant as a measure to validate the originally intended downloaded resources used in the creation of a package are the same files that are received at a future date. This also ensures that the same files that are checked by all parts of moderation (if applicable) are the same files that are received by users for a package. This is seen mostly on the community repository because it is public and packages are subject to copyright laws (distribution rights), which typically requires the package scripts to download software from the official distribution locations. The Chocolatey framework has had the ability to use checksums in package scripts since July 2014.
What is the requirement? choco will now fail if a package download resources from HTTP/FTP and does not use checksums to verify those downloaded resources. The requirement for HTTP/FTP is #112. We are considering also requiring it for HTTPS (#895) as well. You can optionally set a feature (allowEmptyChecksumsSecure) to ensure packages using HTTPS also use checksums.
How does this protect the community anymore than before? During moderation review, there is a check of these downloaded binaries against VirusTotal (which verifies these binaries against 50-60+ different virus scanners). The binaries are also verified for installation purposes against a test computer. With an independent 3rd party checksum in the package itself, it guarantees that the files received by a user from those remote sources are the exact same files that were used in the verification process.
Why the requirement, and why now? This is a measure of protection for the Chocolatey community. HTTP is easy to hack with both DNS poisoning and MITM (man in the middle) attacks. Without independent verification of the integrity of the downloaded resources, users can be left susceptible to these issues. We've been planning a move to require checksums for awhile now, with a planned longer and smoother transition for package maintainers to get packages updated to reduce breakages. Unfortunately there was a recent event with FOSSHub getting hacked (the community repository had 8 possibly affected packages and we quickly took action), which necessitated a need for us to move in a much swifter fashion to ensure the protection of the community sooner, rather than later. The changes in Chocolatey represented by the checksum changes are a major step in the process to ensure protection. Requiring for HTTPS as well will mitigate any future compromises of software distribution sites that are used with Chocolatey packages.
Can I shut this behavior off or opt out per package?You can shut off the checksum requirement by enabling the feature allowEmptyChecksums. This will return Chocolatey to previous behavior. We strongly recommend against it. 041b061a72