RekeySecretAdminMonitor should be generalized so that done is not a simple boolean, but a numeric counter which gets compared to a constant that is incremented each time we ship a security fix that might have compromised master.key. The call to isUpgradedFromBefore(new VersionNumber("1.496.*")) needs to be somehow changed. And Messages.pleaseRekeyAsap needs to be generalized.
Probably there should also be a button in /configureSecurity allowing an admin to initiate rekeying at any other time that they suspect keys might have been compromised.
- is related to
-
JENKINS-17289 Re-key operation seems to take unnecessarily long
-
- Closed
-
[JENKINS-27446] Rerun SecretRewriter
| Link | New: This issue is blocking SECURITY-167 [ SECURITY-167 ] |
| Link | New: This issue is blocking SECURITY-125 [ SECURITY-125 ] |
| Link | New: This issue is blocking SECURITY-162 [ SECURITY-162 ] |
| Status | Original: Untriaged [ 10001 ] | New: Open [ 1 ] |
| Link |
New:
This issue is related to |
SecretRewriter would also need to be initialized with something other than Secret.getLegacyKey(), and RekeySecretAdminMonitor would have to also look in DefaultConfidentialStore.rootDir for ConfidentialKey instances saved using the old master.key.
Does this really belong to SECURITY? Seems to me that it should be in JENKINS.
| Component/s | New: core [ 15593 ] | |
| Component/s | Original: core [ 15738 ] | |
| Key | Original: SECURITY-174 | New: JENKINS-27446 |
| Project | Original: Security Issues [ 10180 ] | New: Jenkins [ 10172 ] |
| Workflow | Original: Security v1.2 [ 160988 ] | New: JNJira [ 161654 ] |
Re-keying wasn't fun. It took forever and in the end modified 36 files.
JENKINS-17289suggests a few performance improvements that should be considered if this becomes a semi-regular event.