Welcome to the Chocolatey Community Package Repository! The packages found in this section of the site are provided, maintained, and moderated by the community.
Every version of each package undergoes a rigorous moderation process before it goes live that typically includes:
- Security, consistency, and quality checking
- Installation testing
- Virus checking through VirusTotal
- Human moderators who give final review and sign off
If you are an organization using Chocolatey, we want your experience to be fully reliable. Due to the nature of this publicly offered repository, reliability cannot be guaranteed. Packages offered here are subject to distribution rights, which means they may need to reach out further to the internet to the official locations to download files at runtime.
Fortunately, distribution rights do not apply for internal use. With any edition of Chocolatey (including the free open source edition), you can host your own packages and cache or internalize existing community packages.
Your use of the packages on this site means you understand they are not supported or guaranteed in any way. Learn more...
Downloads of v 0.9.2:
07 Apr 2018
- Mitchell Hashimoto
This is not the latest version of Vault available.
To edit the metadata for a package, please upload an updated version of the package.
Chocolatey's Community Package Repository currently does not allow updating package metadata on the website. This helps ensure that the package itself (and the source used to build the package) remains the one true source of package metadata.
This does require that you increment the package version.
This is not the latest version of Vault available.
All Checks are Passing
2 Passing Test
Validation Testing Passed
Verification Testing PassedDetails
This package was approved as a trusted package on 07 Apr 2018.
Vault is a tool for securely accessing secrets. A secret is anything that you want to tightly control access to, such as API keys, passwords, certificates, and more. Vault provides a unified interface to any secret, while providing tight access control and recording a detailed audit log.
A modern system requires access to a multitude of secrets: database credentials, API keys for external services, credentials for service-oriented architecture communication, etc. Understanding who is accessing what secrets is already very difficult and platform-specific. Adding on key rolling, secure storage, and detailed audit logs is almost impossible without a custom solution. This is where Vault steps in.
The key features of Vault are:
- Secure Secret Storage: Arbitrary key/value secrets can be stored in Vault. Vault encrypts these secrets prior to writing them to persistent storage, so gaining access to the raw storage isn't enough to access your secrets. Vault can write to disk, Consul, and more.
- Dynamic Secrets: Vault can generate secrets on-demand for some systems, such as AWS or SQL databases. For example, when an application needs to access an S3 bucket, it asks Vault for credentials, and Vault will generate an AWS keypair with valid permissions on demand. After creating these dynamic secrets, Vault will also automatically revoke them after the lease is up.
- Data Encryption: Vault can encrypt and decrypt data without storing it. This allows security teams to define encryption parameters and developers to store encrypted data in a location such as SQL without having to design their own encryption methods.
- Leasing and Renewal: All secrets in Vault have a lease associated with it. At the end of the lease, Vault will automatically revoke that secret. Clients are able to renew leases via built-in renew APIs.
- Revocation: Vault has built-in support for secret revocation. Vault can revoke not only single secrets, but a tree of secrets, for example all secrets read by a specific user, or all secrets of a particular type. Revocation assists in key rolling as well as locking down systems in the case of an intrusion.
For more information, see the introduction section of the Vault website.
$checksum = '405d746a2d0b7f359d8579a82b1eedc94f69b210f4f10de2ccc3d62f58da3064' $checksum64 = '9e64cd2a337fc25f9c29dbf5d1b1620527a53939f3d434fe5cea753552a72635' $version = '0.9.2' $url = "https://releases.hashicorp.com/vault/$($version)/vault_$($version)_windows_386.zip" $url64bit = "https://releases.hashicorp.com/vault/$($version)/vault_$($version)_windows_amd64.zip" $unzipLocation = "$(Split-Path -parent $MyInvocation.MyCommand.Definition)" Install-ChocolateyZipPackage -PackageName "vault" -Url "$url" -UnzipLocation "$unzipLocation" -Url64 "$url64bit" -ChecksumType 'sha256' -Checksum "$checksum" -Checksum64 "$checksum64"
Log in or click on link to see number of positives.
- vault.0.9.2.nupkg (a11174ba832b) - ## / 60
- vault_0.9.2_windows_amd64.zip (9e64cd2a337f) - ## / 59
- vault_0.9.2_windows_386.zip (405d746a2d0b) - ## / 59
- vault.exe (40b3eddb20ba) - ## / 65
- vault.exe (0fd81d5b00d3) - ## / 64
In cases where actual malware is found, the packages are subject to removal. Software sometimes has false positives. Moderators do not necessarily validate the safety of the underlying software, only that a package retrieves software from the official distribution point and/or validate embedded software against official distribution point (where distribution rights allow redistribution).
Chocolatey Pro provides runtime protection from possible malware.
|Vault 1.6.2||1693||Monday, February 1, 2021||Approved|
|Vault 1.6.1||614||Thursday, January 21, 2021||Approved|
|Vault 1.5.5||3174||Friday, October 23, 2020||Approved|
|Vault 1.5.4||1510||Thursday, October 22, 2020||Approved|
|Vault 1.5.3||180||Thursday, October 22, 2020||Approved|
|Vault 1.5.2||2210||Wednesday, August 26, 2020||Approved|
|Vault 1.5.0||1490||Wednesday, July 22, 2020||Approved|
|Vault 1.4.3||784||Friday, July 3, 2020||Approved|
|Vault 1.4.1||1627||Monday, May 4, 2020||Approved|
|Vault 1.4.0||1269||Thursday, April 9, 2020||Approved|
|Vault 1.3.4||134||Wednesday, April 8, 2020||Approved|
|Vault 1.3.3||795||Monday, March 9, 2020||Approved|
|Vault 1.3.2||1357||Friday, January 24, 2020||Approved|
|Vault 1.3.1||1492||Friday, December 20, 2019||Approved|
|Vault 1.3.0||393||Wednesday, December 11, 2019||Approved|
|Vault 1.2.4||934||Tuesday, November 12, 2019||Approved|
|Vault 1.2.3||3315||Monday, September 16, 2019||Approved|
|Vault 1.2.2||2258||Friday, August 16, 2019||Approved|
|Vault 1.2.1||72||Thursday, August 8, 2019||Approved|
|Vault 1.2.0||855||Wednesday, July 31, 2019||Approved|
|Vault 1.1.1||4934||Tuesday, April 16, 2019||Approved|
|Vault 1.1.0||894||Tuesday, March 19, 2019||Approved|
|Vault 1.0.3||588||Friday, March 1, 2019||Approved|
|Vault 0.10.0||3003||Monday, April 16, 2018||Approved|
|Vault 0.10.0-rc1||206||Saturday, April 7, 2018||Approved|
|Vault 0.9.6||376||Saturday, April 7, 2018||Approved|
|Vault 0.9.5||189||Saturday, April 7, 2018||Approved|
|Vault 0.9.4||240||Saturday, April 7, 2018||Approved|
|Vault 0.9.3||188||Saturday, April 7, 2018||Approved|
|Vault 0.9.2||192||Saturday, April 7, 2018||Approved|
|Vault 0.9.1||894||Saturday, January 13, 2018||Approved|
|Vault 0.9.0||238||Saturday, January 13, 2018||Approved|
|Vault 0.8.3||832||Wednesday, September 20, 2017||Approved|
|Vault 0.8.2||269||Wednesday, September 20, 2017||Approved|
|Vault 0.8.1||349||Thursday, August 24, 2017||Approved|
|Vault 0.8.0||317||Thursday, August 24, 2017||Approved|
|Vault 0.7.3||467||Thursday, June 8, 2017||Approved|
|Vault 0.7.2||316||Wednesday, June 7, 2017||Approved|
|Vault 0.7.1||280||Wednesday, June 7, 2017||Approved|
|Vault 0.7.0||295||Wednesday, June 7, 2017||Approved|
|Vault 0.6.5||802||Wednesday, February 8, 2017||Approved|
|Vault 0.6.4||416||Thursday, December 22, 2016||Approved|
|Vault 0.6.3||312||Wednesday, December 14, 2016||Approved|
|Vault 0.6.2||379||Tuesday, October 25, 2016||Approved|
|Vault 0.6.1||371||Tuesday, August 30, 2016||Approved|
0.9.2 (January 26th, 2018)
- Okta Auth Backend: While the Okta auth backend was successfully verifying usernames and passwords, it was not checking the returned state of the account, so accounts that had been marked locked out could still be used to log in. Only accounts in SUCCESS or PASSWORD_WARN states are now allowed.
- Periodic Tokens: A regression in 0.9.1 meant that periodic tokens created by the AppRole, AWS, and Cert auth backends would expire when the max TTL for the backend/mount/system was hit instead of their stated behavior of living as long as they are renewed. This is now fixed; existing tokens do not have to be reissued as this was purely a regression in the renewal logic.
- Seal Wrapping: During certain replication states values written marked for seal wrapping may not be wrapped on the secondaries. This has been fixed, and existing values will be wrapped on next read or write. This does not affect the barrier keys.
sys/healthDR Secondary Reporting: The
replication_dr_secondarybool returned by
sys/healthcould be misleading since it would be
falseboth when a cluster was not a DR secondary but also when the node is a standby in the cluster and has not yet fully received state from the active node. This could cause health checks on LBs to decide that the node was acceptable for traffic even though DR secondaries cannot handle normal Vault traffic. (In other words, the bool could only convey "yes" or "no" but not "not sure yet".) This has been replaced by
replication_perf_modewhich are string values that convey the current state of the node; a value of
disabledindicates that replication is disabled or the state is still being discovered. As a result, an LB check can positively verify that the node is both not
disabledand is not a DR secondary, and avoid sending traffic to it if either is true.
- PKI Secret Backend Roles parameter types: For
organizationin role definitions in the PKI secret backend, input can now be a comma-separated string or an array of strings. Reading a role will now return arrays for these parameters.
- Plugin API Changes: The plugin API has been updated to utilize golang's context.Context package. Many function signatures now accept a context object as the first parameter. Existing plugins will need to pull in the latest Vault code and update their function signatures to begin using context and the new gRPC transport.
- gRPC Backend Plugins: Backend plugins now use gRPC for transport, allowing them to be written in other languages.
- Brand New CLI: Vault has a brand new CLI interface that is significantly streamlined, supports autocomplete, and is almost entirely backwards compatible.
- UI: PKI Secret Backend (Enterprise): Configure PKI secret backends, create and browse roles and certificates, and issue and sign certificates via the listed roles.
- auth/aws: Handle IAM headers produced by clients that formulate numbers as ints rather than strings [GH-3763]
- auth/okta: Support JSON lists when specifying groups and policies [GH-3801]
- autoseal/hsm: Attempt reconnecting to the HSM on certain kinds of errors (Enterprise)
- cli: Output password prompts to stderr to make it easier to pipe an output token to another command [GH-3782]
- core: Report replication status in
- physical/s3: Allow using paths with S3 for non-AWS deployments [GH-3730]
- physical/s3: Add ability to disable SSL for non-AWS deployments [GH-3730]
- plugins: Args for plugins can now be specified separately from the command, allowing the same output format and input format for plugin information [GH-3778]
organizationcan now be specified as a comma-separated string or an array of strings [GH-3804]
- plugins: Plugins will fall back to using netrpc as the communication protocol on older versions of Vault [GH-3833]
- auth/(approle,aws,cert): Fix behavior where periodic tokens generated by these backends could not have their TTL renewed beyond the system/mount max TTL value [GH-3803]
- auth/aws: Fix error returned if
bound_iam_principal_arnwas given to an existing role update [GH-3843]
- core/sealwrap: Speed improvements and bug fixes (Enterprise)
- identity: Delete group alias when an external group is deleted [GH-3773]
- legacymfa/duo: Fix intermittent panic when Duo could not be reached [GH-2030]
- secret/database: Fix a location where a lock could potentially not be released, leading to deadlock [GH-3774]
- secret/(all databases) Fix behavior where if a max TTL was specified but no default TTL was specified the system/mount default TTL would be used but not be capped by the local max TTL [GH-3814]
- secret/database: Fix an issue where plugins were not closed properly if they failed to initialize [GH-3768]
- ui: mounting a secret backend will now properly set
default_lease_ttlwhen specified - previously both fields set
For more information on previous releases, check out the changelog on GitHub.
This package has no dependencies.
- This discussion is only about Vault and the Vault package. If you have feedback for Chocolatey, please contact the Google Group.
- This discussion will carry over multiple versions. If you have a comment about a particular version, please note that in your comments.
- The maintainers of this Chocolatey Package will be notified about new comments that are posted to this Disqus thread, however, it is NOT a guarantee that you will get a response. If you do not hear back from the maintainers after posting a message below, please follow up by using the link on the left side of this page or follow this link to contact maintainers. If you still hear nothing back, please follow the package triage process.
- Tell us what you love about the package or Vault, or tell us what needs improvement.
- Share your experiences with the package, or extra configuration or gotchas that you've found.
- If you use a url, the comment will be flagged for moderation until you've been whitelisted. Disqus moderated comments are approved on a weekly schedule if not sooner. It could take between 1-5 days for your comment to show up.