gnodet commented on code in PR #2024: URL: https://github.com/apache/maven-resolver/pull/2024#discussion_r3711958142
########## src/site/markdown/about-checksums.md: ########## @@ -18,65 +18,62 @@ specific language governing permissions and limitations under the License. --> -Maven Resolver uses checksums to verify the integrity of downloaded artifacts and -metadata. Checksums are usually placed in repositories next to the file in question, with the file -extension indicating the checksum algorithm that produced the given file. Currently, -most Maven repositories contain SHA-1 and MD5 checksums as they are produced by Resolver by default. - -Historically, Maven Resolver used `java.security.MessageDigest` to implement checksums. Secure one-way -hashes provided by the Java Cryptography Architecture were (mis)used to implement checksums for transport integrity -validation. Secure hashes MAY be used as checksums, as there is quite some -overlap between checksums and hashes in general. But this simplicity comes at a price: cryptographically safe -algorithms require way more CPU cycles to compute than a simple checksum. However, the purpose of a checksum is just -integrity validation, nothing more. There is no security or trust implied or expected from -them. Checksums do not protect against man-in-the-middle or supply chain attacks. - -To actually trust that artifacts have not been tampered with, you need signatures such as +Maven Resolver uses checksums to verify the integrity of downloaded artifacts and metadata. +Checksums exist in repositories next to the target file. +The file extension identifies the checksum algorithm that produced the checksum. +Most Maven repositories contain SHA-1 and MD5 checksums by default. +Maven Resolver also produces these checksums by default. +Checksums only provide integrity verification. They do not provide security or trust. +They do not protect against man-in-the-middle or supply chain attacks. + +In the past, Maven Resolver used `java.security.MessageDigest` to calculate checksums. +The Java Cryptography Architecture provides secure one-way hashes. +Maven Resolver used these secure hashes to verify transport integrity. +Secure hashes work as checksums, but cryptographically safe algorithms +require many more CPU cycles to calculate than a simple checksum. + +Some users state that specific algorithms are unsafe or deprecated. +This argument does not apply to Maven Resolver because checksums do not provide security. +This fact is true for the SHA-1 algorithm and the MD5 algorithm. +Industry still uses both algorithms today to verify transport integrity and to detect errors. + +To prove that artifacts have not been tampered with, you need signatures such as those provided by the [Maven GPG Plugin](https://maven.apache.org/plugins/maven-gpg-plugin/). -Hence, the usual argument that "XXX algorithm is unsafe, deprecated, not secure anymore" does not apply in the case -of Maven Resolver. Moreover, this is true not only for SHA-1 -algorithm, but even for its "elder brother" MD5. A checksum is not intended to be secure. Both algorithms are still widely used today as "transport integrity -validation" or "error detection" (a.k.a. "bit-rot detection"). - ## Checksum Algorithms SPI -From a technical perspective, the above facts imply the following consequences: because checksum algorithms are exposed -to the user, one can set them via configuration, and thus users are not prevented from asking for SHA-256 or even SHA-512, even if -these algorithms are not part of standard Maven process. Moreover, nothing prevents users (integrating -Maven Resolver) registering an alternate Java Cryptography Provider and using even broader (or exotic) -message digest algorithms for checksums. While this is not wrong, we do consider this as a -bad use case. The notion of transport validation and secure hashes are being constantly mixed up due to historical -reasons explained above. - -Hence, the Maven Resolver team decided to make the supported set of checksum algorithms more controlled. Instead of directly exposing -`MessageDigest` algorithms, we introduced an SPI around checksums. This not only prevents incorrect use cases by not -exposing all supported algorithms of `MessageDigest` to users, but also makes it possible to introduce real checksum -algorithms. Finally, the set of supported checksum algorithms remains extensible: if some required algorithm is -not provided by Resolver, it can easily be added by creating a factory component for it. - -We are aware that users started using "better SHA" algorithms, and we do not want to break them. Nothing for them -changes (configuration and everything basically remains the same). But we do want to prevent any possible further -proliferation of non-standard checksums. - -## Implemented Checksum Algorithms +The user configuration enables POMs to specify arbitrary checksum algorithms, Review Comment: The original was deliberately generic ("one can set them via configuration"). The rewrite introduces "POMs" as the mechanism, but the project's own [expected-checksums.md](https://maven.apache.org/resolver/expected-checksums.html) docs show checksum algorithms are configured via system properties (`aether.layout.maven2.checksumAlgorithms`) and `-D` flags, not POMs. ```suggestion Configuration allows users to specify arbitrary checksum algorithms, even if they are not part of the standard Maven process. ``` ########## src/site/markdown/about-checksums.md: ########## @@ -18,65 +18,62 @@ specific language governing permissions and limitations under the License. --> -Maven Resolver uses checksums to verify the integrity of downloaded artifacts and -metadata. Checksums are usually placed in repositories next to the file in question, with the file -extension indicating the checksum algorithm that produced the given file. Currently, -most Maven repositories contain SHA-1 and MD5 checksums as they are produced by Resolver by default. - -Historically, Maven Resolver used `java.security.MessageDigest` to implement checksums. Secure one-way -hashes provided by the Java Cryptography Architecture were (mis)used to implement checksums for transport integrity -validation. Secure hashes MAY be used as checksums, as there is quite some -overlap between checksums and hashes in general. But this simplicity comes at a price: cryptographically safe -algorithms require way more CPU cycles to compute than a simple checksum. However, the purpose of a checksum is just -integrity validation, nothing more. There is no security or trust implied or expected from -them. Checksums do not protect against man-in-the-middle or supply chain attacks. - -To actually trust that artifacts have not been tampered with, you need signatures such as +Maven Resolver uses checksums to verify the integrity of downloaded artifacts and metadata. +Checksums exist in repositories next to the target file. +The file extension identifies the checksum algorithm that produced the checksum. +Most Maven repositories contain SHA-1 and MD5 checksums by default. +Maven Resolver also produces these checksums by default. +Checksums only provide integrity verification. They do not provide security or trust. +They do not protect against man-in-the-middle or supply chain attacks. + +In the past, Maven Resolver used `java.security.MessageDigest` to calculate checksums. +The Java Cryptography Architecture provides secure one-way hashes. +Maven Resolver used these secure hashes to verify transport integrity. Review Comment: The original's "(mis)used" was intentional editorial commentary — it acknowledged that applying cryptographic hash functions as transport checksums was a design shortcut, which motivates the SPI section that follows. Dropping it entirely loses that context. Consider preserving the nuance, e.g.: > Maven Resolver repurposed these secure hashes as checksums for transport integrity validation. ########## src/site/markdown/about-checksums.md: ########## @@ -18,65 +18,62 @@ specific language governing permissions and limitations under the License. --> -Maven Resolver uses checksums to verify the integrity of downloaded artifacts and -metadata. Checksums are usually placed in repositories next to the file in question, with the file -extension indicating the checksum algorithm that produced the given file. Currently, -most Maven repositories contain SHA-1 and MD5 checksums as they are produced by Resolver by default. - -Historically, Maven Resolver used `java.security.MessageDigest` to implement checksums. Secure one-way -hashes provided by the Java Cryptography Architecture were (mis)used to implement checksums for transport integrity -validation. Secure hashes MAY be used as checksums, as there is quite some -overlap between checksums and hashes in general. But this simplicity comes at a price: cryptographically safe -algorithms require way more CPU cycles to compute than a simple checksum. However, the purpose of a checksum is just -integrity validation, nothing more. There is no security or trust implied or expected from -them. Checksums do not protect against man-in-the-middle or supply chain attacks. - -To actually trust that artifacts have not been tampered with, you need signatures such as +Maven Resolver uses checksums to verify the integrity of downloaded artifacts and metadata. +Checksums exist in repositories next to the target file. +The file extension identifies the checksum algorithm that produced the checksum. +Most Maven repositories contain SHA-1 and MD5 checksums by default. +Maven Resolver also produces these checksums by default. +Checksums only provide integrity verification. They do not provide security or trust. +They do not protect against man-in-the-middle or supply chain attacks. + +In the past, Maven Resolver used `java.security.MessageDigest` to calculate checksums. +The Java Cryptography Architecture provides secure one-way hashes. +Maven Resolver used these secure hashes to verify transport integrity. +Secure hashes work as checksums, but cryptographically safe algorithms +require many more CPU cycles to calculate than a simple checksum. + +Some users state that specific algorithms are unsafe or deprecated. +This argument does not apply to Maven Resolver because checksums do not provide security. +This fact is true for the SHA-1 algorithm and the MD5 algorithm. +Industry still uses both algorithms today to verify transport integrity and to detect errors. + +To prove that artifacts have not been tampered with, you need signatures such as those provided by the [Maven GPG Plugin](https://maven.apache.org/plugins/maven-gpg-plugin/). -Hence, the usual argument that "XXX algorithm is unsafe, deprecated, not secure anymore" does not apply in the case -of Maven Resolver. Moreover, this is true not only for SHA-1 -algorithm, but even for its "elder brother" MD5. A checksum is not intended to be secure. Both algorithms are still widely used today as "transport integrity -validation" or "error detection" (a.k.a. "bit-rot detection"). - ## Checksum Algorithms SPI -From a technical perspective, the above facts imply the following consequences: because checksum algorithms are exposed -to the user, one can set them via configuration, and thus users are not prevented from asking for SHA-256 or even SHA-512, even if -these algorithms are not part of standard Maven process. Moreover, nothing prevents users (integrating -Maven Resolver) registering an alternate Java Cryptography Provider and using even broader (or exotic) -message digest algorithms for checksums. While this is not wrong, we do consider this as a -bad use case. The notion of transport validation and secure hashes are being constantly mixed up due to historical -reasons explained above. - -Hence, the Maven Resolver team decided to make the supported set of checksum algorithms more controlled. Instead of directly exposing -`MessageDigest` algorithms, we introduced an SPI around checksums. This not only prevents incorrect use cases by not -exposing all supported algorithms of `MessageDigest` to users, but also makes it possible to introduce real checksum -algorithms. Finally, the set of supported checksum algorithms remains extensible: if some required algorithm is -not provided by Resolver, it can easily be added by creating a factory component for it. - -We are aware that users started using "better SHA" algorithms, and we do not want to break them. Nothing for them -changes (configuration and everything basically remains the same). But we do want to prevent any possible further -proliferation of non-standard checksums. - -## Implemented Checksum Algorithms +The user configuration enables POMs to specify arbitrary checksum algorithms, +even if they are not part of the standard Maven process. +Users can also register an alternate provider for Java Cryptography that +supplies a broader set of message digests for checksums. +The Maven Resolver team discourages this. -Resolver out of the box provides the following checksum algorithms (important: algorithm names are case sensitive): +To control the supported set of checksums, the Maven Resolver team introduced an SPI for checksums. +We no longer expose `MessageDigest` algorithms directly. +Instead it supports four checksum algorithms: Review Comment: Minor grammar: missing comma after "Instead" (conjunctive adverb), and the antecedent of "it" is unclear since the preceding sentence's subject is "We." ```suggestion Instead, the SPI supports four checksum algorithms: ``` ########## src/site/markdown/about-checksums.md: ########## @@ -18,65 +18,62 @@ specific language governing permissions and limitations under the License. --> -Maven Resolver uses checksums to verify the integrity of downloaded artifacts and -metadata. Checksums are usually placed in repositories next to the file in question, with the file -extension indicating the checksum algorithm that produced the given file. Currently, -most Maven repositories contain SHA-1 and MD5 checksums as they are produced by Resolver by default. - -Historically, Maven Resolver used `java.security.MessageDigest` to implement checksums. Secure one-way -hashes provided by the Java Cryptography Architecture were (mis)used to implement checksums for transport integrity -validation. Secure hashes MAY be used as checksums, as there is quite some -overlap between checksums and hashes in general. But this simplicity comes at a price: cryptographically safe -algorithms require way more CPU cycles to compute than a simple checksum. However, the purpose of a checksum is just -integrity validation, nothing more. There is no security or trust implied or expected from -them. Checksums do not protect against man-in-the-middle or supply chain attacks. - -To actually trust that artifacts have not been tampered with, you need signatures such as +Maven Resolver uses checksums to verify the integrity of downloaded artifacts and metadata. +Checksums exist in repositories next to the target file. +The file extension identifies the checksum algorithm that produced the checksum. +Most Maven repositories contain SHA-1 and MD5 checksums by default. +Maven Resolver also produces these checksums by default. +Checksums only provide integrity verification. They do not provide security or trust. +They do not protect against man-in-the-middle or supply chain attacks. + +In the past, Maven Resolver used `java.security.MessageDigest` to calculate checksums. +The Java Cryptography Architecture provides secure one-way hashes. +Maven Resolver used these secure hashes to verify transport integrity. +Secure hashes work as checksums, but cryptographically safe algorithms +require many more CPU cycles to calculate than a simple checksum. + +Some users state that specific algorithms are unsafe or deprecated. +This argument does not apply to Maven Resolver because checksums do not provide security. +This fact is true for the SHA-1 algorithm and the MD5 algorithm. +Industry still uses both algorithms today to verify transport integrity and to detect errors. + +To prove that artifacts have not been tampered with, you need signatures such as Review Comment: Minor: "prove" is stronger than the original "trust." GPG signatures provide cryptographic assurance from a trusted signer — they establish trust, not mathematical proof. The original word was more precise. ```suggestion To trust that artifacts have not been tampered with, you need signatures such as ``` -- 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]
