[
https://issues.apache.org/jira/browse/MRESOLVER-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716445#comment-17716445
]
ASF GitHub Bot commented on MRESOLVER-354:
------------------------------------------
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.
> Document expected checksums
> ---------------------------
>
> Key: MRESOLVER-354
> URL: https://issues.apache.org/jira/browse/MRESOLVER-354
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
> Reporter: Tamas Cservenak
> Assignee: Tamas Cservenak
> Priority: Major
> Fix For: 1.9.9
>
>
> Extend existing checksums documentation, add (reuse) partially done page to
> explain "expected" checksums in resolver regarding new features.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
