Files
vault/changelog
Ryan Cragun 012cd5a42a VAULT-33008: ipv6: always display RFC-5952 §4 conformant addresses (#29228)
USGv6[0] requires implementing §4.1.1 of the NISTv6-r1 profile[1] for
IPv6-Only capabilities. This section requires that whenever Vault
displays IPv6 addresses (including CLI output, Web UI, logs, etc.) that
_all_ IPv6 addresses must conform to RFC-5952 §4 text representation
recommendations[2].

These recommendations do not prevent us from accepting RFC-4241[3] IPv6
addresses, however, whenever these same addresses are displayed they
must conform to the strict RFC-5952 §4 guidelines.

This PR implements handling of IPv6 address conformance in our
`vault server` routine. We handle conformance normalization for all
server, http_proxy, listener, seal, storage and telemetry
configuration where an input could contain an IPv6 address, whether
configured via an HCL file or via corresponding environment variables.

The approach I've taken is to handle conformance normalization at
parse time to ensure that all log output and subsequent usage
inside of Vaults various subsystems always reference a conformant
address, that way we don't need concern ourselves with conformance
later. This approach ought to be backwards compatible to prior loose
address configuration requirements, with the understanding that
going forward all IPv6 representation will be strict regardless of
what has been configured.

In many cases I've updated our various parser functions to call the
new `configutil.NormalizeAddr()` to apply conformance normalization.
Others required no changes because they rely on standard library URL
string output, which always displays IPv6 URLs in a conformant way.

Not included in this changes is any other vault exec mode other than
server. Client, operator commands, agent mode, proxy mode, etc. will
be included in subsequent changes if necessary.

[0]: https://www.nist.gov/publications/usgv6-profile
[1]: https://www.nist.gov/publications/nist-ipv6-profile
[2]: https://www.rfc-editor.org/rfc/rfc5952.html#section-4
[3]: https://www.rfc-editor.org/rfc/rfc4291

Signed-off-by: Ryan Cragun <me@ryan.ec>
2025-01-27 14:14:28 -07:00
..
2023-02-03 12:26:25 -05:00
2023-06-15 12:52:13 -07:00
2024-09-10 16:59:08 +00:00
2024-11-15 13:32:09 -05:00
2024-06-04 10:19:18 -07:00
2022-12-07 13:29:51 -05:00
2022-10-26 15:34:43 -06:00
2022-12-01 16:56:59 -08:00
2022-11-16 09:27:56 -05:00
2022-11-02 13:23:09 -06:00
2022-11-10 12:11:23 -08:00
2022-11-09 12:00:24 -05:00
2022-11-11 11:04:10 -08:00
2022-11-18 10:38:18 -05:00
2022-12-01 09:33:30 -06:00
2022-12-08 15:02:18 -05:00
2022-12-13 14:50:11 -07:00
2023-01-16 13:49:28 -05:00
2023-03-07 16:23:45 +00:00
2023-01-23 15:51:22 -05:00
2023-01-17 16:37:07 -07:00
2023-01-25 15:19:45 +00:00
2023-01-27 18:07:55 +00:00
2023-02-06 09:41:56 -05:00
2023-02-07 14:22:22 -07:00
2023-02-14 17:00:24 +00:00
2023-02-16 22:44:33 +00:00
2023-05-02 19:36:15 -06:00
2023-03-17 07:52:54 -07:00
2023-04-05 10:54:27 -05:00
2023-03-31 11:01:02 -04:00
2023-03-31 15:05:16 +00:00
2023-04-03 15:24:58 -06:00
2023-04-18 14:20:27 -07:00
2023-04-18 07:39:05 -04:00
2023-04-19 14:30:18 -05:00
2023-05-01 16:43:05 +00:00
2023-05-04 13:23:06 -07:00
2023-05-17 11:41:02 -05:00
2023-05-16 10:38:53 -06:00
2023-08-25 10:54:29 -06:00
2023-05-31 14:21:36 -06:00
2023-08-22 15:21:38 +00:00
2023-06-07 15:19:29 +02:00
2023-06-21 14:47:53 -07:00
2023-08-14 15:25:39 -07:00
2023-07-05 17:20:18 +00:00
2023-07-10 10:28:42 -07:00
2023-07-19 23:57:37 +00:00
2023-07-19 19:23:42 +00:00
2023-08-01 14:02:21 -05:00
2023-08-15 19:00:29 +00:00
2023-08-08 13:49:26 -07:00
2023-08-14 12:35:34 -07:00
2024-04-30 10:47:45 -04:00
2023-08-31 23:31:42 +01:00
2023-09-06 11:07:48 -04:00
2023-10-23 18:46:42 +00:00
2023-09-18 10:48:03 -05:00
2023-10-05 13:50:16 -07:00
2023-10-05 09:29:20 -06:00
2023-10-11 09:12:44 -06:00
2023-10-12 17:34:38 +00:00
2023-12-13 11:16:44 -08:00
2024-02-14 11:52:34 -06:00
2023-10-17 15:36:35 -06:00
2023-10-25 21:02:58 +00:00
2023-11-13 21:29:39 +00:00
2023-11-08 11:01:01 +00:00
2023-11-21 15:11:14 -06:00
2023-12-04 10:40:34 -06:00
2023-12-18 17:03:35 +00:00
2024-01-11 15:19:16 -06:00
2024-01-24 18:04:44 +00:00
2024-02-14 11:52:34 -06:00
2024-02-20 11:42:59 -08:00
2024-02-26 09:02:05 -07:00
2024-02-26 20:19:35 +00:00
2024-03-28 13:45:43 -05:00
2024-04-09 12:35:39 -07:00
2024-04-12 22:13:45 +00:00
2024-05-27 15:03:59 -04:00
2024-05-07 11:34:21 -05:00
2024-07-09 09:36:23 -07:00
2024-06-28 13:12:10 -07:00
2024-08-05 16:26:24 -07:00
2024-08-15 09:26:51 -07:00
2024-08-29 12:17:51 -06:00
2024-10-21 15:12:31 -04:00
2024-10-22 14:57:26 +02:00
2024-11-06 00:52:29 +00:00
2024-12-04 13:23:55 -05:00
2025-01-09 11:58:29 -08: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.

If more than one area is impacted, use separate code blocks for each entry.

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."
```