Safe v1.5.3

Changes to Defaults

To comply with the expectations of Mac OS Catalina
about x509 certificates, some changes have been made to
some of the default flag values for x509 issue.

• The default TTL for non-CA's is now 2 years instead of 10 years.
• All certificates now have the default extended key usages of server_auth and client_auth. Previously, the default was to have no extended key usages. These defaults can be overridden by providing any key usages manually.
• For CA certificates, the key_cert_sign and crl_sign key usages are provided by default. These defaults can be overridden by provided any key usages manually.

New Features

• Due to the fact that not specifying key usages to x509 issue will cause the default key usages and extended key usages to be used, the key usage spec no was added to allow the user to specify that they want no key usages on the certificate at all.

Improvements

• Key usage strings provided on the command line are now case-insensitive.
• generate was added as a command alias to gen.

Bug Fixes

• Updated help for target not to say to use -s=false. go-cli apparently won't
  handle that syntax, and so it has been updated to suggest --no-strongbox for the
  same functionality.

Safe v1.5.2

Improvements

• x509 renew and x509 reissue now declare the new expiry time in a more
  human-readable format.
• Commands that talk to Vault that receive non-JSON responses should now give a
  more descriptive response. This could happen if you're targeting something
  that isn't Vault, or, say, if a load balancer that should have passed traffic
  through to Vault decided to respond as itself because of an error or
  misconfiguration.
• Communications to Strongbox are now traced when debugging is turned on.

Bug Fixes

• You can no longer attempt to authenticate when you have no Vault targeted.
• x509 show and x509 validate used to fail if your certificate chain ended
  with something that wasn't a PEM block (such as whitespace). Now, this will
  not cause an error as long as one certificate was successfully found.
• seal and unseal would not add a default port (80 and 443) the same way
  that other commands did, which could cause connection refused errors for
  these specific commands. That should be fixed now.
• export had a usage line that had old flag names. The long help had the right
  flags, but the short help did not. Now they both do.

Safe v1.5.1

New Features

• safe auth now supports a --path flag. This allows auth to be done against an auth backend that is not mounted at the default location.

Improvements

• Safe no longer ignores the path segment of the target URL for most commands. It is now prefixed onto the Vault API portion of the path. For example, safe ls with target URL https://myvault.com/foo will query https://myvault.com/foo/v1/secret (sort of, but it works as a visual example).

Bug Fixes

• The auth commands now set the proper header if --namespace is set on the target.

Safe v1.5.0

New Features

• Vault Enterprise Namespaces are now supported. Specify the --namespace
  flag to the target command when creating your target to have that
  target use the given namespace for all requests.

• safe status now has a --err-sealed (-e) flag. If specified, the
  command will return an error and a non-zero exit code if any of the
  Vaults are sealed. Script away!

Safe v1.4.1

Improvements

• CA Certs configured with the --ca-cert flag to target are now
  exposed through the .svtoken file that Spruce uses to get Vault
  information. At the time of this writing, Spruce won't do anything with
  the CA Cert values, but now it has a means of doing so.

Bug Fixes

• The VaultKV library was missing a couple error checks. These could lead
  to segfaults when attempting to read the response body. No longer. (#192)
• The VaultKV library was not reading to the end of the response body
  when making requests to /sys/health. Now it is, so those connections
  can be reclaimed for reuse. Safe doesn't usually make health checks
  en masse, so this isn't a huge deal, but it is a fixed bug nonetheless.

Safe v1.4.0

New Features

• target now has a --no-strongbox flag. This configures the target to treat
  the Vault installation as having no Strongbox on the VM. This affects seal,
  unseal, and status. Previously, and without this flag set, these commands
  would try to talk to a strongbox server to determine where all the nodes in the
  Vault cluster are, and then perform the command action to all of the nodes.
  With the flag set, the actions will just be applied to the targeted node without
  trying to use a Strongbox server.
• target now has a --ca-cert flag. This flag takes either a certificate
  string or a path to a file containing a certificate. The given certificate
  will be trusted as a root CA instead of the certificates in the system
  certificate pool. This flag can be specified multiple times to provide multiple
  CA certificates. The flag even works for passing through to the vault CLI with
  safe vault.

Improvements

• Self-signed certificates (such as root-CAs) now have randomized serial
  numbers instead of using 1. This could previously cause issues if the
  self-signed certificate was regenerated, as the browser would throw an error
  for a duplicate serial number entry.
• x509 show now shows more information about the certificate, including if it
  is self-signed, if it is a CA, and the certificate's serial number.

Bug Fixes

• Commands that recurse (e.g. tree/paths) would fail if access was denied
  to a subsection of the target tree. This was because an attempt to list a path
  would be made on a node that could be discovered, but Vault would return a
  permissions error when trying to list the particular node. This error is now
  handled in a way that allows the rest of the recursive output to succeed.
• The certificate serial number can no longer increment beyond 2^159, which it
  probably wasn't going to do anyway, but now it definitely won't.

Safe v1.3.4

Bug Fixes

• safe init no longer skips unsealing if the --json flag is specified.
• safe init now waits a short period of time to give the Vault a reasonable
  chance to resolve leader election after unsealing.

Safe v1.3.3

New Commands

• safe logout - because safe target can no longer trivially be used to
  remove a token from an existing target (see below), safe logout is now here
  to do just that. It removes your cached auth token.

Improvements

• safe auth approle now appears in the help listing for safe auth.
• safe target with two positional arguments would overwrite the token of an
  existing target even if the URL was the same. Now, if the URL is the same,
  the token will be kept.

Bug Fixes

• Fixed a bug that was causing connections to the Vault to not be reused. This
  saves a considerable amount of traffic for commands that make a large amount
  of requests, like safe tree. As a result, considerable speed increases may
  be seen, especially in environments with low bandwdith or noticeable latency.

Safe v1.3.2

Bug Fixes

• Proxy configuration wasn't being used when talking to Strongbox. Now it is.
• Proxy configuration wasn't being used when passing through to the Vault CLI also. Now it is... also.

Safe v1.3.1

Bug Fixes

• safe seal no longer fails if the lowest IP node isn't the active Vault.

Improvements

• When performing ssh+socks5 proxy, the private key can now alternatively be
  specified as part of the query string, instead of as the path section of the
  URI.