Skip to content

fix(backend): upgrade SVM client, add custom JKS#4130

Merged
GMishx merged 2 commits intoeclipse-sw360:mainfrom
siemens:feat/svm/custom-jks
May 7, 2026
Merged

fix(backend): upgrade SVM client, add custom JKS#4130
GMishx merged 2 commits intoeclipse-sw360:mainfrom
siemens:feat/svm/custom-jks

Conversation

@GMishx
Copy link
Copy Markdown
Member

@GMishx GMishx commented May 6, 2026

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 cacerts file, which broke on non-Debian JDK installations (e.g. /opt/jdk-21.0.2/) where update-ca-certificates does 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:

  • Migrate SvmConnector and SVMUtils from Apache HttpClient 4.x / httpmime to HttpClient 5.x with non-deprecated TLS and response-handler APIs
  • Replace Log4j 1.x bridge with Log4j 2 in both classes
  • Extract all SVM TLS/HTTP-client logic into a new SvmHttpClientFactory that provides thread-safe singleton clients (one for one-way TLS, one for mutual TLS); files are resolved via CommonUtils.loadResource (/etc/sw360/ first, then classpath)
  • Fix bug where fetchComponentMappings and SVMUtils.prepareJSONRequest used HttpClients.createDefault(), bypassing any configured trust store
  • Add configurable JKS trust store (svm.sw360.truststore.filename/password); falls back to JVM default cacerts when not set
  • Add missing svm.sw360.componentmappings.api.url property; remove obsolete svm.sw360.jks.password
  • Remove stale URISyntaxException catch in SVMSyncHandler
  • Add docs/svm-ssl-truststore.md and website page with openssl s_client, keytool steps, and full sw360.properties reference

How To Test?

  1. Deploy SW360 with an SVM endpoint that uses a private CA certificate (e.g. svmtest.cert.siemens.com).
  2. Place the CA certificates in a JKS trust store at /etc/sw360/svm-truststore.jks (follow https://eclipse.dev/sw360/docs/administrationguide/vulnerabilitymanagement/svm-ssl-configuration/).
  3. Set in /etc/sw360/sw360.properties:
    svm.sw360.truststore.filename=svm-truststore.jks
    svm.sw360.truststore.password=changeit
  4. Trigger the SVM sync task — the PKIX path building failed error should no longer appear.
  5. Verify that SW360 starts normally without any SVM properties configured (SVM not in use) — no ExceptionInInitializerError should occur.
  6. Verify that fetchComponentMappings and vulnerability data fetches also succeed (they previously ignored the trust store).

Checklist

Must:

  • All related issues are referenced in commit messages and in PR
  • If code is AI-generated, mention the tool and model used (e.g., GitHub Copilot, GPT-4)

Code in this PR was developed with assistance from GitHub Copilot (GPT-4o).

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>
@GMishx GMishx force-pushed the feat/svm/custom-jks branch from 20d6ae4 to 4269cc3 Compare May 7, 2026 05:27
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>
@GMishx GMishx merged commit 7b99a4d into eclipse-sw360:main May 7, 2026
3 checks passed
@GMishx GMishx deleted the feat/svm/custom-jks branch May 7, 2026 09:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant