gnodet commented on code in PR #2010: URL: https://github.com/apache/maven-resolver/pull/2010#discussion_r3639663795
########## src/site/markdown/about-checksums.md: ########## @@ -19,44 +19,45 @@ under the License. --> Maven Resolver uses checksums to verify the integrity of downloaded artifacts and -metadata. Checksums are usually laid out in repositories next to the file in question, with file -extension telling the checksum algorithm that produced the given checksum file content. Currently, -most Maven repositories contain SHA-1 and MD5 checksums by default (they are produced by Resolver by default). +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). Review Comment: Stray closing parenthesis — the opening `(` was removed during the rewrite but `)` was kept: ```suggestion most Maven repositories contain SHA-1 and MD5 checksums as they are produced by Resolver by default. ``` ########## src/site/markdown/about-checksums.md: ########## @@ -19,44 +19,45 @@ under the License. --> Maven Resolver uses checksums to verify the integrity of downloaded artifacts and -metadata. Checksums are usually laid out in repositories next to the file in question, with file -extension telling the checksum algorithm that produced the given checksum file content. Currently, -most Maven repositories contain SHA-1 and MD5 checksums by default (they are produced by Resolver by default). +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. So to say, secure one-way -hashes provided by Java Cryptography Architecture were (mis)used to implement checksums for transport integrity -validation. There is no misunderstanding here, secure hashes MAY be used as checksums, as there is quite some +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 calculate checksum, while all their purpose is just -integrity validation, nothing more. There is no security, trust or whatever else implied or expected from -them. +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. -If you are interested in trust in your artifacts, it is signatures (for example -[GPG Signatures](https://maven.apache.org/plugins/maven-gpg-plugin/)) that you should look for. +To actually trust that artifacts have not been tampered with, you need signatures such +those provided by the +[Maven GPG Plugin](https://maven.apache.org/plugins/maven-gpg-plugin/)). Review Comment: Two issues: (1) missing "as" — "signatures such those" should be "signatures such as those"; (2) stray `)` after the link's closing paren — leftover from the removed `(for example ...)`: ```suggestion To actually trust 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/). ``` -- 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]
