slachiewicz opened a new pull request, #2292: URL: https://github.com/apache/maven-resolver/pull/2292
Implements #2291: with `aether.connector.http.requestSigner=aws-sigv4` the Apache, JDK and Jetty transports sign every request with AWS Signature Version 4, so a plain `https://<endpoint>/<bucket>/<prefix>/` repository URL addresses S3 and S3-compatible stores through the regular HTTP transports, with everything they already have: HTTP/2, proxies, TLS settings, retries, origin-scoped headers and the `x-amz-meta-checksum-*` extraction. No new dependency. What is where: - `ConfigurationProperties` gains `requestSigner` (`none` or `aws-sigv4`), `aws.region` and `aws.service`, all under `aether.connector.http.` and with the usual repository-id suffix. With a signer active the repository username and password are the access key and secret key and are not sent as HTTP authentication; without repository authentication the `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and `AWS_SESSION_TOKEN` environment variables are used, and the region falls back to `AWS_REGION`, `AWS_DEFAULT_REGION`, then `us-east-1`. - `maven-resolver-util` gains the `HttpRequestSigner` interface, the `AwsSigV4RequestSigner` (about 200 lines, JDK crypto only) and `HttpTransporterUtils.getHttpRequestSigner`, which resolves the configuration and credentials. The payload is declared `UNSIGNED-PAYLOAD`, which S3 accepts and which keeps the transports from reading uploads twice. The path is signed in S3's canonical form, each segment decoded and URI-encoded once, not as the client sends it: the Apache client sends a literal `+` where the JDK and Jetty clients send `%2B`, S3 treats both as the same object, and signing the bytes as sent made the Apache integration test fail with 403 on exactly that case. - Each engine signs at the point where the final request exists and refuses to carry a signature across origins: Apache in the request executor, after the protocol interceptors set `Host` and after any redirect is resolved; JDK in `prepare` and again per redirect hop, which signed requests now always follow in the transporter so that each hop can be re-signed or stripped; Jetty in a headers listener that also sees the hops Jetty follows itself. Preemptive basic authentication and the engines' credential providers are disabled for the repository when a signer is active, proxy authentication is untouched. The signer is pinned to the AWS SDK: the unit test's expected signatures were produced with `AwsV4HttpSigner` from AWS SDK 2.57.11 for the same inputs, including a session token and an encoded path, so what the test accepts is what S3 accepts. Each engine has an integration test against an S3-compatible container (same image as the MinIO transporter's test) covering put, peek, get, an encoded path, a missing object classified as not found, and a wrong secret key classified as an error. Not covered: credential sources beyond static keys and environment variables (profile files, instance roles, SSO). Those are what the SDK's `auth` module is for, and the `HttpRequestSigner` interface leaves room for a signer that uses it. A repository URL with an explicit default port (`:443`) is signed with the port dropped, as the JDK and Jetty clients send it. Verified: `mvn -pl maven-resolver-transport-apache,maven-resolver-transport-jetty,maven-resolver-transport-jdk-parent/maven-resolver-transport-jdk11 -am -P run-its verify` on JDK 21 with Docker → BUILD SUCCESS; `AwsSigV4RequestSignerTest` 7/0/0 against the SDK vectors; spotless clean. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
