New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for SHA-256/512 in update site metadata #3356
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🐝 nothing seems weird.
Build failed but no errors are shown...
@daniel-beck is it still on hold? |
@oleg-nenashev This is on-hold because it depends on the corresponding PR to Jenkins project infra. Timeline:
This is ready to be reviewed etc. -- in fact, I invite feedback before I make infra changes. |
Corresponding infra change is merged. @jenkinsci/code-reviewers Ping -- would like to land this this week. |
@rtyler objected to the massive increase in size of update-center.json, so I've followed up in jenkins-infra/update-center2#196 and need to adapt this PR. |
a099442
to
6dc3297
Compare
Rebased to current master. I'm not convinced this needs adapting, will try the upcoming PR build. |
Un-onholding this. @jenkinsci/code-reviewers assemble! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🐝
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the reason for the partial SHA-256 support if the update center only has SHA-1 and SHA-512 after jenkins-infra/update-center2#196? Is it so that if we eventually add SHA-256 back to the update center we don't have to modify as much code on the Jenkins side? Other than that question the changes look good to me.
VerificationResult result512 = verifyChecksums(entry.getSha512(), job.getComputedSHA512(), false); | ||
switch (result512) { | ||
case PASS: | ||
// this has passed but no real reason not to check the others |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the idea behind falling through here that if there is a SHA-512 collision that isn't also a SHA-256 or SHA-1 collision it will be caught by checking the other signatures?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically, yes. Seems extremely unlikely that this is a likely case, but as the comment says, no real reason not to check the others, if they are defined.
It's essentially free to support this way, and SHA-256 could be a desirable mode for some custom update sites. |
In that case, should we add support for SHA-256 to |
That's probably a good idea. Let's see whether I can find the time to do this within this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. I am fine with SHA-256 support being added to JSONSignatureValidator as a separate change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
// Irrelevant as the Java spec says SHA-1 must exist. Still, if this fails | ||
// the DownloadJob will just have computedSha1 = null and that is expected | ||
// to be handled by caller | ||
sha256 = MessageDigest.getInstance("SHA-256"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it considered as weak now? Logging message would say so if there is no SHA-512
try { | ||
// Java spec says SHA-1 and SHA-256 exist, and SHA-512 might not, so one try/catch block should be fine | ||
sha1 = MessageDigest.getInstance("SHA-1"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to create a follow-up ticket to disable weak algorithms (e.g. via Security settings or system property)
@@ -1107,12 +1108,15 @@ public void postValidate(DownloadJob job, File src) throws IOException { | |||
*/ | |||
public File download(DownloadJob job, URL src) throws IOException { | |||
MessageDigest sha1 = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
having one digest
field and ENUM for type would simplify the logic below
I forgot to adapt the tool installer metadata as well, so on-holding this while Jenkins would show messages like this:
|
Un-onholding this, after releasing update-center2-2.0 and using it in jenkins-infra/crawler#77 tools metadata include the additional checksums. Haven't attempted this PR build yet, but I expect this to resolve the problem from the previous comment. |
😃 |
@daniel-beck please note the behavior for the 'verifyChecksums' method has changed, since no error was thrown previously if no SHA-1 was provided. |
If the update site metadata provides SHA-512 or SHA-256 checksums, check those.
This is intended as a security hardening. SHA-1 isn't a good choice anymore.
Companion PR in infra: jenkins-infra/update-center2#191. As Jenkins will continue to support update sites that only provide SHA-1 (for now, and with a warning), they could be merged independently, but probably should not be.
Proposed changelog entries
Submitter checklist
* Use the
Internal:
prefix if the change has no user-visible impact (API, test frameworks, etc.)