Avoid dependency on netty-pkitesting #3634
Description
What is not easy to do right now?
Because zio-http depends on netty-pkitesting, it introduces a transitive dependency on the BouncyCastle provider. As a result, when running jdeps (for JPMS modularization), we encounter module-missing errors related to BouncyCastle. Moreover, we do not want to bundle unnecessary SSL-related dependencies like BouncyCastle in our production application.
Describe the solution you'd like
I would like netty-pkitesting to be used only in test or developer mode. Ideally, zio-http should:
- Move the certificate generation feature (SSLConfig.Generate) into a testkit or a separate module, or
- Mark netty-pkitesting as an optional/test scope dependency, so production users are not forced to include it.
This way, applications that need self-signed certificates for development can opt in, while production users can provide their own certificates without inheriting test-only dependencies.
Why is it important?
Including netty-pkitesting at runtime has several drawbacks:
- It brings test-only code and extra cryptographic providers into production builds unnecessarily.
- It breaks tools like jdeps and jlink unless additional manual steps are taken.
- It introduces potential security risks by encouraging the use of incomplete self-signed certificates (missing SAN, EKU, etc.) in production.
Separating or scoping this dependency properly will make zio-http easier to use in production, safer by default, and more modular.
Additional context
zio-http/project/Dependencies.scala
Line 31 in d8917d5
Netty maintainers have clarified that netty-pkitesting is only intended for testing PKI/TLS scenarios. Current zio-http code (SSLConfig.Generate) relies on it at runtime, which is what causes the issue.