[GitHub] [maven-resolver] slawekjaranowski commented on a diff in pull request #281: [MRESOLVER-354] Document Expected Checksums in Resolver

["slawekjaranowski (via GitHub)" <gi...@apache.org>]

slawekjaranowski commented on code in PR #281:
URL: https://github.com/apache/maven-resolver/pull/281#discussion_r1177049383


##########
src/site/markdown/expected-checksums.md:
##########
@@ -0,0 +1,148 @@
+# Expected Checksums
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+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. 
+
+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.
+
+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).
+
+Instead, 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 

Review Comment:
   An example implementation or demo  - how to implement will be helpful, can be on separated document.



-- 
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: issues-unsubscribe@maven.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org