slachiewicz opened a new issue, #2291: URL: https://github.com/apache/maven-resolver/issues/2291
Design proposal, the longer-term half of #2289. #2290 adds an S3 transport on the AWS SDK for 2.0.x; this is about not needing an S3 transport at all. ## Observation Over HTTPS with path-style access, an S3 bucket is an ordinary HTTP repository. `https://host/bucket/prefix/` is a valid resolver base URL, GET, HEAD and single PUT (up to 5 GB) are the only operations a repository transport performs, and the object name mappers of the MinIO and S3 transports exist only because an SDK client takes bucket and key as separate arguments. The one thing the HTTP transports lack is the authentication scheme: S3 wants each request signed with Signature Version 4. SigV4 is engine-neutral. From method, URL, a few headers, a payload hash (`UNSIGNED-PAYLOAD` is allowed over TLS), access key, secret key, optional session token, region and time, it produces three or four request headers: `Authorization`, `x-amz-date`, `x-amz-content-sha256` and, with temporary credentials, `x-amz-security-token`. ## What it would take 1. A request-signer SPI next to the existing `org.eclipse.aether.spi.connector.transport.http` types: given the request's method, URI and headers, return the headers to add. Transporters call it right before sending, after their own headers are set. 2. One implementation, `aws-sigv4`, selected through the repository's authentication context (for example a custom `aws.region` key, with username and password as access and secret key, as the S3 transports already do). The signing itself is about two hundred lines; alternatively `software.amazon.awssdk:http-auth-aws` (180 KB plus its SPI jars) can do it. Credential sources beyond static keys and environment variables (profile files, instance roles, SSO) are what the SDK's `auth` module provides and could stay an optional dependency. 3. A hook in each of the three HTTP engines: an interceptor in the Apache client, the request build in the JDK transporter where the preemptive `Authorization` header is set today, and a request listener in Jetty. The `url` transport is GET and HEAD only and can be left out. ## What it buys - No S3 module and no SDK on the classpath: the S3 case becomes documentation plus one authentication type. - S3 repositories get everything the HTTP transports already have and the SDK path does not: HTTP/2, proxies, the TLS settings, retries, origin-scoped headers and redirects, transport listeners, and the included-checksum extraction that `XChecksumExtractor` already implements for `x-amz-meta-checksum-*`. - Users of `s3+https` and `minio+https` URLs migrate by changing the URL to the path-style HTTPS form and setting the authentication type; the bucket moves from a configuration key into the URL. ## Open points - Error semantics: some stores answer HEAD on a missing bucket with 403 rather than 404; the transports already treat 404 as not found and anything else as an error, which matches what the S3 transport does. - Whether region should default to `us-east-1` for non-AWS endpoints, as #2290 does, or be mandatory for the scheme. - Multipart upload is not needed for artifacts, but the limit should be stated. If this direction is agreed, #2290 ships as the 2.0.x solution and this replaces it in 2.1 together with the removal of the MinIO module. -- 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]
