quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.
https://quarkus.io
Apache License 2.0
13.82k stars 2.69k forks source link

Quarkus tests fails mTLS authentication against internal Maven repository #15461

Closed tveon closed 1 year ago

tveon commented 3 years ago

Describe the bug Our internal Maven repository is using mTLS as part of the authentication, which requires a bit additional configuration of Maven. This configuration is, however, not picked up by the Quarkus bootstrapper, which then throws an exception when running test.

Expected behavior The javax.net.ssl.* properties from MAVEN_OPTS are successfully used to configure the HTTPS connection.

Actual behavior I hope, this is "clear and concise". 🙂

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.acme.getting.started.GreetingResourceTest
Downloading from tradeshift-public: https://maven.tradeshift.net/content/repositories/tradeshift-public/org/glassfish/jakarta.json/1.1.6/jakarta.json-1.1.6.pom
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.131 s <<< FAILURE! - in org.acme.getting.started.GreetingResourceTest
[ERROR] org.acme.getting.started.GreetingResourceTest.testHelloEndpoint  Time elapsed: 0.003 s  <<< ERROR!
java.lang.RuntimeException: io.quarkus.bootstrap.BootstrapException: Failed to create the application model for org.acme:getting-started::jar:1.0.0-SNAPSHOT
Caused by: io.quarkus.bootstrap.BootstrapException: Failed to create the application model for org.acme:getting-started::jar:1.0.0-SNAPSHOT
Caused by: io.quarkus.bootstrap.resolver.maven.BootstrapMavenException: Failed to resolve dependencies for org.acme:getting-started:jar:1.0.0-SNAPSHOT
Caused by: org.eclipse.aether.resolution.DependencyResolutionException: Failed to collect dependencies at io.quarkus:quarkus-junit5:jar:1.12.1.Final -> io.quarkus:quarkus-test-common:jar:1.12.1.Final -> io.quarkus:quarkus-jsonp-deployment:jar:1.12.1.Final -> io.quarkus:quarkus-jsonp:jar:1.12.1.Final -> org.glassfish:jakarta.json:jar:1.1.6
Caused by: org.eclipse.aether.collection.DependencyCollectionException: Failed to collect dependencies at io.quarkus:quarkus-junit5:jar:1.12.1.Final -> io.quarkus:quarkus-test-common:jar:1.12.1.Final -> io.quarkus:quarkus-jsonp-deployment:jar:1.12.1.Final -> io.quarkus:quarkus-jsonp:jar:1.12.1.Final -> org.glassfish:jakarta.json:jar:1.1.6
Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.glassfish:jakarta.json:jar:1.1.6
Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Could not transfer artifact org.glassfish:jakarta.json:pom:1.1.6 from/to tradeshift-public (https://maven.tradeshift.net/content/repositories/tradeshift-public): Transfer failed for https://maven.tradeshift.net/content/repositories/tradeshift-public/org/glassfish/jakarta.json/1.1.6/jakarta.json-1.1.6.pom
Caused by: org.eclipse.aether.transfer.ArtifactTransferException: Could not transfer artifact org.glassfish:jakarta.json:pom:1.1.6 from/to tradeshift-public (https://maven.tradeshift.net/content/repositories/tradeshift-public): Transfer failed for https://maven.tradeshift.net/content/repositories/tradeshift-public/org/glassfish/jakarta.json/1.1.6/jakarta.json-1.1.6.pom
Caused by: org.apache.maven.wagon.TransferFailedException: Transfer failed for https://maven.tradeshift.net/content/repositories/tradeshift-public/org/glassfish/jakarta.json/1.1.6/jakarta.json-1.1.6.pom
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Notice, that all dependencies to this point have been downloaded successfully, and it is also possible to run mvn quarkus:dev.

To Reproduce

Steps to reproduce the behavior:

  1. Configure Maven to use a repository using mTLS authentication
  2. Bootstrap any Quarkus project
  3. Run mvn test

Configuration N/A

Screenshots N/A - but see the stacktrace above.

Environment (please complete the following information):

Additional context 🤔

quarkus-bot[bot] commented 3 years ago

/cc @quarkusio/devtools

rquinio commented 3 years ago

You might try passing the javax.net.ssl.* system properties via Maven surefire plugin <systemPropertyVariables> ? Since QuarkusTests do a Maven resolution (directly using Aether, not via Maven CLI) of the augmentation classpath, I'd imagine surefire JVM settings are taken into account.

tveon commented 3 years ago

Nice, that actually "just worked". 👍

If anyone comes accros this later, then I add the following lines:

            <javax.net.ssl.keyStoreType>${javax.net.ssl.keyStoreType}</javax.net.ssl.keyStoreType>
            <javax.net.ssl.keyStore>${javax.net.ssl.keyStore}</javax.net.ssl.keyStore>
            <javax.net.ssl.keyStorePassword>${javax.net.ssl.keyStorePassword}</javax.net.ssl.keyStorePassword>

Depending on your exact setup, you might also need to add a trustStore...

famod commented 3 years ago

Great to hear to you could solve this via configuration!

@aloubyansky WDYT, should we add a hint to the documentation or just close this right away?

aloubyansky commented 3 years ago

It's worth to mention this in the docs. Not sure whether we can add support for it propagating these automatically.

famod commented 3 years ago

Not sure whether we can add support for it propagating these automatically.

I don't think so, unless we create a mojo that runs before surefire and somehow "injects" certain properties into it. But I think only Maven extensions can do that. ${maven.home} was added to the project generation etc. for the same reason.

aloubyansky commented 3 years ago

That's kind of what I was thinking about. Perhaps it doesn't have to be even a mojo. Extensions are enabled for quarkus-maven-plugin.

famod commented 3 years ago

I see one problem for multi-module projects in which you typically only have the quarkus-plugin in one (aggregating) module, but @QuarkusTest classes can exist in every module. You'd need to add the quarkus-plugin there as well (or in a common parent).

aloubyansky commented 3 years ago

Right. It should be documented first. Would you like to do that?

geoand commented 1 year ago

Is this still relevant?