Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
algorithm: ErrDigestInvalidFormat on Validate() even for unknown algo…
…rithms In some cases (e.g. Algorithm("foo").Validate("!")) we know the encoded portion is invalid even if we do not have an entry for foo in anchoredEncodedRegexps. Whatever algorithm-specific additional restrictions are applied via anchoredEncodedRegexps, the encoded portion must satisfy the generic encoded-portion restrictions from the DigestRegexp. This commit adjusts the Algorithm("foo").Validate("!") result to match the current Digest("foo:!").Validate() result, and factors the encoded portion of DigestRegexp out into encodedRegexp and encodedRegexpAnchored. It also guards the Size()-based length check with Available(), because Size() returns zero for unavailable algorithms. Now that we have a check for algorithms that aren't in anchoredEncodedRegexps, we can't rely on lookup-misses there to protect us from running the Size() check on unavailable algorithms. And equating anchoredEncodedRegexps hits with Available was dicey anyway, since it depended on what packages get loaded, etc. Adding Algorithm.ValidateIdentifier() allows us to avoid doubling up on the encoded check in Digest.Validate(), since both DigestRegexpAnchored and algorithm.Validate() were covering the encoded portion. The new tests are based on digest_test.go's TestParseDigest. I've also dropped the Available check from Digest.Valid, because we can tell: sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 is a valid digest even if Algorithm("sha256") happens to be unavailable (e.g. because the consumer didn't import crypto/sha256). Available-ness just affects whether you're capable of verifying content against the digest, not digest-validity. Running Algorithm.Validate before Algorithm.ValidateIdentifier uses the presence of an identifier in anchoredEncodedRegexps as a hint to skip the identifier validation. This saves some time (ad Derek's suggestion [1]) and is safe as long as we don't add any invalid identifiers to that map. [1]: opencontainers#34 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
- Loading branch information