changelog++

This commit is contained in:
Jeff Mitchell 2016-05-27 13:55:23 -04:00
parent 39fe3200e3
commit 9185941f1a
1 changed files with 41 additions and 1 deletions

View File

@ -1,4 +1,4 @@
## 0.5.3 (Unreleased)
## 0.6.0 (Unreleased)
SECURITY:
@ -134,6 +134,46 @@ BUG FIXES:
* secret/pki: Don't check whether a certificate is destined to be a CA
certificate if sign-verbatim endpoint is used [GH-1250]
## 0.5.3 (May 27th, 2016)
SECURITY:
* Consul ACL Token Revocation: An issue was reported to us indicating that
generated Consul ACL tokens were not being properly revoked. Upon
investigation, we found that this behavior was reproducible in a specific
scenario: when a generated lease for a Consul ACL token had been renewed
prior to revocation. In this case, the generated token was not being
properly persisted internally through the renewal function, leading to an
error during revocation due to the missing token. Unfortunately, this was
coded as a user error rather than an internal error, and the revocation
logic was expecting internal errors if revocation failed. As a result, the
revocation logic believed the revocation to have succeeded when it in fact
failed, causing the lease to be dropped while the token was still valid
within Consul. In this release, the Consul backend properly persists the
token through renewals, and the revocation logic has been changed to
consider any error type to have been a failure to revoke, causing the lease
to persist and attempt to be revoked later.
We have written an example shell script that searches through Consul's ACL
tokens and looks for those generated by Vault, which can be used as a template
for a revocation script as deemed necessary for any particular security
response. The script is available at
https://gist.github.com/jefferai/6233c2963f9407a858d84f9c27d725c0
Please note that any outstanding leases for Consul tokens produced prior to
0.5.3 that have been renewed will continue to exhibit this behavior. As a
result, we recommend either revoking all tokens produced by the backend and
issuing new ones, or if needed, a more advanced variant of the provided example
could use the timestamp embedded in each generated token's name to decide which
tokens are too old and should be deleted. This could then be run periodically
up until the maximum lease time for any outstanding pre-0.5.3 tokens has
expired.
This is a security-only release. There are no other code changes since 0.5.2.
The binaries have one additional change: they are built against Go 1.6.1 rather
than Go 1.6, as Go 1.6.1 contains two security fixes to the Go programming
language itself.
## 0.5.2 (March 16th, 2016)
FEATURES: