Fix checks to allow passing in of sha1 digests through StructuredResults.#676
Conversation
|
/issue 675 |
|
The following is the coverage report on the affected files.
|
lcarva
left a comment
There was a problem hiding this comment.
A few minor comments, but overall it's pretty straight forward.
Do we actually want to support SHA1 since it's been deprecated since 2011?
| prefix := digest.Canonical.String() + ":" | ||
| if !strings.HasPrefix(dig, prefix) { | ||
| return fmt.Errorf("unsupported digest algorithm: %s", dig) | ||
| // 93c56eeba9ec70f74c9bfd297d9516642d366cb5 |
There was a problem hiding this comment.
yeah. That was a testcase. sorry!!!
removed.
| if err := algo.Validate(hex); err != nil { | ||
| return err | ||
| } | ||
| case algo_string == "sha1": |
There was a problem hiding this comment.
It might be worth adding a comment here to explain why sha1 is treated differently.
| return err | ||
| } | ||
| case algo_string == "sha1": | ||
| if !regexp.MustCompile(`^[a-f0-9]{40}$`).MatchString(hex) { |
There was a problem hiding this comment.
Maybe regexp.MustCompile should be called at the package level? Minor performance boost.
| } | ||
| case algo_string == "sha1": | ||
| if !regexp.MustCompile(`^[a-f0-9]{40}$`).MatchString(hex) { | ||
| return fmt.Errorf("sha1 digest %s does not match regexp %s", dig, "^[a-f0-9]{40}$") |
There was a problem hiding this comment.
Let's use Regexp.String() so we don't have to worry about keeping these strings in sync.
eccbcae to
9a0c426
Compare
|
/assign @bobcatfish |
|
The following is the coverage report on the affected files.
|
|
/kind bug |
|
/assign lcarva |
|
@lcarva could you please take another look at the PR. I have addressed all the comments. |
|
/lgtm
I guess adding this support is fine since it's simply used to detect information about artifacts. @wlynch, any objections? |
To provide more context on this. |
wlynch
left a comment
There was a problem hiding this comment.
I guess adding this support is fine since it's simply used to detect information about artifacts. @wlynch, any objections?
Yeah SHA1 is unavoidable with git. AFAIK no git hosting provider supports the sha256 mode for repos yet (and even then it will take a long time to get repos to move over).
As long as we're only using it for input and not our own digest output, it's fine.
| }), | ||
| }, | ||
| { | ||
| Name: "img2_input" + "_" + ArtifactsInputsResultName, |
There was a problem hiding this comment.
nit: I'd include the sha# in the name to distinguish these.
| if strings.HasSuffix(res.Name, categoryMarker) { | ||
| valid, err := isStructuredResult(res, categoryMarker) | ||
| if err != nil { | ||
| logger.Debugf("ExtractStructuredTargetFromResults: %v", err) |
There was a problem hiding this comment.
I don't think we want to error here - I think it's fine if a result happens to have the suffix but doesn't conform to the structured result format.
There was a problem hiding this comment.
+1 agree that we should not error here.
Currently we are just logging a message (although at debug level which does not show up in the logs which is not useful and as such would prefer WARN level atleast) and continuing.
9a0c426 to
a017743
Compare
|
The following is the coverage report on the affected files.
|
sha1 digest not being added into materials. Before this fix checkDigest would only check if the digest was sha256 and would reject other digests. This commit fixes checkDigest to ensue that it accepts all valid digests of type sha256, sha512, sha384 and sha1. Signed-off-by: jagathprakash <31057312+jagathprakash@users.noreply.github.com>
a017743 to
919a6c2
Compare
|
The following is the coverage report on the affected files.
|
|
/retest |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: wlynch The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
sha1 digest not being added into materials. Before this fix checkDigest would only check if the digest was sha256 and would reject other digests. This commit fixes checkDigest to ensue that it accepts all valid digests of type sha256, sha512, sha384 and sha1. Signed-off-by: jagathprakash <31057312+jagathprakash@users.noreply.github.com> Signed-off-by: jagathprakash <31057312+jagathprakash@users.noreply.github.com>
Fixes #636
This PR addresses the issue of artifacts which have sha1 digest not being added into materials.
Before this fix checkDigest would only check if the digest was sha256 and would reject other digests.
This commit fixes checkDigest to ensue that it accepts all valid digests of type sha256, sha512, sha384 and sha1.
Signed-off-by: jagathprakash 31057312+jagathprakash@users.noreply.github.com
Changes
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
Release Notes