Devcontainer: Java/Maven kan geen externe artifacts resolven achter de Huddle-proxy

[insuT0ver]

Samenvatting

In de Huddle-devcontainer kan geen enkele op de JVM gebaseerde tool (Maven, Gradle, IntelliJ Maven-import) externe artifacts ophalen. curl/apt werken wel. Het gevolg is dat Maven de Spring Boot BOMs niet kan resolven, met een cascade aan dependencies.dependency.version is missing-fouten en — in IntelliJ — misleidende symptomen zoals modules die op "JVM target 5" terugvallen (onopgeloste Maven-modules vallen terug op defaults).

Elke ontwikkelaar raakt dit bij een verse container en moet het handmatig omzeilen. Graag structureel oplossen in het image/platform.

Impact

• Nieuwe/verse devcontainers zijn niet in staat het project te bouwen zonder handmatige workaround.
• Symptomen zijn misleidend (lijkt een pom-/IntelliJ-configfout, is in werkelijkheid proxy/CA/DNS).
• Een tijdelijke netwerkblip "vergiftigt" ~/.m2 (gecachete .lastUpdated), waardoor het probleem dagen aanhoudt.

Omgeving

• Devcontainer met alle verkeer via de Huddle DMZ-proxy: HTTP_PROXY/HTTPS_PROXY/JAVA_TOOL_OPTIONS → huddle:80.
• Directe DNS naar externe hosts faalt ("Temporary failure in name resolution"); alles moet via de proxy.
• Proxy doet TLS-interceptie met eigen root-CA: CN=Huddle DMZ Proxy Root CA, O=Huddle.
• JDK: ~/.jdks/ms-21.0.11 (geen mvn op PATH, JAVA_HOME niet gezet).

Reproductie

1. Verse Huddle-devcontainer starten.
2. In een Maven-project (Java 21, Spring Boot) mvn -U validate draaien of in IntelliJ "Reload All Maven Projects".
3. Resultaat: Non-resolvable import POM ... spring-boot-dependencies + PKIX path building failed: unable to find valid certification path.

Oorzaakanalyse (3 gestapelde problemen)

1. JDK vertrouwt de proxy-CA niet. huddle-ca.crt staat wel in de systeem-CA-bundle (/usr/local/share/ca-certificates/, dus curl werkt), maar niet in de JDK-truststore ($JAVA_HOME/lib/security/cacerts) → PKIX path building failed in alle JVM-tools.
2. Maven gebruikt de proxy niet. De proxy-props in JAVA_TOOL_OPTIONS worden door Maven's artifact-resolver genegeerd; er is geen ~/.m2/settings.xml met een <proxies>-blok, dus Maven probeert central direct te DNS-resolven en faalt.
3. Gecachete faalstatus. Een tijdelijke blip laat Maven de mislukking cachen (.lastUpdated); het wordt pas na het update-interval opnieuw geprobeerd.

Voorgestelde oplossing (geprioriteerd)

P1 — Interne Maven-mirror (Artifactory/Nexus) — grootste hefboom

Zet een interne repository-mirror neer met een geldig (intern vertrouwd) TLS-cert en configureer die als <mirror> in een meegeleverde settings.xml. Dit lost CA-, DNS- én cache-fragiliteit grotendeels in één keer op: geen TLS-interceptie van Maven Central meer nodig, geen externe DNS-afhankelijkheid per build, betrouwbaardere en snellere resolves.

P2 — Minimale image-fixes (als P1 op korte termijn niet haalbaar is)

a. Proxy-CA importeren in élke JDK-truststore (bij image-build), bijv.:

for jdk in /home/vscode/.jdks/*/; do
  keytool -importcert -noprompt \
    -keystore "$jdk/lib/security/cacerts" -storepass changeit \
    -alias huddle-dmz-proxy-root-ca \
    -file /usr/local/share/ca-certificates/huddle-ca.crt || true
done

Robuuster alternatief: één centrale truststore + -Djavax.net.ssl.trustStore=... via JAVA_TOOL_OPTIONS, zodat het niet per JDK-installatie hoeft.

b. Globale ~/.m2/settings.xml meeleveren met proxy-config:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0">
  <proxies>
    <proxy>
      <id>huddle-http</id><active>true</active><protocol>http</protocol>
      <host>huddle</host><port>80</port>
      <nonProxyHosts>localhost|127.*|[::1]</nonProxyHosts>
    </proxy>
    <proxy>
      <id>huddle-https</id><active>true</active><protocol>https</protocol>
      <host>huddle</host><port>80</port>
      <nonProxyHosts>localhost|127.*|[::1]</nonProxyHosts>
    </proxy>
  </proxies>
</settings>

P3 — Ergonomie / robuustheid

• JAVA_HOME zetten en een mvn op PATH beschikbaar maken.
• Controleer nonProxyHosts op interne hosts (voorkom dat interne services onnodig door de proxy gaan).
• Overweeg CI standaard met -U te draaien en .m2 niet over een blip heen te persisteren.

Definition of Done

• Verse Huddle-devcontainer kan mvn -U validate op een Spring Boot / Java 21-project draaien en IntelliJ "Reload All Maven Projects" slaagt, zónder handmatige CA-import of settings.xml.
• Geen PKIX- of Non-resolvable import POM-fouten meer bij een verse container.

Huidige workaround (ter referentie)

1. CA in JDK-truststore importeren (keytool ... -cacerts).
2. ~/.m2/settings.xml met <proxies> naar huddle:80 aanmaken.
3. find ~/.m2/repository -name "*.lastUpdated" -delete en -U draaien.