• TLDR
  • Chocolatey Client
  • Chocolatey Community Package Repository
• Summary
• Overall
• Chocolatey binaries and the Chocolatey package
• Organizational Use of Chocolatey
• Chocolatey.org Packages
  • Security for the Community Package Repository:
  • Rigorous Moderation Process for Community Packages
    • Downloading Internet Resources Can Still Be An Issue
• Chocolatey Pro / Chocolatey for Business
• Servers / IP Addresses
• Future Chocolatey Enhancements
• History
  • Past Security Concerns
  • What about a non-administrative installation of Chocolatey? Is it secure?
  • Security Scenarios to Keep in Mind / Avoid
• Report Issue

Let's start here. We know you are going to read this entire document anyway. But to give you a high level of what to expect with Chocolatey.

With Chocolatey (choco) client itself, these are the important things to know:

• Chocolatey is Open source.
• On release, everything is authenticode signed. Binaries and PowerShell scripts.
• Chocolatey is also verified against VirusTotal - 60-70 amped up anti-virus scanners.
• Completely offline - By default choco is installed with the community package repository as a source, but that is easily adjusted to internal repositories.
• No Data Collection / Telemetry - No call home, not even in our commercial options (license tracking is honor-based) and there are organizations (or internal processes) that verify/validate (and karma) that will adjust any abuses of licensing.
• No 3rd party advertising - We do feel that our commercial options make sense for anyone that can afford them, so you will see we lean folks to that.
• Commercial code is not open source - and it won't be open sourced. No need for discussion, there are many reasons we don't need to get into, mostly it protects our ability to ensure all infrastructure costs can be paid for.

Use of the community package repository is optional. Community package repository is the same thing as Chocolatey.org packages, and represents less than 5% of the existing packages in existence (nearly all are internal). Most organizations using Chocolatey do NOT use the community repository, and Chocolatey Software [[DOES NOT RECOMMEND using the community repository either|CommunityPackagesDisclaimer]] for organizational deployments for a variety of reasons.

Here are some other important things to understand:

