fix: bind credentials to origin and reject TLS downgrade redirects

[gnodet]

Summary

Fixes 5 findings from the maven-resolver security audit (scan-maven-resolver-20260811):

Finding	Severity	Description
f002	MEDIUM	Settings credentials attached by bare ID to POM-declared repositories
f008	MEDIUM	Apache transport silently follows https-to-http downgrade redirects
f009	MEDIUM	JDK transport Authenticator hands credentials to any challenging host
f016	MEDIUM	Jetty transport follows https-to-http redirects without a downgrade guard
f027	LOW	Operator-configured static auth headers follow redirects cross-origin

Root cause: Credential release decisions ignore where the request is actually going: selectors match on bare repository id with no host binding, authenticators answer any challenger, redirect handling follows cross-origin and https-to-http hops.

Fix: Enforce one rule across all transports: credentials go only to the configured origin, and https never silently becomes http.

Test plan

• Existing tests pass
• Credential scoping validated per transport
• TLS downgrade rejection tested

🤖 Generated with Claude Code

[cstamas]

LGTM, and a Q: URL transport does not need any change?

[gnodet]

Excellent security hardening across all three HTTP transports with comprehensive test coverage. The credential binding and TLS downgrade rejection are correctly implemented.

⚠️ @since tag corrections (12 locations)

All 12 @since tags across the PR say 2.0.22, but that version is already released (tag exists). They must be updated to @since 2.0.23 to match the milestone. Affected files:

• RemoteRepositoryManager.java (1)
• DefaultRemoteRepositoryManager.java (1)
• ApacheTransporterConfigurationKeys.java (2)
• OriginScopedHeadersInterceptor.java (1)
• ResolverRedirectStrategy.java (1)
• JdkTransporterConfigurationKeys.java (2)
• JettyTransporterConfigurationKeys.java (2)
• InsecureRedirectGuard.java (1)
• OriginScopedHeadersListener.java (1)

Minor observations (not blocking)

• JDK transport redirect error quality: When followableRedirect() returns null on HTTPS→HTTP downgrade, the raw 302 is returned, producing a generic HttpTransporterException(302). Apache's equivalent throws ProtocolException with an explicit message naming the config property. Consider matching the error quality for parity.
• effectivePort duplication: 5 near-identical implementations across modules. Cross-module dedup is constrained by different HTTP APIs, but within-module consolidation (Apache: 2 copies, JDK: 2 copies) is feasible.

Positive observations

• Credential scoping by scheme+host+port is correct across all transports
• Fail-closed on unknown target host
• Case-insensitive hostname and header comparisons
• Default port normalization prevents port-mismatch bypasses
• Descriptor-repository credential blocking correctly allows mirrored repos

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of gnodet

[gnodet]

@cstamas — good question. The URL transport (UrlTransporter) already has both guards built in:

1. TLS downgrade rejection (line 358–363): blocks HTTPS → HTTP redirects unless redirectAllowDowngrade is explicitly enabled (false by default)
2. Credential scoping on redirect (line 349–356): strips auth when the redirect target has a different authority

These were already part of the URL transport's redirect handling prior to this PR. The three transports that needed fixing were:

• Apache (f008): silently followed https→http downgrades
• JDK (f009): Authenticator handed credentials to any challenging host
• Jetty (f016): followed https→http redirects without a downgrade guard

The URL transport was already doing the right thing here.