Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 31 million developers.Sign up
safe targetno longer cares if your current target is valid
before overwriting it.
These are things that should have been done in 1.0.0 to maintain
backward compatibility with older versions of safe`s export calls.
safe exportwill now make a v1-style export if it is able to.
These can be imported by older versions of safe.
--only-aliveflags are now the
default behaviors. They can be flipped with the new
- safe commands no longer 403 when the auth token's policies does not have
access to sys endpoints.
- paths and tree operations work correctly when the Vault has a secret at the
root of a mount.
safe pathswithout the
--keysflag has output again.
safenow supports the versioned KV v2 backend! (Fixes #138)
- Commands that write will append new versions to versioned backends.
- Commands that read will read the newest version (if undeleted) by default.
Older versions can be read with the
- Commands that delete will operate on the newest version by default. You can
target specific versions with the
PATH^VERSIONsyntax. By default, versions
will be marked as deleted. They can be destroyed with the
All versions of a secret can be targeted with the
safe treenow has a
-qflag. Because scripts using paths have
thus far assumed that only paths with accessible secrets will be returned, we need to
make sure that this behavior was preserved by default. However, Vault returns deleted
or destroyed secrets from list requests. Therefore, we have to make extra calls to make
sure that the latest version of the secret is alive.
-q(quick) skips those checks to
get you a result faster, even though any secret with remaining metadata will be returned.
safe versionsis now a command. It shows all the existing version numbers for a
secret with their respective states. v1 backends are abstracted as versioned backends
that only ever have one living version.
safe undeleteis now a command. It undeletes a version that was marked as deleted.
It errs if you try it on a v1 backend because I can't get your cert back and I'm sorry.
safe revertreads in an older version and writes it as the newest version of a secret.
It's a no-op if the newest version is specified. You can revert to versions marked as
deleted with the
-dflag. This will cause the version to be undeleted, read, and then
redeleted. The resulting newest version will be left alive.
- Operations which walk the tree recursively now operate concurrently. This can lead
to a significant speed increase in environments where there is noticeable latency when
communicating with the Vault server. See:
delete -R, etc
- x509 reissue and x509 renew now show up in
safe help x509
--data-onlyflag is now in the help (thanks, @lvets)
- We can
safe localall the way up to Vault 1.0.1 (and possibly even beyond) (Fixes #171)
safe tree /and
safe paths /will now show all secrets across all KV mounts.
- We can read non-strings out of the Vault again (Fixes #178).
safe rekey's key prompt is fixed and now won't just ask you for the first key
- Exports are now in a new format. While this version of safe can import versions of the old
format, this version of safe will produce exports that older versions of safe will not be able
safe local's internals have been updated to work with Vault 0.11.2+
- Safe honours the new
$SAFE_TARGETenvironment variable to override the the safe target without using -T or calling
safe target. This can be used for scripts that want to target a specific vault without modifying the user's current target in
safe auth -T <target>now correctly indicates the target being
authenticated. It used to specify the current target instead of the
specified target, even though it auth'ed to the specified target. Now it no
safe targets --jsonreported the opposite state of the skip-ssh-verify
condition -- this has been corrected.
safe rekeynow cancels an existing rekey operation.
safe x509 issue,
safe x509 renew, and
safe x509 reissuenow have a
--sig-algorithmflag that allows the user to specify which signature
algorithm to sign the certificate with. Previously, this was hardcoded
to be SHA512 with RSA - now that is simply the default value.
safe x509 shownow shows the algorithm that the certificate was signed with.
- The code that actually talks to Vault was switched to a library for smoother
development moving forward. This shouldn't cause any behavioral changes,
but some error messaging may have changed. If some error messaging is unclear,
(or if something broke, of course) drop us an issue.
safe x509 renewcan now recover from missing CRLs and missing
serial numbers, in case you've imported the certificate and
private key from somewhere else.
safe x509 validatenow complains is a certificate is listed as
a CA but does not have its serial number or CRL.
safe x509 issueno longer propagates duplicate
into the resulting X.509 certificate's subject alt names list.
The help for
safe setnow documents all the fun little tricks
that safe has up its sleeve, like
safe set key@some/file.
If you somehow manage to create an empty path via
some other out-of-band access to the Vault,
safe pathswill no
longer panic when it encounters it.
For weirdos who populate
~/.safercwith empty tokens and then
target their vaults via URL (you know who you are), target
lookup has been fixed to work as expected.
Line endings on windows are now properly trimmed when using
Windows LDAP auth should now be functional on more environments due to the above fix.