Eclipse SSL trust management: no UI mechanism for temporary host trust exceptions

Eclipse's Communication Framework (ECF) and p2 update mechanism delegate all HTTPS certificate validation to the Java Runtime Environment's JSSE provider. The platform does not maintain a separate trust store nor expose a per-host trust exception UI, meaning certificate chain failures surface as PKIX path building errors regardless of whether the endpoint is a Marketplace update site, a Maven repository accessed through m2e, or a Git remote operated by EGit.

This design creates uncertainty for deployments in CI containers, corporate environments with custom JDK distributions, or scenarios involving MITM proxies that re-sign certificates with internal CAs. Error text varies across JRE vendors while the root cause remains a trust-store mismatch. Furthermore, the m2e connector may cache repository metadata from a previously successful connection, masking intermittent validation failures until cache expiry or a forced metadata refresh.

Given the project's current architecture, what would be required to implement a per-project or per-repository trust store preference within Eclipse's stack? How can distribution packages isolate SSL trust configuration from the host JRE without resorting to VM arguments or manual keytool imports? Is there a viable architectural path toward a UI-driven trust exception model that respects the platform's delegation model?