fix(backend): upgrade SVM client, add custom JKS#4130
Merged
GMishx merged 2 commits intoeclipse-sw360:mainfrom May 7, 2026
Merged
fix(backend): upgrade SVM client, add custom JKS#4130GMishx merged 2 commits intoeclipse-sw360:mainfrom
GMishx merged 2 commits intoeclipse-sw360:mainfrom
Conversation
Replace the deprecated Apache HttpClient 4.x stack in SvmConnector and SVMUtils with HttpClient 5.x, fix SSL trust-store configuration, and consolidate all SVM HTTP/TLS logic in a new shared factory class. Changes: - Replace httpmime 4.x with httpclient5 in backend-common pom - Fix stale org.apache.http.HttpHeaders import in BackendUtils - Rewrite SvmConnector: HC5 APIs, Log4j2, no deprecated SSL methods - Rewrite SVMUtils: HC5 APIs, Log4j2 - Add SvmHttpClientFactory: shared singleton HTTP clients pre-built with JKS trust store and mutual-TLS support; files resolved via CommonUtils.loadResource (/etc/sw360/ first, then classpath) - Fix bug: fetchComponentMappings and SVMUtils.prepareJSONRequest now use the configured trust store instead of the JVM default only - Drop PKCS12 client-cert support; document PKCS12-to-JKS migration - Add sw360.properties keys: svm.sw360.truststore.filename/password, svm.sw360.componentmappings.api.url; remove obsolete jks.password - Remove stale URISyntaxException catch in SVMSyncHandler Signed-off-by: Gaurav Mishra <mishra.gaurav@siemens.com>
20d6ae4 to
4269cc3
Compare
ScheduleSyncTask.run() was executing long-running Thrift calls directly in java.util.Timer's single thread. Since Timer uses one thread for all tasks, a slow job (e.g. monitoring list export, ~1 min) blocked every other pending task and made the scheduler unresponsive. Changes: - Delegate the task body to a named daemon thread in ScheduleSyncTask so the Timer thread is freed immediately after each fire. - Add a per-service AtomicBoolean flag in Scheduler (getOrCreateRunningFlag) to prevent concurrent executions of the same service when the Timer fires again while a previous run is still in progress. - Name the Timer instance "sw360-scheduler" and mark it daemon for cleaner thread dumps and graceful Tomcat shutdown. - Remove dead static nextSync field and unused no-arg getNextSync() that were never called outside the class. Signed-off-by: Gaurav Mishra <mishra.gaurav@siemens.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
SW360 connects to the SVM service over HTTPS. The previous implementation used the deprecated Apache HttpClient 4.x stack and hardcoded the path to the JVM's
cacertsfile, which broke on non-Debian JDK installations (e.g./opt/jdk-21.0.2/) whereupdate-ca-certificatesdoes not update the JDK trust store.This PR modernizes the SVM HTTP layer and introduces a configurable JKS trust store so admins can supply enterprise CA certificates (e.g. Siemens PKI) without touching the JDK installation.
Changes:
SvmConnectorandSVMUtilsfrom Apache HttpClient 4.x /httpmimeto HttpClient 5.x with non-deprecated TLS and response-handler APIsSvmHttpClientFactorythat provides thread-safe singleton clients (one for one-way TLS, one for mutual TLS); files are resolved viaCommonUtils.loadResource(/etc/sw360/first, then classpath)fetchComponentMappingsandSVMUtils.prepareJSONRequestusedHttpClients.createDefault(), bypassing any configured trust storesvm.sw360.truststore.filename/password); falls back to JVM defaultcacertswhen not setsvm.sw360.componentmappings.api.urlproperty; remove obsoletesvm.sw360.jks.passwordURISyntaxExceptioncatch inSVMSyncHandlerdocs/svm-ssl-truststore.mdand website page withopenssl s_client,keytoolsteps, and fullsw360.propertiesreferenceHow To Test?
svmtest.cert.siemens.com)./etc/sw360/svm-truststore.jks(follow https://eclipse.dev/sw360/docs/administrationguide/vulnerabilitymanagement/svm-ssl-configuration/)./etc/sw360/sw360.properties:PKIX path building failederror should no longer appear.ExceptionInInitializerErrorshould occur.fetchComponentMappingsand vulnerability data fetches also succeed (they previously ignored the trust store).Checklist
Must: