-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
[7.x] [RHPAM-4504] Update KeyStoreHelper signature fails on ibm1.8 jdk cert… #4662
Conversation
result = sig.verify(signature); // IBM JDK 1.8 returns false without SignatureException | ||
} catch (SignatureException e) { | ||
if (allowVerifyOldSignAlgo) { | ||
// Fallback for old sign algorithm | ||
sig = Signature.getInstance(MD5WITH_RSA); | ||
sig.initVerify(cert.getPublicKey()); | ||
sig.update(data); | ||
return sig.verify(signature); | ||
} else { | ||
throw new RuntimeException("Failed to verify signature. If you call this method for data signed by old Drools version," + | ||
" set system property \"" + KeyStoreConstants.PROP_VERIFY_OLD_SIGN + "\" to true" , e); | ||
} | ||
logger.warn("Exception while verifying signature", e); | ||
return verifyWithFallbackAlgorithmIfAllowed(cert, data, signature); | ||
} | ||
return result || verifyWithFallbackAlgorithmIfAllowed(cert, data, signature); |
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.
IBM JDK 1.8 returns false without SignatureException. So let it retry with fallback algorithm in both cases -- false and SignatureException.
" set system property \"" + KeyStoreConstants.PROP_VERIFY_OLD_SIGN + "\" to true" , e); | ||
} | ||
logger.warn("Exception while verifying signature", e); | ||
return verifyWithFallbackAlgorithmIfAllowed(cert, data, signature); |
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.
Minor improvement: I think that you can explicitly set result
to false
where declared and completely eliminate this early return statement. The other return at the end of the method should already cover all possible cases.
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.
Thank you, @mariofusco . It's exactly better!
…k cert… (apache#4662) * [RHPAM-4504] Update KeyStoreHelper signature fails on ibm1.8 jdk certification test * - better writing
…k cert… (apache#4662) * [RHPAM-4504] Update KeyStoreHelper signature fails on ibm1.8 jdk certification test * - better writing
…k cert… (apache#4662) * [RHPAM-4504] Update KeyStoreHelper signature fails on ibm1.8 jdk certification test * - better writing
…bm1.8 jdk cert… (apache#4662)" This reverts commit 17377b2.
…bm1.8 jdk cert… (apache#4662) (apache#4872)" This reverts commit 0f78d65.
…bm1.8 jdk cert… (apache#4662) (apache#4873)" This reverts commit 74fa069.
…k cert… (apache#4662) (apache#4872) * [RHPAM-4504] Update KeyStoreHelper signature fails on ibm1.8 jdk certification test * - better writing
…k cert… (apache#4662) (apache#4873) * [RHPAM-4504] Update KeyStoreHelper signature fails on ibm1.8 jdk certification test * - better writing
…ification test
Ports
This PR is for 7.x.
Will do for 7.67.x
Will do for 7.67.x-blue
for main -> https://github.com/kiegroup/drools/pull/4678
JIRA:
https://issues.redhat.com/browse/RHPAM-4504
How to replicate CI configuration locally?
Build Chain tool does "simple" maven build(s), the builds are just Maven commands, but because the repositories relates and depends on each other and any change in API or class method could affect several of those repositories there is a need to use build-chain tool to handle cross repository builds and be sure that we always use latest version of the code for each repository.
build-chain tool is a build tool which can be used on command line locally or in Github Actions workflow(s), in case you need to change multiple repositories and send multiple dependent pull requests related with a change you can easily reproduce the same build by executing it on Github hosted environment or locally in your development environment. See local execution details to get more information about it.
How to retest this PR or trigger a specific build:
for pull request checks
Please add comment: Jenkins retest this
for a specific pull request check
Please add comment: Jenkins (re)run [drools|kogito-runtimes|kogito-apps|kogito-examples] tests
for a full downstream build
run_fdb
a compile downstream build please add comment: Jenkins run cdb
a full production downstream build please add comment: Jenkins execute product fdb
an upstream build please add comment: Jenkins run upstream
for quarkus branch checks
Run checks against Quarkus current used branch
Please add comment: Jenkins run quarkus-branch
for a quarkus branch specific check
Run checks against Quarkus current used branch
Please add comment: Jenkins (re)run [drools|kogito-runtimes|kogito-apps|kogito-examples] quarkus-branch
for quarkus main checks
Run checks against Quarkus main branch
Please add comment: Jenkins run quarkus-main
for a specific quarkus main check
Run checks against Quarkus main branch
Please add comment: Jenkins (re)run [drools|kogito-runtimes|kogito-apps|kogito-examples] quarkus-branch
for native checks
Run native checks
Please add comment: Jenkins run native
for a specific native check
Run native checks
Please add comment: Jenkins (re)run [drools|kogito-runtimes|kogito-apps|kogito-examples] native
for mandrel checks
Run native checks against Mandrel image
Please add comment: Jenkins run mandrel
for a specific mandrel check
Run native checks against Mandrel image
Please add comment: Jenkins (re)run [drools|kogito-runtimes|kogito-apps|kogito-examples] mandrel