Files
vault/changelog
Alexander Scheel 6e6914547e Let PKI tidy associate revoked certs with their issuers (#16871)
* Refactor tidy steps into two separate helpers

This refactors the tidy go routine into two separate helpers, making it
clear where the boundaries of each are: variables are passed into these
method and concerns are separated. As more operations are rolled into
tidy, we can continue adding more helpers as appropriate. Additionally,
as we move to make auto-tidy occur, we can use these as points to hook
into periodic tidying.

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

* Refactor revInfo checking to helper

This allows us to validate whether or not a revInfo entry contains a
presently valid issuer, from the existing mapping. Coupled with the
changeset to identify the issuer on revocation, we can begin adding
capabilities to tidy to update this association, decreasing CRL build
time and increasing the performance of OCSP.

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

* Refactor issuer fetching for revocation purposes

Revocation needs to gracefully handle using the old legacy cert bundle,
so fetching issuers (and parsing them) needs to be done slightly
differently than other places. Refactor this from revokeCert into a
common helper that can be used by tidy.

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

* Allow tidy to associate revoked certs, issuers

When revoking a certificate, we need to associate the issuer that signed
its certificate back to the revInfo entry. Historically this was
performed during CRL building (and still remains so), but when running
without CRL building and with only OCSP, performance will degrade as the
issuer needs to be found each time.

Instead, allow the tidy operation to take over this role, allowing us to
increase the performance of OCSP and CRL in this scenario, by decoupling
issuer identification from CRL building in the ideal case.

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

* Add tests for tidy updates

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

* Add changelog entry

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

* Add documentation on new tidy parameter, metrics

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

* Refactor tidy config into shared struct

Finish adding metrics, status messages about new tidy operation.

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
2022-08-26 10:13:45 -07:00
..
2021-01-20 15:06:23 -05:00
2020-12-15 10:42:39 -08:00
2020-12-16 10:55:12 -05:00
2021-01-04 11:08:39 -05:00
2021-01-26 19:30:42 -05:00
2022-08-23 19:05:43 -04:00
2022-08-24 09:03:30 -04:00
2020-12-18 10:26:08 -07:00
2020-11-16 14:05:28 -05:00
2020-11-30 09:24:24 -08:00
2020-11-30 10:28:32 -08:00
2020-12-01 16:08:19 +00:00
2020-12-02 18:21:14 +01:00
2020-12-10 06:55:24 -05:00
2020-12-15 15:58:03 +01:00
2021-01-26 16:37:07 -06:00
2021-01-05 15:32:47 -06:00
2021-01-06 16:05:00 -06:00
2021-02-01 13:38:03 -06:00
2021-02-24 13:29:09 -05:00
2021-01-20 11:02:33 -08:00
2021-01-26 12:45:54 -05:00
2021-02-11 12:16:00 -07:00
2021-02-25 13:00:00 -07:00
2021-11-19 12:59:00 -08:00
2021-03-22 10:03:47 -06:00
2021-03-23 14:55:31 -06:00
2021-03-26 09:53:33 -06:00
2021-04-14 16:07:07 -05:00
2021-04-16 09:33:47 -04:00
2021-04-02 15:17:42 -05:00
2021-04-07 10:46:06 -06:00
2021-04-22 08:58:37 -06:00
2021-04-26 11:23:57 -05:00
2021-06-25 15:41:08 -07:00
2021-06-22 12:39:23 -04:00
2021-05-17 16:41:39 -05:00
2021-05-24 10:45:35 -06:00
2021-05-26 13:59:11 -05:00
2021-06-03 15:30:26 -05:00
2021-10-05 11:28:49 -04:00
2021-06-18 14:56:41 -05:00
2021-06-09 10:38:52 -04:00
2021-06-17 15:56:04 -05:00
2021-06-21 11:35:40 -07:00
2021-07-12 12:50:30 -05:00
2021-07-21 12:47:52 -07:00
2021-07-20 11:28:44 -05:00
2021-11-29 11:09:12 -08:00
2021-08-16 11:55:12 -07:00
2021-09-07 09:16:12 -07:00
2021-08-24 09:54:26 -07:00
2021-08-25 14:22:15 -07:00
2021-09-07 12:54:33 -07:00
2021-10-04 14:31:36 -07:00
2021-09-16 15:28:03 -07:00
2021-11-10 16:39:27 -08:00
2021-09-27 13:48:44 -07:00
2021-09-28 13:15:43 -06:00
2021-10-07 14:00:42 -07:00
2021-10-12 11:14:03 -05:00
2022-02-03 16:52:45 -08:00
2021-10-13 15:04:39 -05:00
2021-10-19 15:05:06 -04:00
2021-10-21 09:32:03 -04:00
2021-10-22 15:16:02 -06:00
2021-10-29 09:58:56 -07:00
2021-12-01 11:41:49 -07:00
2021-11-04 14:25:15 -06:00
2021-11-09 15:05:25 -07:00
2021-11-17 10:30:59 -07:00
2021-11-15 08:48:11 -07:00
2021-11-24 13:38:15 -05:00
2021-12-06 09:38:53 -08:00
2021-11-23 13:51:02 -05:00
2021-12-10 16:14:57 -06:00
2021-12-14 11:11:13 -05:00
2021-12-16 20:44:29 -07:00
2022-01-07 09:16:40 -06:00
2022-01-06 16:34:26 -07:00
2022-01-17 10:33:03 -05:00
2022-01-24 09:50:23 -05:00
2022-02-04 11:10:51 -08:00
2022-02-03 01:46:03 +05:30
2022-03-01 15:13:39 -08:00
2022-02-17 15:40:25 -07:00
2022-02-17 13:17:59 -07:00
2022-02-17 13:17:59 -07:00
2022-02-23 10:00:20 -06:00
2022-02-23 15:08:08 -05:00
2022-03-02 09:45:53 -07:00
2022-03-16 11:00:08 -05:00
2022-03-18 09:40:17 -06:00
2022-03-29 10:25:16 -06:00
2022-04-12 13:59:34 -06:00
2022-04-19 21:19:34 -04:00
2022-04-07 08:30:29 -06:00
2022-04-08 14:37:49 -07:00
2022-04-19 14:28:08 -04:00
2022-04-19 15:45:20 -06:00
2022-05-18 09:16:13 -07:00
2022-05-20 10:41:24 -05:00
2022-05-25 13:37:42 -05:00
2022-06-13 13:17:07 -05:00
2022-06-03 09:17:41 -07:00
2022-06-03 14:22:50 -07:00
2022-06-09 15:55:49 -07:00
2022-07-22 09:50:28 -07:00
2022-06-21 12:27:24 -04:00
2022-07-27 15:22:38 -05:00
2022-08-03 20:44:57 -05:00
2022-08-05 10:27:37 -07:00
2022-08-23 11:08:23 -04:00
2020-11-16 14:05:28 -05:00

changelog

This folder holds changelog updates from commit 3bc7d15 onwards.

Release notes are text files with three lines:

  1. An opening code block with the release-note:<MODE> type annotation.

    For example:

    ```release-note:bug
    

    Valid modes are:

    • bug - Any sort of non-security defect fix.
    • change - A change in the product that may require action or review by the operator. Examples would be any kind of API change (as opposed to backwards compatible addition), a notable behavior change, or anything that might require attention before updating. Go version changes are also listed here since they can potentially have large, sometimes unknown impacts. (Go updates are a special case, and dep updates in general aren't a change). Discussion of any potential change items in the pull request to see what other communication might be warranted.
    • deprecation - Announcement of a planned future removal of a feature. Only use this if a deprecation notice also exists in the docs.
    • feature - Large topical additions for a major release. These are rarely in minor releases. Formatting for feature entries differs from normal changelog formatting - see the new features instructions.
    • improvement - Most updates to the product that arent bugs, but aren't big enough to be a feature, will be an improvement.
  2. A component (for example, secret/pki or sdk/framework or), a colon and a space, and then a one-line description of the change.

  3. An ending code block.

This should be in a file named after the pull request number (e.g., 12345.txt).

There are many examples in this folder; check one out if you're stuck!

See hashicorp/go-changelog for full documentation on the supported entries.

New and Major Features

For features we are introducing in a new major release, we prefer a single changelog entry representing that feature. This way, it is clear to readers what feature is being introduced. You do not need to reference a specific PR, and the formatting is slightly different - your changelog file should look like:

changelog/<pr num OR feature name>.txt:
```release-note:feature
**Feature Name**: Description of feature - for example "Custom password policies are now supported for all database engines."
```