This can be seen via System(). In the PKI backend, if the CA is
reconfigured but not fully (e.g. an intermediate CSR is generated but no
corresponding cert set) and there are already leases (issued certs), the
CRL is unable to be built. As a result revocation fails. But in this
case we don't actually need revocation to be successful since the CRL is
useless after unmounting. By checking taint status we know if we can
simply fast-path out of revocation with a success in this case.
Fixes#946
backends for the moment. This is pretty simple; it just adds the actual
capability to make a list call into both the CLI and the HTTP handler.
The real meat was already in those backends.
The secretAccessKeysRevoke revoke function now asserts that it is
not dealing with STS keys by checking a new internal data flag. Defaults
to IAM when the flag is not found.
Factored out genUsername into its own function to share between STS and
IAM secret creation functions.
Fixed bad call to "WriteOperation" instead of "UpdateOperation" in
aws/backend_test
The new STS path allows for obtaining the same credentials that you would get
from the AWS "creds" path, except it will also provide a security token, and
will not have an annoyingly long propagation time before returning to the user.
From the PostgreSQL docs
(http://www.postgresql.org/docs/9.4/static/datatype-character.html):
> Tip: There is no performance difference among these three types,
> apart from increased storage space when using the blank-padded type,
> and a few extra CPU cycles to check the length when storing into a
> length-constrained column. While character(n) has performance
> advantages in some other database systems, there is no such advantage
> in PostgreSQL; in fact character(n) is usually the slowest of the
> three because of its additional storage costs. In most situations
> text or character varying should be used instead.