• The community repository is open source.
• Every version of every package submitted must pass through a rigorous moderation review process before they become publicly available (includes checks for quality, consistency, installation, and validations against VirusTotal. NOTE: Only en-US installers are tested by default via Chocolatey's Package Scanner.).
• Data Collection / Telemetry - IP address, package, and a timestamp - this provides statistics for install counts for community folks. Google analytics for site usage.
• No 3rd party advertising - That's right, we don't have any advertising on the site. We don't agree with the ideas behind ad-based income (but others might and that is fine). People should never be the product and we don't want to waste your time. If you see any of the tools we use (like Disqus) put up advertisements on our pages, please notify us immediately as we might have missed a policy change with them and will need to seek alternatives.

We take security issues very seriously. Security falls into a few areas of the Chocolatey framework - the clients (choco.exe and ChocolateyGUI), and the community repository (aka https://chocolatey.org/packages). While no one can give you a guarantee of complete security, we can provide information here for you to make the best decision for your use of Chocolatey. The most secure use of Chocolatey is when you use Chocolatey with packages that use embedded or local software resources. If you are super security conscious, you should understand the tradeoffs prior to using the community repository.

• If you are an organization and you are using Chocolatey in the recommended way (internal repositories using packages that use internal resources only), Chocolatey is secure and reliable.
• Using the community repository (https://chocolatey.org/packages) is only as secure as the packages that you are using. While Chocolatey provides security features like checksumming, verification against VirusTotal (for packages and any binaries they contain or download. NOTE: Only en-US installers are tested by default via Chocolatey's Package Scanner.), and moderation to be sure packages are using official binaries, there is no guarantee for what may be in the official distributions.
• Moderation and virus checking of packages on the public community repository (https://chocolatey.org/packages) represent what the package and links represented at the time of original moderation. Many packages on the public feed represent software that has distribution rights, so the packages must contain instructions on how to download those binaries from official sources. There is no guarantee (other than packages using a package checksum - required for non-secure downloads) against the vendor changing what is at the URLs that the package uses.
• If you need better runtime protection against malware, you should look at Chocolatey Pro / Chocolatey For Business. While we'd like to offer runtime protection for free to everyone, it's not free for us so we are not able to provide it as a free service.

Chocolatey has grown up quite a bit since the release of 0.9.9+ series and has continued moving towards a secure by default approach. What that means is that Chocolatey will set the more secure defaults and the user has to do something (e.g. set a switch, choose to install Chocolatey to a less secure location, etc.) to reduce the overall security of Chocolatey.

1. Requires elevated permissions to make changes to the default location (C:\ProgramData\chocolatey). The default location is locked down explicitly to Administrators starting in 0.9.10. This reduces escalation of privilege attacks.
2. Requires elevated permissions to run choco.exe in the default installed location. This reduces escalation of privilege attacks.
3. Requires administrative permission to add to the Machine PATH environment variable. This reduces escalation of privilege attacks.
4. Chocolatey by default will stop and ask you to confirm before changing state of the system, showing you the script it wants to execute.
5. choco.exe supports a --whatif scenario (aka --noop) in 0.9.9+ so you can get a feel for what a package would do to your system.
6. To reduce MITM (Man in the middle) attacks, package installs support [[checksums|HelpersInstallChocolateyPackage]], so that when downloading from a remote location, binaries are verified prior to acting on them. If the package downloads over non-secure urls/FTP, Chocolatey v0.10.0+ requires the package include checksums by default (can be overridden by the user).
7. Starting with v0.10.0, users can supply runtime checksums so they are not required to just trust what the package supplies (or in the case a package has missing or incorrect checksums).
8. Starting with v0.10.1, Chocolatey will detect whether an SSL/TLS download is available and automatically switch to that for more security.
9. Choco will not allow you to push to the community package repository without using SSL/TLS (HTTPS). This reduces DNS poisoning issues and discovery of your Community repository API key.
10. When hosting internal packages, those packages can embed software and/or point to internal shares. Non-public packages are not subject to software distribution rights like the packages on the community feed, so you can create packages that are more reliable and secure. See [[What are Chocolatey Packages|GettingStarted#what-are-chocolatey-packages]] for more details.
11. Chocolatey is run by a US-based Delaware Corporation named Chocolatey Software.

The binary choco.exe can be trusted (at least as far as you trust the Chocolatey maintainers, Chocolatey Software, Inc, and formerly RealDimensions Software, LLC). On release, the binaries are also verified against VirusTotal, so you can have some additional 3rd party verification.

• Starting with 0.9.10.0, both the binaries and the PowerShell scripts are Authenticode signed. This certificate is only held by Chocolatey employees (Chocolatey Software, Inc). This provides quite a bit of trust that you are getting Chocolatey from the source and as intended.

Using PowerShell, you can verify the binary (the path below is the default install location, adjust if necessary).

0.10.10+:

C:\ PS> (Get-AuthenticodeSignature -FilePath C:\ProgramData\chocolatey\choco.exe).SignerCertificate | Format-List


Subject      : CN="Chocolatey Software, Inc.", O="Chocolatey Software, Inc.", L=Topeka, S=Kansas, C=US
Issuer       : CN=DigiCert SHA2 Assured ID Code Signing CA, OU=www.digicert.com, O=DigiCert Inc, C=US
Thumbprint   : 4BF7DCBC06F6D0BDFA8A0A78DE0EFB62563C4D87
FriendlyName :
NotBefore    : 3/29/2018 7:00:00 PM
NotAfter     : 4/14/2021 7:00:00 AM
Extensions   : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid,
               System.Security.Cryptography.Oid...}

0.10.4-0.10.9:

C:\ PS> (Get-AuthenticodeSignature -FilePath C:\ProgramData\chocolatey\choco.exe).SignerCertificate | Format-List

Subject      : CN="Chocolatey Software, Inc.", O="Chocolatey Software, Inc.", L=Topeka, S=Kansas, C=US
Issuer       : CN=DigiCert SHA2 Assured ID Code Signing CA, OU=www.digicert.com, O=DigiCert Inc, C=US
Thumbprint   : 493018BA27EAA09B895BC5660E77F694B84877C7
FriendlyName :
NotBefore    : 3/27/2017 7:00:00 PM
NotAfter     : 4/3/2018 7:00:00 AM
Extensions   : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid,
              System.Security.Cryptography.Oid, System.Security.Cryptography.Oid...}

0.9.10 - 0.10.3:

C:\ PS> (Get-AuthenticodeSignature -FilePath C:\ProgramData\chocolatey\choco.exe).SignerCertificate | Format-List

Subject      : CN="RealDimensions Software, LLC", O="RealDimensions Software,
              LLC", L=Topeka, S=Kansas, C=US
Issuer       : CN=DigiCert SHA2 Assured ID Code Signing CA, OU=www.digicert.com,
              O=DigiCert Inc, C=US
Thumbprint   : C9F7FD1A91F078DB6BFCFCCE28B9749F8F2A0C38
FriendlyName :
NotBefore    : 3/23/2016 7:00:00 PM
NotAfter     : 3/28/2017 7:00:00 AM
Extensions   : {System.Security.Cryptography.Oid,
               System.Security.Cryptography.Oid,
               System.Security.Cryptography.Oid,
              System.Security.Cryptography.Oid...}

• Although not the best security method, one can also verify choco based on the strong name. choco.exe is strong named with a key that is known only to the lead maintainer of Chocolatey (Rob). Verify the strong name of the official choco binary with the sn.exe utility - the public key should be 79d02ea9cad655eb.

Using a Visual Studio Command Prompt, you can verify the binary (the path below is the default install location, adjust if necessary). You can also download sn separately if necessary:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>sn -T c:\ProgramData\chocolatey\choco.exe

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Public key token is 79d02ea9cad655eb

• Choco will warn if it is not signed with the right key (the FOSS project has a default key so that it can build appropriately) and require a user to pass --allow-unofficial-build. Over time we are going to increase this so that more places will restrict this (those a user can't just go change source of choco on and build).
• The code for Chocolatey is open source, so you can inspect to visually be sure it is not doing anything malicious to your machine - https://github.com/chocolatey/choco.

For more information on the specifics, see #36 and #501.

When you use Chocolatey in an organizational sense, do so in a manner that requires no internet access. Chocolatey doesn't require internet access at all. The default source (https://chocolatey.org/packages, aka the community package repository) that is available on installed is typically the first thing to be removed when organizations are using Chocolatey. This provides the utmost in security for organizations.

"Hundreds of organizations use a packaging solution that requires zero internet access. It's pretty much the de facto for packaging software deployments on Windows. Have you looked at Chocolatey and building and hosting your own internal packages?"

It's important to keep the following in mind:

"Chocolatey != Chocolatey.org Packages"

It goes without stating that if you are a business and you are using Chocolatey, you should think long and hard before trusting an external source you have no control over (chocolatey.org packages, in addition to all of the binaries that download from official distribution channels over the internet). It is both free and easy to set up your [[own private feed|How-To-Host-Feed]] where you can vet packages and have complete control over the binaries and what gets installed. This also provides a complete offline solution that is reliable and trustworthy. This is what we recommend for businesses that use Chocolatey in production scenarios (and what many of them do). There is a great article written up on the reasoning and options for hosting your own server.

Chocolatey.org has a community repository of packages known as the community feed / community package repository. These packages are created by folks in the community and due to [[distribution rights|CommunityPackagesDisclaimer]], they usually contain executable instructions on how to download software from official distribution points written in PowerShell.

1. Every package submitted to the community package repository (https://chocolatey.org/packages) since October 2014 undergoes a rigorous moderation process before it becomes live. Yes, every package, every version of a package is moderated and approved before they become live. See "Rigorous Moderation Process" below.
2. Packages are run through VirusTotal to produce a second opinion on the relative safety of the package and underlying software that is contained or downloaded by the package. The verification of this is shown on the site. NOTE: Only en-US installers are tested by default via Chocolatey's Package Scanner.
3. Some packages move into a trusted status. This is usually when the package maintainer is also the software maintainer, but can also occur when the maintainer(s) are trusted and multiple versions of a package have been submitted without issues.
4. Packages that download binaries (installers, zip archives) are checked to ensure that the binary is coming from the official distribution source.
5. Users can report malicious packages/software directly to the site administrators using a form found on every package page.
6. Everything is enforced as HTTPS where it should be. This reduces DNS poisoning attacks.
7. Packages are pushed to the site over HTTPS. The site grabs a SHA512 checksum of the package, then forwards it on to where packages are stored securely. You can see this package checksum in 0.9.10+ if you call choco info <packagename>.
8. When installing a package, the site passes the package checksum and then the link for downloading the package. The Chocolatey binaries verify the package meets the package checksum.
9. If the package automation scripts download binaries from official sources, the scripts used can provide checksums to verify those binaries (and are required for non-secure sources). If the package scripts have checksums for the downloads, it provides a further integrity check that the downloadable binaries are the exact same file that the maintainer based the package version on, the moderation process checked (including virus scans by all of the scanners set up with VirusTotal), and is the same binary that the user gets. Chocolatey v0.10.0+ enforces a checksum requirement for non-secure locations by default and is hoping that secure downloads will also become a requirement in 2017 for all new packages and versions submitted to the community repository.
10. Checksums of included binaries are shown on the community package page to allow for folks to perform independent verification. The community has moved to adding an additional VERIFICATION.txt file for verifying the binaries.

In October 2014, the community repository had moderation turned on. All community packages (every version of a package) go through a [[rigorous moderation process|Moderation]] prior to any public consumption:

• All package versions are run through an automated validation process to determine quality.
• All package versions are run through an automated verification process to determine if they work correctly (install, etc).
• All packages versions are run through VirusTotal to determine if there are any flagging items. This includes downloading and unpacking any external resources (See the results on a package page in the Virus section - https://chocolatey.org/packages/chocolatey#virus as an example). NOTE: Only en-US installers are tested by default via Chocolatey's Package Scanner.
• A human [[reviews every package version|Moderation#reviewer--moderator-process]] that is not a [[trusted package|ChocolateyFAQs#what-is-a-trusted-package]]. This process verifies that packages are pulling from official distro sources or checksumming items versus the official distros and checking over scripts for malicious behavior.
• We don't require cryptographically signing packages yet, that is a future enhancement
• Checksumming is a requirement for non-secure scenarios, but is not yet a requirement in some scenarios, so keep reading the next section.

With all of that said, you may want to ensure you build trust with each package as the software is coming from somewhere on the internet sometimes and moderators only validate that the package gets the software from those official distribution points, not necessarily the software itself. While VirusTotal provides a bit more of a validation against the binaries, if the maintainer is not using checksums in the package (checksums are required if the package downloads from non-secure locations), there isn't a guarantee that the software vendor did not pull a switch on the binary (the remote distribution source). If you are concerned about that you should look to Pro or Business (next section).

1. Licensed editions of Chocolatey perform runtime virus scan verification. We highly recommend folks concerned about security using the community feed or other packages that download resources from the internet to use Pro.
2. For organizations, we highly recommend a security conscious company look at the features available in Chocolatey for Business for more security (and locking down of components, like locking down folders even more and other nice tweaks that a business would need to make). Please note that some features are still in development.

For using Chocolatey, if you are using the community repository, you will need to whitelist the following servers:

• https://chocolatey.org
• https://packages.chocolatey.org
• https://licensedpackages.chocolatey.org (licensed editions of Chocolatey)
• https://files.chocolatey.org (licensed editions of Chocolatey)

For specific IP addresses to whitelist, please see the following: https://www.cloudflare.com/ips/

If you are using the community package repository, you would also need to whitelist the official distribution location for EVERY package that you intend to manage (unless you had a licensed edition and the downloads have been cached on the Chocolatey customer CDN). This is due to distribution rights and the community repo being publicly available (discussed above at Chocolatey.org Packages), so those community packages are not able to embed binaries directly into the package and must download those resources at runtime. Licensed editions of Chocolatey take advantage of a [[CDN cache|FeaturesPrivateCdn]] of those downloaded resources, which is used instead of reaching out to those remote locations to ensure availability.

Keep in mind that the Chocolatey CDN can only download resources for packages that it has been able to cache. While it is currently able to cache 70% of the existing packages (https://chocolatey.org/stats for actuals - use PackagesCached divided by UniquePackages), we always recommend running choco search pkgid (or choco info pkgid) to determine if it has the "Downloads cached for licensed users" aspect, or look on the package page for the indicator that the packages are cached. If it does not, you would either need to go through the process of internalization for that package, or look to whitelisting whatever resources that package needed to download.

1. Moderators will cryptographically sign packages with a PGP key that they own. This will allow folks to trust moderators.
2. Users will also cryptographically sign packages so we can provide authenticity that the package came from them.
3. We'll show the package checksum on the website for folks that want to verify the package is brought down appropriately.
4. A user can optionally pass their own checksums that must be validated for downloaded software - chocolatey/choco#112 Available in v0.10.0+.

Some folks may state that Chocolatey is insecure. That is based on older information and is incorrect to be stated in that way. Feel free to correct the person with "You mean Chocolatey used to be insecure, you might want to catch up with the last 3+ years." And then point them to this page (https://chocolatey.org/security).

Or if they say the packages (typically they mean community packages) may not be secure? "Organizations typically do not use the community repository anyway and only use Chocolatey in a completely secure manner. Individuals looking for more protection with the community repository go Pro." Also point them to this page if you haven't already. Some of the paid security features have significant recurring costs based on usage, so unfortunately they can't be offered for free.

It is correct that there were some major security concerns. However, all known concerns have been corrected and/or have a plan to be resolved (e.g. package signing). As we learn of new security concerns we put together a plan to resolve those issues with a priority that each CVE (common vulnerabilities and exposures) requires. In the sense of security, nothing can ever be fully secured, but that is outside of the context of this discussion. We make things as secure as possible given current technologies.

Chocolatey has had multiple security audits and findings have been corrected.

These are things that used to be security concerns. They are listed here for historical purposes in case questions come up or someone states misinformation.

1. Installs without prompting for confirmation - not true as of 0.9.9. Chocolatey by default will stop and ask you to confirm before changing state of the system, showing you the script it wants to execute.
2. Anybody can put packages up on the community feed and they could be malicious - we put package moderation in place in October 2014. All packages coming in are now moderated BEFORE they are open to the public. See http://codebetter.com/robreynolds/2014/10/27/chocolatey-now-has-package-moderation/ for more details.
3. Downloads packages from S3 over HTTP (subject to DNS poisoning) - this was corrected in March 2014 (https://github.com/chocolatey/chocolatey.org/issues/70)
4. Site doesn't require HTTPS (could be subject to DNS poisoning) - https://github.com/chocolatey/chocolatey.org/issues/126 (closed completely in November 2014)
5. Downloads files from the internet with no integrity check - we've added checksumming in August 2014 and started enforcing it by default for non-secure downloads with 0.10.0 in August 2016. Secure downloads will also require checksums sometime in 2017 (but can be flipped on with choco feature disable -n allowEmptyChecksumsSecure or with a runtime switch).
6. Poor permissions with c:\Chocolatey at root (allows attacker to gain Admin perms through specially crafted exes dropped in bin folder, among other things) - we don't install here by default anymore. We install to C:\ProgramData\chocolatey by default for more secure permissions. The default location is locked down explicitly to Administrators starting in 0.9.10.

In a word, it depends on where you install Chocolatey.

Keep in mind by default that Chocolatey requires elevated rights.

1. The default install location (C:\ProgramData\chocolatey) requires elevated rights to install to.
2. It (C:\ProgramData\chocolatey) also requires elevated rights to install packages. To ease this a bit, we add the installing user's ACE with modify access (the user still needs to be elevated/admin at the time of installing/upgrading Chocolatey) (removed in 0.9.10+, for old behavior see #398).
3. Adding system-wide environment variables (e.g. Chocolatey's bin directory to System PATH) requires administrative rights to set.

Now with that in mind, let's talk about a non-administrative install of Chocolatey.

1. A non-admin user installs Chocolatey. They need to select a different install location that they can write to.
2. When they install Chocolatey, it only adds USER environment variables. That means they only appear systemwide for that user alone.
3. Chocolatey does not attempt to set or lock down permissions when a different install location is chosen.

Note the administrative install is secure by default, but the non-admin install can be secure depending on where the user decides to install Chocolatey and steps they take afterwards to secure the installation.

A non-administrative user should choose to install Chocolatey in a directory somewhere under C:\Users\<username> to avoid the most security risk. Ensure that Everyone/Users do not have modify access to the folder by checking the ACL (security tab of Folder properties).

1. Administrative user chooses to install Chocolatey to an insecure location (like the root of the system drive, e.g. C:\Chocolatey). Now anyone that has access to that computer has an attack vector. This is very bad, DO NOT DO THIS. It still requires an administrative execution context to exploit, but it has a high possibility and high impact.
2. Non-admin user chooses to install Chocolatey to an insecure location (like the root of the system drive, e.g. C:\Chocolatey). Now anyone that has access to that computer has an attack vector for that user alone. This has a medium possibility and low impact.
3. Installing user is admin during install, but then the admin privileges are removed. That user can still install portable packages that will end up on PATH. This can lead to escalation of privilege attacks. This is an unlikely scenario but one to consider if you reduce privileges for users in your organization. This has a low possibility but a high impact.

• Report general security issue - please email security [at] chocolatey dot io.
• Report package malware/security/other package issue - please use the Report Abuse link directly on the package page on https://chocolatey.org/packages.