Skip to content
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

Improvement: create truststore based on jvm default truststore and extend with the one defined explicit #92

Open
truthslie opened this issue Dec 13, 2024 · 2 comments

Comments

@truthslie
Copy link

As far as I understand this plugin is able to create a new truststore with certs defined in the source-folder. This is good. However a common use case also "I need a trust store with the default certs as well as the one defined in my source-folder". Does it makes sense to extend this plugin for this use case?

See also:
https://www.baeldung.com/java-custom-truststore

Additionally:
As the truststore do not contain any secret data, setting a password should be optional (this works out of the box in JDK18, see https://bugs.openjdk.org/browse/JDK-8274862, https://github.com/marschall/truststore-maven-plugin?tab=readme-ov-file#passwordless-truststores

@chkpnt
Copy link
Owner

chkpnt commented Dec 22, 2024

Thank you for your suggestions.

There are no "default certs", so they can't be included. The cacert file used by Java depends on the Java distribution, so e.g. Temurin uses a different set of root CAs to Corretto. Also, if you are using a JDK/JRE packaged by/for a Linux distribution, the cacert is usually replaced by the set of root CAs that the Linux distribution includes.
This plugin is typically used in a CI environment, so the cacert file at build time may be completely different from what you expect at runtime on the target system.
But of course you could use the cacert file of your choice and extract the certificates to a pem file which the plugin can process.
In my projects, where the Java processes need to connect to any server on the Internet, I prefer to include the TrustStore managed by Mozilla.
If you want to include the download of this truststore in your Gradle build script, you could do something like this

repositories {
    exclusiveContent {
        forRepository {
            ivy {
                url = uri("https://curl.se/ca/")
                patternLayout {
                    artifact("cacert.pem")
                }
                metadataSources {
                    artifact()
                }
            }
        }
        filter {
            includeModule("mozilla", "truststore")
        }
    }
}

val cacerts by configurations.creating

dependencies {
    cacerts("mozilla:truststore:cacert@pem")
}

val copyMozillaTrustStore by tasks.registering(Copy::class) {
    from(cacerts)
    into("src/main/certs")
}

Regarding your second suggestion: This makes perfect sense. But does it mean that the plugin would need Java 18 as a requirement? Puh...

@truthslie
Copy link
Author

Hey @chkpnt , thank you for your quick response. I admit, that the default truststore of the jvm of the gradle process calling this plugin is by default not the same as the truststore of the runtime environment. In general there is a problem of "the truststore used might by outdated because it's defined at build time which might be built years before". So I guess there is no quick solution to my use case "accept what you usually accept but also particular the certs I provide as ressources". Sounds like a runtime feature not like a build time feature on a second thought

As for the passwordless truststore extenstion: I don't see a problem with JDK 18 if you make "passwordless" optional. Of course it would be nice to document the restriction that the option can only be used with JDK18+

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

No branches or pull requests

2 participants