From 34470308edbba07787d040c7a73e6678f98e45eb Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Thu, 6 Aug 2026 10:29:20 +0000 Subject: [PATCH 01/24] docs: rewrite expected-checksums.md to STE rules --- src/site/markdown/expected-checksums.md | 175 ++++++++---------------- 1 file changed, 55 insertions(+), 120 deletions(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index 4250313e1..522f048fe 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -18,155 +18,99 @@ specific language governing permissions and limitations under the License. --> -Checksums in Resolver were historically used during transport, -to ensure Artifact integrity. In addition, latest Resolver may -use checksums in various other ways too, for example to ensure -Artifact integrity during resolution. +In the past, Resolver used checksums during transport to verify that the artifact is intact. The latest Resolver also uses checksums in other ways. For example, it verifies that the artifact is intact during resolution. -The bare essence of all checksum uses in Resolver is -"integrity validation": Resolver calculates by various -means the "calculated" checksum (for given payload), -then obtains somehow the "expected" checksum (for same payload) -and compares the two. +All checksum uses in Resolver have one purpose. That purpose is integrity verification. Resolver calculates the "calculated" checksum for a payload. Then it gets the "expected" checksum for the same payload. Then it compares the two checksums. -The "calculated" checksum is uninteresting from technical viewpoint, -as it is calculated by standard means: either during payload -streaming, or in worst case, from file already present on local -file system (transport dependant). +The "calculated" checksum is not important from the technical viewpoint. Resolver calculates it by standard means. Resolver calculates it during the payload stream. Or it calculates it from a file already present on the local file system. The calculation method depends on the transport. -Instead, this page covers all the "expected" checksum varieties. +This page covers all the "expected" checksum varieties. ## Transport Checksum Strategies -Historically, the "obtain expected checksum" was implemented as simple -request against Artifact checksum URL (Artifact URL appended by ".sha1"). This logic -is still present in current Resolver, but is "decorated" and extended in multiple -ways. - -Resolver has broadened the "obtain checksum" step for "expected" checksum with two new strategies, -so the three expected checksum kinds in transport are: "Provided", "Remote Included" and -"Remote External". All these strategies provide the source of "expected" checksum, -but it differs **how** Resolver obtains these. - -The new **Provided** kind of expected checksums are provided to resolver by some alternative -means, possibly ahead of any transport operation. There is an SPI extension point that users may -implement, to have own ways to provide checksums to resolver. Alternatively, one may use Resolver out of the -box implementation, that simply delegates "provided checksums" to "trusted checksums" (more about them later). - -The new **Remote Included** checksums are in some way included by remote party, typically -in their response. Since advent of modern Repository Managers, most of -them already sends checksums (usually the "standard" SHA-1 and MD5) -in their response headers. Moreover, Maven Central, and even Google Mirror of Maven Central -sends them as well. By extracting these checksums from response, we can get hashes -that were provided by remote repository along with its content. This saves one HTTP round-trip, as we -got both, content and checksums in one response. - -Finally, the **Remote External** checksums are the "classic" checksums we all know: They are laid down -next to Artifact files, external in other words on the remote repository, according -to remote repository layout. To obtain Remote External checksum, new HTTP request against remote repository is -required. The order of requested checksums will follow the order given in layout configuration, -asking for checksums in same order as the parameter contains algorithm names. - -During single artifact retrieval, these strategies are executed in above specified order, -and only if current strategy has "no answer", the next strategy is attempted. Hence, if -resolver is able to get "expected" checksum from Provided Checksum Source, the Remote Included -and Remote External sources will not be consulted. Important implication: given that almost -all MRMs and remote repositories (Maven Central, Google Mirror of Maven Central) send "standard" (SHA-1, MD5) -checksums in their response, if any of the standard checksum are enabled, validation will -be probably satisfied by "Remote Included" strategy and "Remote External" will be skipped. - -The big win here is that by obtaining hashes using "Remote Included" and not by "Remote External" -strategy, we can halve the count of HTTP requests to download an Artifact. +In the past, Resolver got the expected checksum with a request to the artifact checksum URL. The artifact checksum URL is the artifact URL with ".sha1" appended. This logic is still present in the current Resolver. The current Resolver extends this logic in several ways. + +Resolver added two new strategies to the "obtain checksum" step. The three expected checksum kinds in transport are "Provided", "Remote Included", and "Remote External". All the strategies provide the source of the expected checksum. The strategies differ in **how** Resolver gets the checksum. + +The **Provided** checksums come to Resolver by some alternative means. The checksums can arrive before any transport operation. Users can implement an SPI extension point. The extension point gives users their own way to provide checksums. + +Users can also use the Resolver implementation that comes with Resolver. The implementation delegates the provided checksums to the trusted checksums. The section "Trusted Checksums" describes them. + +The remote party includes the **Remote Included** checksums in its response. Most modern repository managers send checksums in the response headers. The checksums are usually the standard SHA-1 and MD5. Maven Central sends them as well. The Google Mirror of Maven Central sends them too. + +Resolver extracts the checksums from the response. Then it gets the hashes that the remote repository provided with the content. This saves one HTTP round-trip. Resolver gets the content and the checksums in one response. + +The **Remote External** checksums are the classic checksums. The remote repository stores them next to the artifact files. The layout of the remote repository defines the storage position. To get a Remote External checksum, send a new HTTP request to the remote repository. The order of the requested checksums follows the order in the layout configuration. Resolver asks for the checksums in the same order as the parameter contains the algorithm names. + +During one artifact retrieval, Resolver runs the strategies in the order above. If the current strategy has no answer, Resolver tries the next strategy. If Resolver gets the expected checksum from the Provided source, it does not consult the Remote Included and Remote External sources. + +Almost all repository managers and remote repositories send the standard checksums in their response. These repositories include Maven Central and the Google Mirror of Maven Central. If any standard checksum is enabled, the Remote Included strategy usually satisfies the verification. Then Resolver skips the Remote External strategy. + +If Resolver gets the hashes with the Remote Included strategy, it halves the number of HTTP requests to download an artifact. Related configuration keys: -* `aether.layout.maven2.checksumAlgorithms` A comma-separated list of checksum algorithms. Order is important, as - transport will ask for those in specified order (default is "SHA-1,MD5"), and first received and matched causes - integrity validation algorithm to stop. +* `aether.layout.maven2.checksumAlgorithms` A comma-separated list of checksum algorithms. The order is important. The transport asks for the checksums in the specified order. The default is "SHA-1,MD5". The first received and matched checksum stops the integrity verification algorithm. -Note: Since Maven 3.9.x you can use expression `${session.rootDirectory}/.mvn/checksums/` to store checksums along with -sources as `session.rootDirectory` will become an absolute path pointing to the root directory of your project (where -usually the `.mvn` directory is). +Note: Since Maven 3.9.x you can use the expression `${session.rootDirectory}/.mvn/checksums/` to store checksums along with sources. `session.rootDirectory` becomes an absolute path. The path points to the root directory of your project. The `.mvn` directory is usually in the root directory. ### Provided Checksums -There is a Resolver SPI `ProvidedChecksumsSource` that makes possible to feed Provided Checksums to Resolver ahead -of actual transport. These checksums are used **during transport only** to verify transported payload (artifacts) -integrity. Hence, Provided checksums are NOT usable to verify already cached artifacts integrity (unless you build -with empty repository, of course, that forces all of your artifact go through transport). +The Resolver SPI `ProvidedChecksumsSource` feeds the Provided Checksums to Resolver before the actual transport. Resolver uses these checksums only during transport. It uses them to verify the integrity of the transported payload. The Provided checksums cannot verify the integrity of cached artifacts. If you build with an empty repository, all your artifacts go through transport. Then the Provided checksums can verify them. -Resolver out of the box provides one SPI implementation: one that simply delegates to "trusted checksums". +Resolver provides one SPI implementation with the distribution. The implementation delegates to the trusted checksums. ### Remote Included Checksums -**Note: Remote Included checksums work only with transport-http, they do NOT work with transport-wagon!** +**Note:** Remote Included checksums work only with transport-http. They do not work with transport-wagon. -By using "Remote Included" checksum feature, we are able to halve the issued HTTP request -count, since many repository services along Maven Central emits the reference checksums in -the artifact response itself (as HTTP headers). Hence, we are able to get the -artifact and reference "expected" checksum using only one HTTP round-trip. +Many repository services emit the reference checksums in the artifact response. Maven Central is one of these services. The service emits the checksums as HTTP headers. The Remote Included feature halves the number of HTTP requests. Resolver gets the artifact and the expected checksum with one HTTP round-trip. Related configuration keys: * `aether.connector.basic.smartChecksums` to enable or disable Remote Included checksums. -The Remote Included checksums support several "strategies" to extract checksums from HTTP response header. +The Remote Included checksums support several "strategies" to extract checksums from the HTTP response header. #### Sonatype Nexus 2 -Sonatype Nexus 2 uses SHA-1 hash to generate `ETag` header in "shielded" (à la Plexus Cipher) -way. Naturally, this means only SHA-1 is available in artifact response header. +Sonatype Nexus 2 generates the `ETag` header from a SHA-1 hash. It shields the hash in the Plexus Cipher style. Only SHA-1 is available in the artifact response header. Emitted by: Sonatype Nexus2 only. #### Non-standard `X-` headers -Maven Central emits headers `x-checksum-sha1` and `x-checksum-md5` along with artifact response. -Google GCS on the other hand uses `x-goog-meta-checksum-sha1` and `x-goog-meta-checksum-md5` -headers. AWS S3 uses `x-amz-meta-checksum-sha1` and `x-amz-meta-checksum-md5` headers. -Resolver will detect all these and use their value. +Maven Central emits the headers `x-checksum-sha1` and `x-checksum-md5` along with the artifact response. Google GCS uses the headers `x-goog-meta-checksum-sha1` and `x-goog-meta-checksum-md5`. AWS S3 uses the headers `x-amz-meta-checksum-sha1` and `x-amz-meta-checksum-md5`. Resolver detects all these headers and uses their values. Emitted by: Maven Central, GCS, AWS S3, some CDNs and probably more. ### Remote External checksums -These are the "classic" checksums existing since Maven 1. They are laid on layout in the remote repository, next -to the payload file (i.e. "lib.jar" and checksum "lib.jar.sha1"). While they are the oldest kind of Resolver checksums, -their shortcoming is that most often only SHA-1 and MD5 are produced. Basically, consumer is tied to those checksum -algorithms only, that are provided by remote repository. Similarly, given both, the payload and the checksum comes -from same origin, unless the origin is trusted (like Maven Central is), it may be seen as a risk. +The Remote External checksums are the classic checksums. They exist since Maven 1. The remote repository stores them next to the payload file. For example, it stores "lib.jar" and the checksum "lib.jar.sha1". They are the oldest kind of Resolver checksums. + +Their shortcoming is that only SHA-1 and MD5 are often produced. The consumer is tied to the checksum algorithms that the remote repository provides. The payload and the checksum come from the same origin. If the origin is not trusted, this can be a risk. Maven Central is an example of a trusted origin. ## Trusted Checksums -All the "expected" checksums discussed above are used in transport only, they are all -about URLs, HTTP requests and responses, or require Transport related API elements. +All the expected checksums above are used only in transport. They relate to URLs, HTTP requests, and HTTP responses. Or they require transport related API elements. + +`TrustedChecksumsSource` is an SPI component. It delivers the expected checksums for an artifact. It does not use any transport API element. This API is not bound to transport. It is generic. + +The trusted checksums map almost one-to-one into the Provided strategy. Resolver provides an implementation that delegates the Provided checksums to the Trusted checksums. The Provided and Trusted checksums become equivalent for transport. -`TrustedChecksumsSource` is a SPI component that is able to deliver "expected" checksums -for given Artifact, without use of any transport API element. In other words, this -API is not bound to transport, but is generic. +The biggest advantage of Trusted Checksums is their transport independence. They work in places where there is no transport. One use of Trusted Checksums is the ArtifactResolver post-processing. -Since they map almost one-to-one into transport "Provided Checksum" strategy, resolver provides -implementation that delegates Provided to Trusted checksums (makes Provided and Trusted -checksums equivalent, transport-wise). +This functionality verifies all the resolved artifacts against the Trusted Checksums. It costs checksum calculation overhead. The user provides a known checksum. The checksum can be cryptographically strong. -But the biggest game changer of Trusted Checksums is their transport independence, that they -can be utilized in places where there is no transport happening at all. One of such uses of -Trusted Checksums is ArtifactResolver post-processing. -This new functionality, at the cost of checksum calculation overhead, is able to validate all -the resolved artifacts against Trusted Checksums, thus, making sure that all resolved -artifacts are "validated" with some known (possibly even cryptographically strong) checksum -provided by user. This new feature may become handy in cases when user cannot trust the local -repository, as it may be shared with some other unknown or even untrusted parties. +The functionality can help when the user cannot trust the local repository. An unknown or untrusted party can share the local repository. -Moreover, using Resolver Trusted Checksum post-processor, one can "record" the checksums, -for example when executed in a known "pristine" and safe environment, and reuse the produced -checksum to distribute within organization. +You can record the checksums with the Trusted Checksum post-processor. For example, run it in a known and safe environment. Then distribute the produced checksum within your organization. -The Trusted Checksums provide two source implementations out of the box. +The Trusted Checksums distribution provides two source implementations. Related configuration keys: * `aether.trustedChecksumsSource.*` @@ -174,15 +118,13 @@ Related configuration keys: ### Summary File Trusted Checksums Source -The summary file source uses single file that is in GNU coreutils compatible format: each -line contains the hash and relative path of artifact from local repository basedir. +The summary file source uses one file. The file is compatible with the GNU coreutils format. Each line contains the hash and the relative path of an artifact. The path is relative to the local repository basedir. -The file can be produced using common OS and GNU coreutils `sha1sum` command line tools, -and the same tools can be also used to "batch verify" the enlisted artifacts in local repository. +You can produce the file with the `sha1sum` command line tool. GNU coreutils provides this tool. You can use the same tools to verify the artifacts in the local repository in a batch. -Each summary file contains information for single checksum algorithm, represented as summary file extension. +Each summary file contains information for one checksum algorithm. The file extension represents the algorithm. -If you are using Maven 3.9.x, use the following procedure to save the summary checksum file alongside your project code: +If you use Maven 3.9.x, use the following procedure to save the summary checksum file alongside your project code: 1. Add the following command line flags to your `.mvn/config` file: @@ -202,7 +144,7 @@ If you are using Maven 3.9.x, use the following procedure to save the summary ch mvn clean install -Daether.artifactResolver.postProcessor.trustedChecksums.record=true ``` - This will generate one or more checksum files (one for each source Maven repository) with the `.sha512` extension. + The build generates one or more checksum files with the `.sha512` extension. Each source Maven repository generates one file. 3. Verify that the build succeeds with trusted checksum recording disabled: @@ -212,19 +154,12 @@ If you are using Maven 3.9.x, use the following procedure to save the summary ch ### Sparse Directory Trusted Checksums Source -This source mimics Maven local repository layout, and stores checksums in similar layout -as Maven local repository stores checksums in local repository. +This source mimics the Maven local repository layout. It stores the checksums in a similar layout. -Here, just like Maven local repository, the sparse directory can contain multiple algorithm checksums, -as they are coded in checksum file path (the extension). +The sparse directory can contain checksums for multiple algorithms. The file extension encodes the algorithm. ### Notes On Using Trusted Checksums -- Use the `--strict-checksums` flag to fail a build if the expected checksums of downloaded - artifacts do not match. -- More than one checksum algorithm can be specified for the - `aether.artifactResolver.postProcessor.trustedChecksums.checksumAlgorithms` system property. The - listed checksums must be a subset of those specified by `aether.checksums.algorithms`. -- Most dependency management tools do not currently update trusted checksum files if they are - stored in version control alongside source code. We hope maintainers of these tools support - Maven trusted checksums in the near future. +- Use the `--strict-checksums` flag to fail a build if the expected checksums of the downloaded artifacts do not match. +- You can specify more than one checksum algorithm for the `aether.artifactResolver.postProcessor.trustedChecksums.checksumAlgorithms` system property. The listed checksums must be a subset of the checksums in `aether.checksums.algorithms`. +- Most dependency management tools do not update trusted checksum files. This is true if the files are stored in version control alongside the source code. We hope that the maintainers of these tools support Maven trusted checksums in the near future. From d97b4cf6128095244fb08107d714c3f5adba701e Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Thu, 6 Aug 2026 10:31:22 +0000 Subject: [PATCH 02/24] present > history --- src/site/markdown/expected-checksums.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index 522f048fe..2c7154b0d 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -18,7 +18,7 @@ specific language governing permissions and limitations under the License. --> -In the past, Resolver used checksums during transport to verify that the artifact is intact. The latest Resolver also uses checksums in other ways. For example, it verifies that the artifact is intact during resolution. +Resolver uses checksums during transport to verify that the artifact is intact. The latest Resolver also uses checksums in other ways. For example, it verifies that the artifact is intact during resolution. All checksum uses in Resolver have one purpose. That purpose is integrity verification. Resolver calculates the "calculated" checksum for a payload. Then it gets the "expected" checksum for the same payload. Then it compares the two checksums. From 7afa8db3b645fbb4a3696a7b2fcc2c091502ed9c Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Thu, 6 Aug 2026 10:33:59 +0000 Subject: [PATCH 03/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index 2c7154b0d..4f5e7b747 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -22,7 +22,7 @@ Resolver uses checksums during transport to verify that the artifact is intact. All checksum uses in Resolver have one purpose. That purpose is integrity verification. Resolver calculates the "calculated" checksum for a payload. Then it gets the "expected" checksum for the same payload. Then it compares the two checksums. -The "calculated" checksum is not important from the technical viewpoint. Resolver calculates it by standard means. Resolver calculates it during the payload stream. Or it calculates it from a file already present on the local file system. The calculation method depends on the transport. +Resolver calculates a checksum for the bytes of an artifact using a standard algorithm. It can read the bytes and calculate the checksum during the download or from a file already present on the local file system. The calculation method depends on the transport. This page covers all the "expected" checksum varieties. From b69467a4e069ef14ba33196cbe82c96c643141bf Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Thu, 6 Aug 2026 10:34:39 +0000 Subject: [PATCH 04/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index 4f5e7b747..a68bcab39 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -22,7 +22,7 @@ Resolver uses checksums during transport to verify that the artifact is intact. All checksum uses in Resolver have one purpose. That purpose is integrity verification. Resolver calculates the "calculated" checksum for a payload. Then it gets the "expected" checksum for the same payload. Then it compares the two checksums. -Resolver calculates a checksum for the bytes of an artifact using a standard algorithm. It can read the bytes and calculate the checksum during the download or from a file already present on the local file system. The calculation method depends on the transport. +Resolver calculates a checksum for the bytes of an artifact using a standard algorithm. It can read the bytes and calculate the checksum during the download or from a file already present on the local file system. This page covers all the "expected" checksum varieties. From 241f01c187c7c885d327cfb2172cc5ebaac45bf5 Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Thu, 6 Aug 2026 10:40:43 +0000 Subject: [PATCH 05/24] examples --- src/site/markdown/expected-checksums.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index a68bcab39..13f7119ca 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -29,9 +29,9 @@ This page covers all the "expected" checksum varieties. ## Transport Checksum Strategies -In the past, Resolver got the expected checksum with a request to the artifact checksum URL. The artifact checksum URL is the artifact URL with ".sha1" appended. This logic is still present in the current Resolver. The current Resolver extends this logic in several ways. +In the past, Resolver got the expected checksum from the artifact checksum URL. This is the artifact URL with am algorithm extension like ".sha1" appended. For example, if the artifact URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar then the SHA-1 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.sha1 and the MD5 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.md5. This logic is still present. The current Resolver extends this logic in several ways. -Resolver added two new strategies to the "obtain checksum" step. The three expected checksum kinds in transport are "Provided", "Remote Included", and "Remote External". All the strategies provide the source of the expected checksum. The strategies differ in **how** Resolver gets the checksum. +Resolver added two new strategies to the "obtain checksum" step. The three expected checksum kinds in transport are "Provided", "Remote Included", and "Remote External". All three strategies provide the source of the expected checksum. The strategies differ in **how** Resolver gets the checksum. The **Provided** checksums come to Resolver by some alternative means. The checksums can arrive before any transport operation. Users can implement an SPI extension point. The extension point gives users their own way to provide checksums. From a2e266cb50db86e84cd2713503f276e956edc6e0 Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Thu, 6 Aug 2026 10:41:11 +0000 Subject: [PATCH 06/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index 13f7119ca..f03c40e47 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -20,7 +20,7 @@ under the License. Resolver uses checksums during transport to verify that the artifact is intact. The latest Resolver also uses checksums in other ways. For example, it verifies that the artifact is intact during resolution. -All checksum uses in Resolver have one purpose. That purpose is integrity verification. Resolver calculates the "calculated" checksum for a payload. Then it gets the "expected" checksum for the same payload. Then it compares the two checksums. +Checksums in Resolver have one purpose. That purpose is integrity verification. Resolver calculates the "calculated" checksum for a payload. Then it gets the "expected" checksum for the same payload. Then it compares the two checksums. Resolver calculates a checksum for the bytes of an artifact using a standard algorithm. It can read the bytes and calculate the checksum during the download or from a file already present on the local file system. From 5ca91d96bddfc00c70ac931e28a4524098edb638 Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Thu, 6 Aug 2026 10:46:24 +0000 Subject: [PATCH 07/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index f03c40e47..352854930 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -20,9 +20,9 @@ under the License. Resolver uses checksums during transport to verify that the artifact is intact. The latest Resolver also uses checksums in other ways. For example, it verifies that the artifact is intact during resolution. -Checksums in Resolver have one purpose. That purpose is integrity verification. Resolver calculates the "calculated" checksum for a payload. Then it gets the "expected" checksum for the same payload. Then it compares the two checksums. +Checksums in Resolver have one purpose: integrity verification. Resolver determines the "calculated" checksum for an artifact by applying a mathematical algorithm to the local copy of the artifact. Then it retrieves the "expected" checksum for the same artifact from he same source it got the artifact from. Then it compares the two checksums. -Resolver calculates a checksum for the bytes of an artifact using a standard algorithm. It can read the bytes and calculate the checksum during the download or from a file already present on the local file system. +Resolver calculates a checksum from the bytes of an artifact using a standard algorithm. It can read the bytes and calculate the checksum during the download or from a file already present on the local file system. This page covers all the "expected" checksum varieties. From c647ba381bf038f7da6d6f82a575ab72185c6351 Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Thu, 6 Aug 2026 10:47:04 +0000 Subject: [PATCH 08/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index 352854930..c643581e7 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -29,7 +29,7 @@ This page covers all the "expected" checksum varieties. ## Transport Checksum Strategies -In the past, Resolver got the expected checksum from the artifact checksum URL. This is the artifact URL with am algorithm extension like ".sha1" appended. For example, if the artifact URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar then the SHA-1 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.sha1 and the MD5 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.md5. This logic is still present. The current Resolver extends this logic in several ways. +In the past, Resolver got the expected checksum from the artifact checksum URL. This is the artifact URL with an algorithm extension like ".sha1" appended. For example, if the artifact URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar then the SHA-1 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.sha1 and the MD5 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.md5. This logic is still present. The current Resolver extends this logic in several ways. Resolver added two new strategies to the "obtain checksum" step. The three expected checksum kinds in transport are "Provided", "Remote Included", and "Remote External". All three strategies provide the source of the expected checksum. The strategies differ in **how** Resolver gets the checksum. From 8a3d4a0dd1915527c3fa741c98a210d9c61c3784 Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Thu, 6 Aug 2026 11:11:08 +0000 Subject: [PATCH 09/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 47 +++++++++++-------------- 1 file changed, 20 insertions(+), 27 deletions(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index c643581e7..3b3f280fc 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -18,22 +18,20 @@ specific language governing permissions and limitations under the License. --> -Resolver uses checksums during transport to verify that the artifact is intact. The latest Resolver also uses checksums in other ways. For example, it verifies that the artifact is intact during resolution. +Resolver uses checksums during transport to verify that the artifact is intact. The latest Resolver also uses checksums at other times. For example, it verifies that the artifact is intact during resolution. -Checksums in Resolver have one purpose: integrity verification. Resolver determines the "calculated" checksum for an artifact by applying a mathematical algorithm to the local copy of the artifact. Then it retrieves the "expected" checksum for the same artifact from he same source it got the artifact from. Then it compares the two checksums. +Checksums in Resolver have one purpose: integrity verification. Resolver determines the "calculated" checksum for an artifact by applying a mathematical algorithm to its local copy of the artifact. It can read the bytes and calculate the checksum during the download or from a file already present on the local file system. Then it retrieves the "expected" checksum for the same artifact from the same source it got the artifact from. It compares the two checksums to see if the artifact is intact or corrupt. -Resolver calculates a checksum from the bytes of an artifact using a standard algorithm. It can read the bytes and calculate the checksum during the download or from a file already present on the local file system. - -This page covers all the "expected" checksum varieties. +This page covers the different ways Resolver can retrieve the "expected" checksum for an artifact that it compares against the locally calculated checksum. ## Transport Checksum Strategies -In the past, Resolver got the expected checksum from the artifact checksum URL. This is the artifact URL with an algorithm extension like ".sha1" appended. For example, if the artifact URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar then the SHA-1 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.sha1 and the MD5 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.md5. This logic is still present. The current Resolver extends this logic in several ways. +In the past, Resolver got the expected checksum from the artifact checksum URL. This is the artifact URL with an algorithm extension like ".sha1" appended. For example, if the artifact URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar then the SHA-1 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.sha1 and the MD5 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.md5. This logic is still present. -Resolver added two new strategies to the "obtain checksum" step. The three expected checksum kinds in transport are "Provided", "Remote Included", and "Remote External". All three strategies provide the source of the expected checksum. The strategies differ in **how** Resolver gets the checksum. +Resolver has three strategies for retrieving the expected checksum: "Provided", "Remote Included", and "Remote External". All three strategies provide the source of the expected checksum. The strategies differ in **how** Resolver gets the checksum. -The **Provided** checksums come to Resolver by some alternative means. The checksums can arrive before any transport operation. Users can implement an SPI extension point. The extension point gives users their own way to provide checksums. +**Provided** checksums come to Resolver by some alternative means. The checksums can arrive before any transport operation. Users can implement an SPI extension point. The extension point gives users their own way to provide checksums. Users can also use the Resolver implementation that comes with Resolver. The implementation delegates the provided checksums to the trusted checksums. The section "Trusted Checksums" describes them. @@ -43,29 +41,33 @@ Resolver extracts the checksums from the response. Then it gets the hashes that The **Remote External** checksums are the classic checksums. The remote repository stores them next to the artifact files. The layout of the remote repository defines the storage position. To get a Remote External checksum, send a new HTTP request to the remote repository. The order of the requested checksums follows the order in the layout configuration. Resolver asks for the checksums in the same order as the parameter contains the algorithm names. -During one artifact retrieval, Resolver runs the strategies in the order above. If the current strategy has no answer, Resolver tries the next strategy. If Resolver gets the expected checksum from the Provided source, it does not consult the Remote Included and Remote External sources. +When retrieving an artifact, Resolver runs the strategies in order: + +1. Provided +2. Remote Included +3. Remote External -Almost all repository managers and remote repositories send the standard checksums in their response. These repositories include Maven Central and the Google Mirror of Maven Central. If any standard checksum is enabled, the Remote Included strategy usually satisfies the verification. Then Resolver skips the Remote External strategy. +If Resolver gets the expected checksum from the Provided source, it does not consult the Remote Included and Remote External sources. -If Resolver gets the hashes with the Remote Included strategy, it halves the number of HTTP requests to download an artifact. +Almost all repository managers and remote repositories send standard checksums in their response. These repositories include Maven Central and the Google Mirror of Maven Central. If any standard checksum is enabled, the Remote Included strategy usually satisfies the verification. Then Resolver skips the Remote External strategy. This halves the number of HTTP requests to download an artifact. Related configuration keys: * `aether.layout.maven2.checksumAlgorithms` A comma-separated list of checksum algorithms. The order is important. The transport asks for the checksums in the specified order. The default is "SHA-1,MD5". The first received and matched checksum stops the integrity verification algorithm. -Note: Since Maven 3.9.x you can use the expression `${session.rootDirectory}/.mvn/checksums/` to store checksums along with sources. `session.rootDirectory` becomes an absolute path. The path points to the root directory of your project. The `.mvn` directory is usually in the root directory. +In Maven 3.9.x and later, you can use the expression `${session.rootDirectory}/.mvn/checksums/` to store checksums alongside sources. `session.rootDirectory` becomes an absolute path. The path points to the root directory of your project. The `.mvn` directory is usually in the root directory. ### Provided Checksums -The Resolver SPI `ProvidedChecksumsSource` feeds the Provided Checksums to Resolver before the actual transport. Resolver uses these checksums only during transport. It uses them to verify the integrity of the transported payload. The Provided checksums cannot verify the integrity of cached artifacts. If you build with an empty repository, all your artifacts go through transport. Then the Provided checksums can verify them. +The Resolver SPI `ProvidedChecksumsSource` feeds the Provided Checksums to Resolver before the actual transport. Resolver uses these checksums during transport to verify the integrity of the transported payload. Provided checksums cannot verify the integrity of cached artifacts. If you build with an empty repository, all your artifacts go through transport. Then the Provided checksums can verify them. -Resolver provides one SPI implementation with the distribution. The implementation delegates to the trusted checksums. +Resolver provides one SPI implementation with the distribution. This implementation delegates to the trusted checksums. ### Remote Included Checksums -**Note:** Remote Included checksums work only with transport-http. They do not work with transport-wagon. +**Note:** Remote Included checksums only work with transport-http. They do not work with transport-wagon. -Many repository services emit the reference checksums in the artifact response. Maven Central is one of these services. The service emits the checksums as HTTP headers. The Remote Included feature halves the number of HTTP requests. Resolver gets the artifact and the expected checksum with one HTTP round-trip. +Many repository services include the reference checksums in the HTTP response headers. Maven Central is one of these services. Resolver gets the artifact and the expected checksum with one HTTP round-trip. Related configuration keys: * `aether.connector.basic.smartChecksums` to enable or disable Remote Included checksums. @@ -73,25 +75,16 @@ Related configuration keys: The Remote Included checksums support several "strategies" to extract checksums from the HTTP response header. -#### Sonatype Nexus 2 - -Sonatype Nexus 2 generates the `ETag` header from a SHA-1 hash. It shields the hash in the Plexus Cipher style. Only SHA-1 is available in the artifact response header. - -Emitted by: Sonatype Nexus2 only. - - #### Non-standard `X-` headers -Maven Central emits the headers `x-checksum-sha1` and `x-checksum-md5` along with the artifact response. Google GCS uses the headers `x-goog-meta-checksum-sha1` and `x-goog-meta-checksum-md5`. AWS S3 uses the headers `x-amz-meta-checksum-sha1` and `x-amz-meta-checksum-md5`. Resolver detects all these headers and uses their values. +Maven Central includes the headers `x-checksum-sha1` and `x-checksum-md5` in the HTTP response. Google Cloud Storage includes the headers `x-goog-meta-checksum-sha1` and `x-goog-meta-checksum-md5`. AWS S3 includes the headers `x-amz-meta-checksum-sha1` and `x-amz-meta-checksum-md5`. Resolver detects all these headers and uses their values. Emitted by: Maven Central, GCS, AWS S3, some CDNs and probably more. ### Remote External checksums -The Remote External checksums are the classic checksums. They exist since Maven 1. The remote repository stores them next to the payload file. For example, it stores "lib.jar" and the checksum "lib.jar.sha1". They are the oldest kind of Resolver checksums. - -Their shortcoming is that only SHA-1 and MD5 are often produced. The consumer is tied to the checksum algorithms that the remote repository provides. The payload and the checksum come from the same origin. If the origin is not trusted, this can be a risk. Maven Central is an example of a trusted origin. +The Remote External checksums are the classic checksums. The remote repository stores them next to the payload file. For example, it stores "lib.jar" and the checksum "lib.jar.sha1". They are the oldest kind of Resolver checksums. ## Trusted Checksums From 50b7dceea36cf15dcfbaa446a80e0ca1c6d8450a Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Thu, 6 Aug 2026 11:22:06 +0000 Subject: [PATCH 10/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index 3b3f280fc..481c4ee02 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -93,13 +93,10 @@ All the expected checksums above are used only in transport. They relate to URLs `TrustedChecksumsSource` is an SPI component. It delivers the expected checksums for an artifact. It does not use any transport API element. This API is not bound to transport. It is generic. -The trusted checksums map almost one-to-one into the Provided strategy. Resolver provides an implementation that delegates the Provided checksums to the Trusted checksums. The Provided and Trusted checksums become equivalent for transport. +Trusted checksums map almost one-to-one into the Provided strategy. Resolver provides an implementation that delegates the Provided checksums to the Trusted checksums. The Provided and Trusted checksums become equivalent for transport. -The biggest advantage of Trusted Checksums is their transport independence. They work in places where there is no transport. One use of Trusted Checksums is the ArtifactResolver post-processing. - -This functionality verifies all the resolved artifacts against the Trusted Checksums. It costs checksum calculation overhead. The user provides a known checksum. The checksum can be cryptographically strong. - -The functionality can help when the user cannot trust the local repository. An unknown or untrusted party can share the local repository. +Transport independence is the biggest advantage of Trusted Checksums. They work in places where there is no transport such as ArtifactResolver post-processing. This functionality verifies all the resolved artifacts against the Trusted Checksums. The user provides a known checksum that can be cryptographically strong. +This helps when the user cannot trust the local repository because an unknown or untrusted party shares the local repository. You can record the checksums with the Trusted Checksum post-processor. For example, run it in a known and safe environment. Then distribute the produced checksum within your organization. @@ -113,7 +110,7 @@ Related configuration keys: The summary file source uses one file. The file is compatible with the GNU coreutils format. Each line contains the hash and the relative path of an artifact. The path is relative to the local repository basedir. -You can produce the file with the `sha1sum` command line tool. GNU coreutils provides this tool. You can use the same tools to verify the artifacts in the local repository in a batch. +You can produce the file with the `sha1sum` command line tool from GNU coreutils. You can use the same tool to verify the artifacts in the local repository. Each summary file contains information for one checksum algorithm. The file extension represents the algorithm. @@ -153,6 +150,6 @@ The sparse directory can contain checksums for multiple algorithms. The file ext ### Notes On Using Trusted Checksums -- Use the `--strict-checksums` flag to fail a build if the expected checksums of the downloaded artifacts do not match. +- Use the `--strict-checksums` flag to fail a build if the expected checksum of a downloaded artifacts does not match the trusted checksum. - You can specify more than one checksum algorithm for the `aether.artifactResolver.postProcessor.trustedChecksums.checksumAlgorithms` system property. The listed checksums must be a subset of the checksums in `aether.checksums.algorithms`. -- Most dependency management tools do not update trusted checksum files. This is true if the files are stored in version control alongside the source code. We hope that the maintainers of these tools support Maven trusted checksums in the near future. +- Most dependency management tools do not update trusted checksum files. This is true if the files are stored in version control alongside the source code. We hope that these tools will support Maven trusted checksums in the near future. From 1c4601a4e2dae9d986470c04e4614aa4f4e91699 Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Thu, 6 Aug 2026 12:11:25 +0000 Subject: [PATCH 11/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index 481c4ee02..c1903e64d 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -20,7 +20,7 @@ under the License. Resolver uses checksums during transport to verify that the artifact is intact. The latest Resolver also uses checksums at other times. For example, it verifies that the artifact is intact during resolution. -Checksums in Resolver have one purpose: integrity verification. Resolver determines the "calculated" checksum for an artifact by applying a mathematical algorithm to its local copy of the artifact. It can read the bytes and calculate the checksum during the download or from a file already present on the local file system. Then it retrieves the "expected" checksum for the same artifact from the same source it got the artifact from. It compares the two checksums to see if the artifact is intact or corrupt. +Checksums in Resolver provide integrity verification. Resolver determines the "calculated" checksum for an artifact by applying a mathematical algorithm to its local copy of the artifact. It can read the bytes and calculate the checksum during the download or from a file already present on the local file system. Then it retrieves the "expected" checksum for the same artifact. It compares the two checksums to see if the artifact is intact or corrupt. This page covers the different ways Resolver can retrieve the "expected" checksum for an artifact that it compares against the locally calculated checksum. From a3001adf0169a632a1e00df2f581bb03ab9ebd0b Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Thu, 6 Aug 2026 12:26:33 +0000 Subject: [PATCH 12/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index c1903e64d..a4d67a5ea 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -29,19 +29,20 @@ This page covers the different ways Resolver can retrieve the "expected" checksu In the past, Resolver got the expected checksum from the artifact checksum URL. This is the artifact URL with an algorithm extension like ".sha1" appended. For example, if the artifact URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar then the SHA-1 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.sha1 and the MD5 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.md5. This logic is still present. -Resolver has three strategies for retrieving the expected checksum: "Provided", "Remote Included", and "Remote External". All three strategies provide the source of the expected checksum. The strategies differ in **how** Resolver gets the checksum. +Resolver has three strategies for retrieving the expected checksum: "Provided", "Remote Included", and "Remote External". Appending a checksum extension to the artifact URL is an example of the "Remote External" strategy. +The strategies differ in **how** Resolver gets the checksum. -**Provided** checksums come to Resolver by some alternative means. The checksums can arrive before any transport operation. Users can implement an SPI extension point. The extension point gives users their own way to provide checksums. +**Provided** checksums come to Resolver by some means. The checksums can arrive before any transport operation. Users can implement an SPI extension point. The extension point gives users their own way to provide checksums. Users can also use the Resolver implementation that comes with Resolver. The implementation delegates the provided checksums to the trusted checksums. The section "Trusted Checksums" describes them. -The remote party includes the **Remote Included** checksums in its response. Most modern repository managers send checksums in the response headers. The checksums are usually the standard SHA-1 and MD5. Maven Central sends them as well. The Google Mirror of Maven Central sends them too. +**Remote Included** checksums are bundled in the same response that the artifact itself arrives in. Most modern repository managers send checksums in the HTTP response headers. Maven Central and the Google Mirror of Maven Central send the SHA-1 checksum as a hexadecimal string in the X-Checksum-Sha1 HTTP header. +They send the hexadecimal encoded MD5 checksum in the X-Checksum-Md5 HTTP header. +Resolver gets the content and the checksums in one response. -Resolver extracts the checksums from the response. Then it gets the hashes that the remote repository provided with the content. This saves one HTTP round-trip. Resolver gets the content and the checksums in one response. +**Remote External** checksums are the classic checksums. The remote repository stores them next to the artifact files. The layout of the remote repository defines the storage position. To get a Remote External checksum, Resolver sends a new HTTP GET request for the artifact checksum URL. The order of the requested checksums follows the order in the layout configuration. Resolver asks for the checksums in the same order as the parameter contains the algorithm names. -The **Remote External** checksums are the classic checksums. The remote repository stores them next to the artifact files. The layout of the remote repository defines the storage position. To get a Remote External checksum, send a new HTTP request to the remote repository. The order of the requested checksums follows the order in the layout configuration. Resolver asks for the checksums in the same order as the parameter contains the algorithm names. - -When retrieving an artifact, Resolver runs the strategies in order: +When retrieving an artifact, Resolver runs the strategies in this order until it finds a checksum: 1. Provided 2. Remote Included From 2f0685df1617462613001ddc99663ab071f1b516 Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Thu, 6 Aug 2026 12:44:26 +0000 Subject: [PATCH 13/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index a4d67a5ea..f43ff7090 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -27,20 +27,18 @@ This page covers the different ways Resolver can retrieve the "expected" checksu ## Transport Checksum Strategies -In the past, Resolver got the expected checksum from the artifact checksum URL. This is the artifact URL with an algorithm extension like ".sha1" appended. For example, if the artifact URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar then the SHA-1 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.sha1 and the MD5 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.md5. This logic is still present. - Resolver has three strategies for retrieving the expected checksum: "Provided", "Remote Included", and "Remote External". Appending a checksum extension to the artifact URL is an example of the "Remote External" strategy. The strategies differ in **how** Resolver gets the checksum. -**Provided** checksums come to Resolver by some means. The checksums can arrive before any transport operation. Users can implement an SPI extension point. The extension point gives users their own way to provide checksums. - -Users can also use the Resolver implementation that comes with Resolver. The implementation delegates the provided checksums to the trusted checksums. The section "Trusted Checksums" describes them. +**Provided** checksums are supplied to the Resolver through the Resolver's Java API. Users can implement or install an SPI extension point that loads checksums. The checksums can load before any transport operation. +Users can also use the trusted checksum SPI bundled with the Resolver implementation. The section "Trusted Checksums" below describes this approach. -**Remote Included** checksums are bundled in the same response that the artifact itself arrives in. Most modern repository managers send checksums in the HTTP response headers. Maven Central and the Google Mirror of Maven Central send the SHA-1 checksum as a hexadecimal string in the X-Checksum-Sha1 HTTP header. +**Remote Included** checksums are part of the response that the artifact itself arrives in. Most modern repository managers send checksums in the HTTP response headers. Maven Central and the Google Mirror of Maven Central send the SHA-1 checksum as a hexadecimal string in the X-Checksum-Sha1 HTTP header. They send the hexadecimal encoded MD5 checksum in the X-Checksum-Md5 HTTP header. -Resolver gets the content and the checksums in one response. +Resolver gets the content and the checksums in one HTTP request. + +**Remote External** checksums are the classic checksums. The remote repository stores them next to the artifact files. To get a Remote External checksum, Resolver sends a new HTTP GET request for the artifact checksum URL. This is the artifact URL with an algorithm extension like ".sha1" appended. For example, if the artifact URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar then the SHA-1 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.sha1 and the MD5 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.md5. -**Remote External** checksums are the classic checksums. The remote repository stores them next to the artifact files. The layout of the remote repository defines the storage position. To get a Remote External checksum, Resolver sends a new HTTP GET request for the artifact checksum URL. The order of the requested checksums follows the order in the layout configuration. Resolver asks for the checksums in the same order as the parameter contains the algorithm names. When retrieving an artifact, Resolver runs the strategies in this order until it finds a checksum: From 3af3d98c7154b60fb964e47bdb6d0495d149ce6a Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Thu, 6 Aug 2026 13:00:38 +0000 Subject: [PATCH 14/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index f43ff7090..3907f9796 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -37,7 +37,7 @@ Users can also use the trusted checksum SPI bundled with the Resolver implementa They send the hexadecimal encoded MD5 checksum in the X-Checksum-Md5 HTTP header. Resolver gets the content and the checksums in one HTTP request. -**Remote External** checksums are the classic checksums. The remote repository stores them next to the artifact files. To get a Remote External checksum, Resolver sends a new HTTP GET request for the artifact checksum URL. This is the artifact URL with an algorithm extension like ".sha1" appended. For example, if the artifact URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar then the SHA-1 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.sha1 and the MD5 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.md5. +**Remote External** checksums are separate resources in the remote repository. The remote repository stores them next to the artifact files. To get a Remote External checksum, Resolver sends a new HTTP GET request for the artifact checksum URL. This is the artifact URL with an algorithm extension such as ".sha1" appended. For example, if the artifact URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar, then the SHA-1 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.sha1, and the MD5 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.md5. When retrieving an artifact, Resolver runs the strategies in this order until it finds a checksum: @@ -48,10 +48,11 @@ When retrieving an artifact, Resolver runs the strategies in this order until it If Resolver gets the expected checksum from the Provided source, it does not consult the Remote Included and Remote External sources. -Almost all repository managers and remote repositories send standard checksums in their response. These repositories include Maven Central and the Google Mirror of Maven Central. If any standard checksum is enabled, the Remote Included strategy usually satisfies the verification. Then Resolver skips the Remote External strategy. This halves the number of HTTP requests to download an artifact. +Almost all repository managers and remote repositories send standard checksums in their responses. +If any standard checksum algorithm is enabled, the Remote Included strategy usually finds a checksum. Then Resolver skips the Remote External strategy. Related configuration keys: -* `aether.layout.maven2.checksumAlgorithms` A comma-separated list of checksum algorithms. The order is important. The transport asks for the checksums in the specified order. The default is "SHA-1,MD5". The first received and matched checksum stops the integrity verification algorithm. +* `aether.layout.maven2.checksumAlgorithms` A comma-separated list of checksum algorithms. The order is important. The transport asks for the checksums in the specified order. The default is "SHA-1,MD5". The first available algorithm will be used. For example, if you prefer MD5 but are willing to use SHA-1, set `aether.layout.maven2.checksumAlgorithms` to "MD5,SHA-1". In Maven 3.9.x and later, you can use the expression `${session.rootDirectory}/.mvn/checksums/` to store checksums alongside sources. `session.rootDirectory` becomes an absolute path. The path points to the root directory of your project. The `.mvn` directory is usually in the root directory. @@ -71,14 +72,14 @@ Many repository services include the reference checksums in the HTTP response he Related configuration keys: * `aether.connector.basic.smartChecksums` to enable or disable Remote Included checksums. -The Remote Included checksums support several "strategies" to extract checksums from the HTTP response header. +Resolver checks several non-standard `X-` headers for checksums: -#### Non-standard `X-` headers +* `x-checksum-sha1` and `x-checksum-md5`: Maven Central and the Google Mirror of Maven Central +* `x-goog-meta-checksum-sha1` and `x-goog-meta-checksum-md5`: Google Cloud Storage +* `x-amz-meta-checksum-sha1` and `x-amz-meta-checksum-md5`: AWS S3 -Maven Central includes the headers `x-checksum-sha1` and `x-checksum-md5` in the HTTP response. Google Cloud Storage includes the headers `x-goog-meta-checksum-sha1` and `x-goog-meta-checksum-md5`. AWS S3 includes the headers `x-amz-meta-checksum-sha1` and `x-amz-meta-checksum-md5`. Resolver detects all these headers and uses their values. - -Emitted by: Maven Central, GCS, AWS S3, some CDNs and probably more. +Resolver detects all these headers and uses their values. You don't need to tell it in advance which variant to expect. ### Remote External checksums From 9a2052f04565f16f494af09e92772541fa595d6d Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Thu, 6 Aug 2026 13:03:52 +0000 Subject: [PATCH 15/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index 3907f9796..19acf49c9 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -84,7 +84,7 @@ Resolver detects all these headers and uses their values. You don't need to tell ### Remote External checksums -The Remote External checksums are the classic checksums. The remote repository stores them next to the payload file. For example, it stores "lib.jar" and the checksum "lib.jar.sha1". They are the oldest kind of Resolver checksums. +The Remote External checksums are the classic checksums. The remote repository stores them next to the payload file. For example, it stores "lib.jar" and the checksum "lib.jar.sha1" in the same directory. They are the oldest kind of Resolver checksums. ## Trusted Checksums From 9b4f047f33c7919c4eced238ed91cea4cced18d4 Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Thu, 6 Aug 2026 13:11:08 +0000 Subject: [PATCH 16/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index 19acf49c9..955a947eb 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -91,14 +91,14 @@ The Remote External checksums are the classic checksums. The remote repository s All the expected checksums above are used only in transport. They relate to URLs, HTTP requests, and HTTP responses. Or they require transport related API elements. -`TrustedChecksumsSource` is an SPI component. It delivers the expected checksums for an artifact. It does not use any transport API element. This API is not bound to transport. It is generic. +`TrustedChecksumsSource` is an SPI component. It delivers the expected checksums for an artifact. This API is not bound to transport. It is generic. -Trusted checksums map almost one-to-one into the Provided strategy. Resolver provides an implementation that delegates the Provided checksums to the Trusted checksums. The Provided and Trusted checksums become equivalent for transport. +Trusted checksums map almost one-to-one into the Provided strategy. `TrustedChecksumsSource` in the Resolver implementation *provides* the Trusted checksums to the Resolver. Transport independence is the biggest advantage of Trusted Checksums. They work in places where there is no transport such as ArtifactResolver post-processing. This functionality verifies all the resolved artifacts against the Trusted Checksums. The user provides a known checksum that can be cryptographically strong. This helps when the user cannot trust the local repository because an unknown or untrusted party shares the local repository. -You can record the checksums with the Trusted Checksum post-processor. For example, run it in a known and safe environment. Then distribute the produced checksum within your organization. +You can record the checksums with the Trusted Checksum post-processor. For example, run it in a known and safe environment to record the current checksums. Distribute the produced checksum within your organization. Then the build fails if at some point in the future the artifact changes. The Trusted Checksums distribution provides two source implementations. From c3951aef55d0fd6ae238aa2baa3c31913de0a856 Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Thu, 6 Aug 2026 13:17:43 +0000 Subject: [PATCH 17/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index 955a947eb..3c5ddac3b 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -112,7 +112,7 @@ The summary file source uses one file. The file is compatible with the GNU coreu You can produce the file with the `sha1sum` command line tool from GNU coreutils. You can use the same tool to verify the artifacts in the local repository. -Each summary file contains information for one checksum algorithm. The file extension represents the algorithm. +Each summary file contains checksums computed by one algorithm. The file extension represents the algorithm. If you use Maven 3.9.x, use the following procedure to save the summary checksum file alongside your project code: @@ -128,7 +128,7 @@ If you use Maven 3.9.x, use the following procedure to save the summary checksum -Daether.artifactResolver.postProcessor.trustedChecksums.failIfMissing=true ``` -2. Run a build with trusted checksum recording enabled: +2. Build with trusted checksum recording enabled: ```sh mvn clean install -Daether.artifactResolver.postProcessor.trustedChecksums.record=true @@ -150,6 +150,6 @@ The sparse directory can contain checksums for multiple algorithms. The file ext ### Notes On Using Trusted Checksums -- Use the `--strict-checksums` flag to fail a build if the expected checksum of a downloaded artifacts does not match the trusted checksum. +- Use the `--strict-checksums` flag to fail a build if the expected checksum of a downloaded artifact does not match the trusted checksum. - You can specify more than one checksum algorithm for the `aether.artifactResolver.postProcessor.trustedChecksums.checksumAlgorithms` system property. The listed checksums must be a subset of the checksums in `aether.checksums.algorithms`. - Most dependency management tools do not update trusted checksum files. This is true if the files are stored in version control alongside the source code. We hope that these tools will support Maven trusted checksums in the near future. From c9fd260fcc4a5492b627b42545c6c3504543e792 Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Fri, 7 Aug 2026 15:14:56 +0000 Subject: [PATCH 18/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index 3c5ddac3b..10398045d 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -18,7 +18,8 @@ specific language governing permissions and limitations under the License. --> -Resolver uses checksums during transport to verify that the artifact is intact. The latest Resolver also uses checksums at other times. For example, it verifies that the artifact is intact during resolution. +Resolver uses checksums during transport to verify that the artifact is intact. +Resolver also uses checksums at other times. For example, it verifies that the artifact is intact during resolution. Checksums in Resolver provide integrity verification. Resolver determines the "calculated" checksum for an artifact by applying a mathematical algorithm to its local copy of the artifact. It can read the bytes and calculate the checksum during the download or from a file already present on the local file system. Then it retrieves the "expected" checksum for the same artifact. It compares the two checksums to see if the artifact is intact or corrupt. From 5634fbf2f8625e2443de54a9bafae8cd7bff873a Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Fri, 7 Aug 2026 15:16:31 +0000 Subject: [PATCH 19/24] italics --- src/site/markdown/expected-checksums.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index 10398045d..92eb756ac 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -21,7 +21,7 @@ under the License. Resolver uses checksums during transport to verify that the artifact is intact. Resolver also uses checksums at other times. For example, it verifies that the artifact is intact during resolution. -Checksums in Resolver provide integrity verification. Resolver determines the "calculated" checksum for an artifact by applying a mathematical algorithm to its local copy of the artifact. It can read the bytes and calculate the checksum during the download or from a file already present on the local file system. Then it retrieves the "expected" checksum for the same artifact. It compares the two checksums to see if the artifact is intact or corrupt. +Checksums in Resolver provide integrity verification. Resolver determines the *calculated checksum* for an artifact by applying a mathematical algorithm to its local copy of the artifact. It can read the bytes and calculate the checksum during the download or from a file already present on the local file system. Then it retrieves the *expected checksum* for the same artifact. It compares the two checksums to see if the artifact is intact or corrupt. This page covers the different ways Resolver can retrieve the "expected" checksum for an artifact that it compares against the locally calculated checksum. From 961f870c2bf8005e7d68da8a5f0011fb7d6ca1f8 Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Fri, 7 Aug 2026 15:27:34 +0000 Subject: [PATCH 20/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 39 ++++++++++++------------- 1 file changed, 19 insertions(+), 20 deletions(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index 92eb756ac..728a78c27 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -23,12 +23,12 @@ Resolver also uses checksums at other times. For example, it verifies that the a Checksums in Resolver provide integrity verification. Resolver determines the *calculated checksum* for an artifact by applying a mathematical algorithm to its local copy of the artifact. It can read the bytes and calculate the checksum during the download or from a file already present on the local file system. Then it retrieves the *expected checksum* for the same artifact. It compares the two checksums to see if the artifact is intact or corrupt. -This page covers the different ways Resolver can retrieve the "expected" checksum for an artifact that it compares against the locally calculated checksum. +This page covers the different ways Resolver can retrieve the *expected checksum* for an artifact that it compares against the locally calculated checksum. ## Transport Checksum Strategies -Resolver has three strategies for retrieving the expected checksum: "Provided", "Remote Included", and "Remote External". Appending a checksum extension to the artifact URL is an example of the "Remote External" strategy. +Resolver has three strategies for retrieving the expected checksum: *Provided*, *Remote Included*, and *Remote External*. Appending a checksum extension to the artifact URL is an example of the Remote External strategy. The strategies differ in **how** Resolver gets the checksum. **Provided** checksums are supplied to the Resolver through the Resolver's Java API. Users can implement or install an SPI extension point that loads checksums. The checksums can load before any transport operation. @@ -41,7 +41,7 @@ Resolver gets the content and the checksums in one HTTP request. **Remote External** checksums are separate resources in the remote repository. The remote repository stores them next to the artifact files. To get a Remote External checksum, Resolver sends a new HTTP GET request for the artifact checksum URL. This is the artifact URL with an algorithm extension such as ".sha1" appended. For example, if the artifact URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar, then the SHA-1 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.sha1, and the MD5 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.md5. -When retrieving an artifact, Resolver runs the strategies in this order until it finds a checksum: +When retrieving an artifact, Resolver looks for a checksum in this order until it finds one: 1. Provided 2. Remote Included @@ -55,24 +55,20 @@ If any standard checksum algorithm is enabled, the Remote Included strategy usua Related configuration keys: * `aether.layout.maven2.checksumAlgorithms` A comma-separated list of checksum algorithms. The order is important. The transport asks for the checksums in the specified order. The default is "SHA-1,MD5". The first available algorithm will be used. For example, if you prefer MD5 but are willing to use SHA-1, set `aether.layout.maven2.checksumAlgorithms` to "MD5,SHA-1". -In Maven 3.9.x and later, you can use the expression `${session.rootDirectory}/.mvn/checksums/` to store checksums alongside sources. `session.rootDirectory` becomes an absolute path. The path points to the root directory of your project. The `.mvn` directory is usually in the root directory. +In Maven 3.9.x and later, you can use the expression `${session.rootDirectory}/.mvn/checksums/` to store checksums alongside sources. `session.rootDirectory` becomes an absolute path. The path points to the root directory of the project. The `.mvn` directory is usually in the root directory. ### Provided Checksums -The Resolver SPI `ProvidedChecksumsSource` feeds the Provided Checksums to Resolver before the actual transport. Resolver uses these checksums during transport to verify the integrity of the transported payload. Provided checksums cannot verify the integrity of cached artifacts. If you build with an empty repository, all your artifacts go through transport. Then the Provided checksums can verify them. +The Resolver SPI `ProvidedChecksumsSource` feeds the Provided Checksums to Resolver before the actual transport. Resolver uses these checksums during transport to verify the integrity of the transported payload. Provided checksums cannot verify the integrity of cached artifacts. If you build with an empty repository, all artifacts go through transport. Then the Provided checksums can verify them. -Resolver provides one SPI implementation with the distribution. This implementation delegates to the trusted checksums. +Resolver provides one SPI implementation with the distribution for loading trusted checksums. ### Remote Included Checksums **Note:** Remote Included checksums only work with transport-http. They do not work with transport-wagon. -Many repository services include the reference checksums in the HTTP response headers. Maven Central is one of these services. Resolver gets the artifact and the expected checksum with one HTTP round-trip. - -Related configuration keys: -* `aether.connector.basic.smartChecksums` to enable or disable Remote Included checksums. - +Maven Central and many other repositories include the reference checksums in the HTTP response headers. Resolver gets the artifact and the expected checksum with one HTTP request. Resolver checks several non-standard `X-` headers for checksums: @@ -82,10 +78,13 @@ Resolver checks several non-standard `X-` headers for checksums: Resolver detects all these headers and uses their values. You don't need to tell it in advance which variant to expect. +Related configuration keys: +* `aether.connector.basic.smartChecksums` to enable or disable Remote Included checksums. + ### Remote External checksums -The Remote External checksums are the classic checksums. The remote repository stores them next to the payload file. For example, it stores "lib.jar" and the checksum "lib.jar.sha1" in the same directory. They are the oldest kind of Resolver checksums. +Remote External checksums are next to the payload file in the remote repository. For example, "lib.jar" and the checksum "lib.jar.sha1" are in the same directory. They are the oldest kind of Resolver checksums. ## Trusted Checksums @@ -94,28 +93,28 @@ All the expected checksums above are used only in transport. They relate to URLs `TrustedChecksumsSource` is an SPI component. It delivers the expected checksums for an artifact. This API is not bound to transport. It is generic. -Trusted checksums map almost one-to-one into the Provided strategy. `TrustedChecksumsSource` in the Resolver implementation *provides* the Trusted checksums to the Resolver. +Trusted checksums map almost one-to-one into the Provided strategy. `TrustedChecksumsSource` in the Resolver implementation *provides* Trusted checksums to the Resolver. -Transport independence is the biggest advantage of Trusted Checksums. They work in places where there is no transport such as ArtifactResolver post-processing. This functionality verifies all the resolved artifacts against the Trusted Checksums. The user provides a known checksum that can be cryptographically strong. -This helps when the user cannot trust the local repository because an unknown or untrusted party shares the local repository. +Transport independence is the biggest advantage of Trusted Checksums. They work in places such as ArtifactResolver post-processing where there is no transport. This functionality verifies all the resolved artifacts against the Trusted Checksums. The user provides a known checksum that can be cryptographically strong. +This helps when the user cannot trust the local repository because an unknown or untrusted party can write to the local repository. You can record the checksums with the Trusted Checksum post-processor. For example, run it in a known and safe environment to record the current checksums. Distribute the produced checksum within your organization. Then the build fails if at some point in the future the artifact changes. -The Trusted Checksums distribution provides two source implementations. - Related configuration keys: * `aether.trustedChecksumsSource.*` * `aether.artifactResolver.postProcessor.trustedChecksums.*` +The Trusted Checksums distribution provides two source implementations, Summary File and Sparse Directory. + ### Summary File Trusted Checksums Source -The summary file source uses one file. The file is compatible with the GNU coreutils format. Each line contains the hash and the relative path of an artifact. The path is relative to the local repository basedir. +The summary file source uses one file compatible with the GNU coreutils format. Each line contains the hash and the relative path of an artifact. The path is relative to the local repository basedir. -You can produce the file with the `sha1sum` command line tool from GNU coreutils. You can use the same tool to verify the artifacts in the local repository. +You can produce this file with the `sha1sum` command line tool from GNU coreutils. You can use the same tool to verify the artifacts in the local repository. Each summary file contains checksums computed by one algorithm. The file extension represents the algorithm. -If you use Maven 3.9.x, use the following procedure to save the summary checksum file alongside your project code: +If you use Maven 3.9.x, the following procedure saves the summary checksum file alongside your project code: 1. Add the following command line flags to your `.mvn/config` file: From 3b06494e2a95a794431c352dba1c479e9b79454d Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Fri, 7 Aug 2026 19:08:23 +0000 Subject: [PATCH 21/24] correct key names --- src/site/markdown/expected-checksums.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index 728a78c27..34fbc526b 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -53,7 +53,7 @@ Almost all repository managers and remote repositories send standard checksums i If any standard checksum algorithm is enabled, the Remote Included strategy usually finds a checksum. Then Resolver skips the Remote External strategy. Related configuration keys: -* `aether.layout.maven2.checksumAlgorithms` A comma-separated list of checksum algorithms. The order is important. The transport asks for the checksums in the specified order. The default is "SHA-1,MD5". The first available algorithm will be used. For example, if you prefer MD5 but are willing to use SHA-1, set `aether.layout.maven2.checksumAlgorithms` to "MD5,SHA-1". +* `aether.maven2.checksumAlgorithms` A comma-separated list of checksum algorithms. The order is important. The transport asks for the checksums in the specified order. The default is "SHA-1,MD5". The first available algorithm will be used. For example, if you prefer MD5 but are willing to use SHA-1, set `aether.maven2.checksumAlgorithms` to "MD5,SHA-1". In Maven 3.9.x and later, you can use the expression `${session.rootDirectory}/.mvn/checksums/` to store checksums alongside sources. `session.rootDirectory` becomes an absolute path. The path points to the root directory of the project. The `.mvn` directory is usually in the root directory. @@ -79,7 +79,7 @@ Resolver checks several non-standard `X-` headers for checksums: Resolver detects all these headers and uses their values. You don't need to tell it in advance which variant to expect. Related configuration keys: -* `aether.connector.basic.smartChecksums` to enable or disable Remote Included checksums. +* `aether.connector.basic.includedChecksums` to enable or disable Remote Included checksums. ### Remote External checksums From 784e335785c46ebfa0204197b81a46ff024e9c47 Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Fri, 7 Aug 2026 19:17:57 +0000 Subject: [PATCH 22/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index 34fbc526b..a03faa0ec 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -53,7 +53,7 @@ Almost all repository managers and remote repositories send standard checksums i If any standard checksum algorithm is enabled, the Remote Included strategy usually finds a checksum. Then Resolver skips the Remote External strategy. Related configuration keys: -* `aether.maven2.checksumAlgorithms` A comma-separated list of checksum algorithms. The order is important. The transport asks for the checksums in the specified order. The default is "SHA-1,MD5". The first available algorithm will be used. For example, if you prefer MD5 but are willing to use SHA-1, set `aether.maven2.checksumAlgorithms` to "MD5,SHA-1". +* `aether.checksums.checksumAlgorithms` A comma-separated list of checksum algorithms. The order is important. The transport asks for the checksums in the specified order. The default is "SHA-1,MD5". The first available algorithm will be used. For example, if you prefer MD5 but are willing to use SHA-1, set `aether.checksums.checksumAlgorithms` to "MD5,SHA-1". In Maven 3.9.x and later, you can use the expression `${session.rootDirectory}/.mvn/checksums/` to store checksums alongside sources. `session.rootDirectory` becomes an absolute path. The path points to the root directory of the project. The `.mvn` directory is usually in the root directory. From 4b11ea8098cd40b664e41faef56564c624080f67 Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Fri, 7 Aug 2026 19:39:55 +0000 Subject: [PATCH 23/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index a03faa0ec..13c622860 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -34,8 +34,9 @@ The strategies differ in **how** Resolver gets the checksum. **Provided** checksums are supplied to the Resolver through the Resolver's Java API. Users can implement or install an SPI extension point that loads checksums. The checksums can load before any transport operation. Users can also use the trusted checksum SPI bundled with the Resolver implementation. The section "Trusted Checksums" below describes this approach. -**Remote Included** checksums are part of the response that the artifact itself arrives in. Most modern repository managers send checksums in the HTTP response headers. Maven Central and the Google Mirror of Maven Central send the SHA-1 checksum as a hexadecimal string in the X-Checksum-Sha1 HTTP header. -They send the hexadecimal encoded MD5 checksum in the X-Checksum-Md5 HTTP header. +**Remote Included** checksums are part of the response that the artifact itself arrives in. Most modern repositories send checksums in the HTTP response headers. Maven Central sends the SHA-1 checksum as a hexadecimal string in the x-checksum-sha1 HTTP header. +It sends the hexadecimal encoded MD5 checksum in the x-checksum-md5 HTTP header. +Other repositories send similar HTTP headers. Resolver gets the content and the checksums in one HTTP request. **Remote External** checksums are separate resources in the remote repository. The remote repository stores them next to the artifact files. To get a Remote External checksum, Resolver sends a new HTTP GET request for the artifact checksum URL. This is the artifact URL with an algorithm extension such as ".sha1" appended. For example, if the artifact URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar, then the SHA-1 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.sha1, and the MD5 checksum URL is https://repo1.maven.org/maven2/xom/xom/1.3.9/xom-1.3.9.jar.md5. @@ -70,10 +71,10 @@ Resolver provides one SPI implementation with the distribution for loading trust Maven Central and many other repositories include the reference checksums in the HTTP response headers. Resolver gets the artifact and the expected checksum with one HTTP request. -Resolver checks several non-standard `X-` headers for checksums: +Resolver checks several unstandardized `X-` headers for checksums: -* `x-checksum-sha1` and `x-checksum-md5`: Maven Central and the Google Mirror of Maven Central -* `x-goog-meta-checksum-sha1` and `x-goog-meta-checksum-md5`: Google Cloud Storage +* `x-checksum-sha1` and `x-checksum-md5`: Maven Central +* `x-goog-meta-checksum-sha1` and `x-goog-meta-checksum-md5`: the Google Mirror of Maven Central * `x-amz-meta-checksum-sha1` and `x-amz-meta-checksum-md5`: AWS S3 Resolver detects all these headers and uses their values. You don't need to tell it in advance which variant to expect. From 74d99c169dc2b527ce6a31add20be026eda8d236 Mon Sep 17 00:00:00 2001 From: Elliotte Rusty Harold Date: Fri, 7 Aug 2026 19:41:30 +0000 Subject: [PATCH 24/24] Update expected-checksums.md --- src/site/markdown/expected-checksums.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/site/markdown/expected-checksums.md b/src/site/markdown/expected-checksums.md index 13c622860..e1df541f5 100644 --- a/src/site/markdown/expected-checksums.md +++ b/src/site/markdown/expected-checksums.md @@ -152,5 +152,5 @@ The sparse directory can contain checksums for multiple algorithms. The file ext ### Notes On Using Trusted Checksums - Use the `--strict-checksums` flag to fail a build if the expected checksum of a downloaded artifact does not match the trusted checksum. -- You can specify more than one checksum algorithm for the `aether.artifactResolver.postProcessor.trustedChecksums.checksumAlgorithms` system property. The listed checksums must be a subset of the checksums in `aether.checksums.algorithms`. +- You can specify more than one checksum algorithm for the `aether.artifactResolver.postProcessor.trustedChecksums.checksumAlgorithms` system property. The listed checksums must be a subset of the checksums in `aether.checksums.checksumAlgorithms`. - Most dependency management tools do not update trusted checksum files. This is true if the files are stored in version control alongside the source code. We hope that these tools will support Maven trusted checksums in the near future.