* Don't race for CRL rebuilding capability check
Core has recently seen some data races during SystemView/replication
updates between them and the PKI subsystem. This is because this
SystemView access occurs outside of a request (during invalidation
handling) and thus the proper lock isn't held.
Because replication status cannot change within the lifetime of a plugin
(and instead, if a node switches replication status, the entire plugin
instance will be torn down and recreated), it is safe to cache this
once, at plugin startup, and use it throughout its lifetime.
Thus, we replace this SystemView access with a stored boolean variable
computed ahead of time.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Update builtin/logical/pki/backend.go
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
There were two races here:
1. Tests racing against periodic func on updating the backend.
2. Tests racing internally to itself, to access the http-served
CRL data.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Fetch CRLs from a user defined CDP (PoC)
* Handle no param sent
* Move CRL fetch to a periodFunc. Use configured CA certs + system root as trusted certs for CRL fetch
* comments
* changelog
* Just use root trust
* cdp->url in api
* Store CRL and populate it initially in cdlWrite
* Update docs
* Update builtin/credential/cert/path_crls.go
Co-authored-by: Steven Clark <steven.clark@hashicorp.com>
* Handle pre-verification of a CRL url better
* just in case
* Fix crl write locking
* Add a CRL fetch unit test
* Remove unnecessary validity clear
* Better func name
* Don't exit early updating CRLs
* lock in updateCRLs
* gofumpt
* err-
Co-authored-by: Steven Clark <steven.clark@hashicorp.com>
Factored out some plugin related tests into their own test package, and added a bunch of parallelism. Moved some non-plugin tests that were in logical_system_integ_test into another file (keeping them in vault package) just for cohesion.
Add plugin version to GRPC interface
Added a version interface in the sdk/logical so that it can be shared between all plugin types, and then wired it up to RunningVersion in the mounts, auth list, and database systems.
I've tested that this works with auth, database, and secrets plugin types, with the following logic to populate RunningVersion:
If a plugin has a PluginVersion() method implemented, then that is used
If not, and the plugin is built into the Vault binary, then the go.mod version is used
Otherwise, the it will be the empty string.
My apologies for the length of this PR.
* Placeholder backend should be external
We use a placeholder backend (previously a framework.Backend) before a
GRPC plugin is lazy-loaded. This makes us later think the plugin is a
builtin plugin.
So we added a `placeholderBackend` type that overrides the
`IsExternal()` method so that later we know that the plugin is external,
and don't give it a default builtin version.
Steven Clark