luxolus
/
open-vault
2
0
Fork 0
Code Issues 1 Pull Requests Releases Activity
open-vault/changelog/20058.txt

4 lines
126 B
Plaintext
Raw Normal View History

Fix building unified delta WAL, unified delta CRLs (#20058) * Correctly find certificates for unified delta CRL When building the unified delta CRL, WAL entries from the non-primary cluster were ignored. This resulted in an incomplete delta CRL, preventing some entries from appearing. Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com> * Correctly rebuild unified delta CRLs When deciding if the Unified Delta CRL should be rebuilt, we need to check the status of all clusters and their last revoked serial numbers. If any new serial has been revoked on any cluster, we should rebuild the unified delta CRLs. Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com> * Correctly persist Unified Delta CRL build entries When building the unified CRL, we need to read the last seen serial number from all clusters, not just the present cluster, and write it to the last built serial for that cluster's unified delta WAL entry. This prevents us from continuously rebuilding unified CRLs now that we have fixed our rebuild heuristic. Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com> * Fix getLastWALSerial for unified delta CRLs getLastWALSerial ignored its path argument, preventing it from reading the specified cluster-specific WAL entry. On the primary cluster, this was mostly equivalent, but now that we're correctly reading WAL entries and revocations for other clusters, we need to handle reading these entries correctly. Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com> * Copy delta WAL entries in event of failure Any local delta WAL should be persisted to unified delta WAL space as well. If such unified persistence fails, we need to ensure that they get eventually moved up, otherwise they'll remain missing until the next full CRL rebuild occurs, which might be significantly longer than when the next delta CRL rebuild would otherwise occur. runUnifiedTransfer already handles this for us, but it lacked logic for delta WAL serials. The only interesting catch here is that we refuse to copy any entries whose full unified revocation entry has not also been written. Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com> * Make doUnifiedTransferMissingLocalSerials log an error This message is mostly an error and would always be helpful information to have when troubleshooting failures. Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com> * Warn on cross-cluster write failures during revoke When revoking certificates, we log cross-cluster revocation failures, but we should really expose this information to the caller, that their local revocation was successful, but their cross-cluster revocation failed. Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com> * Ensure unified delta WAL entry has full entry Delta WAL entries are empty files whose only information (a revoked serial number) is contained in the file path. These depend implicitly on a full revocation entry existing for this file (whether a cross-cluster unified entry or a local entry). We should not write unified delta WAL entries without the corresponding full unified revocation entry existing. Add a warning in this case. Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com> * Add changelog entry Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com> --------- Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
2023-04-11 18:02:58 +00:00
```release-note:bug
secrets/pki: Fix building of unified delta CRLs and recovery during unified delta WAL write failures.
```