Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Included REST Spec Changes #2217

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

nathannaveen
Copy link
Contributor

Description of the PR

  • Second Part of Search REST via Purl #2089
  • All the OpenAPI Spec changes have been included
  • The /query/dependencies is no longer going to be used, instead, the /v0/package/{purl}/dependencies and /v0/artifact/{digest}/dependencies will be replacing it.
  • The code in retrieveDependencies.go has been updated to work for the new endpoints.
  • The error handling code has also been updated.

PR Checklist

  • All commits have a Developer Certificate of Origin (DCO) -- they are generated using -s flag to git commit.
  • All new changes are covered by tests
  • If GraphQL schema is changed, make generate has been run
  • If GraphQL schema is changed, GraphQL client updates/additions have been made
  • If OpenAPI spec is changed, make generate has been run
  • If ent schema is changed, make generate has been run
  • If collectsub protobuf has been changed, make proto has been run
  • All CI checks are passing (tests and formatting)
  • All dependent PRs have already been merged

@nathannaveen nathannaveen mentioned this pull request Oct 25, 2024
9 tasks
* Second Part of guacsec#2089
* All the OpenAPI Spec changes have been included
* The `/query/dependencies` is no longer going to be used, instead, the `/v0/package/{purl}/dependencies` and `/v0/artifact/{digest}/dependencies` will be replacing it.
* The code in retrieveDependencies.go has been updated to work for the new endpoints.

Signed-off-by: nathannaveen <[email protected]>
@nathannaveen
Copy link
Contributor Author

👀 @pxp928 @mdeicas @lumjjb

@lumjjb lumjjb added the needs-review Needs writer LGTM label Oct 28, 2024
@lumjjb lumjjb self-requested a review October 28, 2024 15:08
Copy link
Collaborator

@mdeicas mdeicas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great change, thanks @nathannaveen! Thank you as well for splitting the original PR up and adding documentation to the API spec. I added comments but overall it looks good.

Comment on lines +62 to +63
If a partial purl, pkg:foo/bar is passed in, then it would find all purls
associated with the given purl, such as pkg:foo/[email protected], and pkg:foo/[email protected].
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: how are qualifiers handled? For example, will searching for pkg:foo/bar@a=b return both pkg:foo/bar@a=b and pkg:foo/bar@c=d&a=b?

get:
summary: Get dependencies for a specific Package URL (purl)
description: >
If a partial purl is passed in, then it will find all associated purls
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think "associated purls" count as a dependency.

get:
summary: Identify the most important dependencies
operationId: analyzeDependencies
summary: Get vulnerabilities for a specific digest
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I would phrase it as Get vulnerabilities for an artifact, identified by a digest (also in /v0/artifact/{digest}/dependencies)

get:
summary: Get dependencies for a specific Package URL (purl)
description: >
If a partial purl is passed in, then it will find all associated purls
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO these endpoints should operate on a single purl/package that is defined in Guac, instead of handling partial purls. Doing so hides information from the user, and it's not clear if what is returned is directly related to the input package or if it originates from a similar package. Supporting partial purls increases complexity, compounds the inaccuracy of finding the dependencies of a package (https://blog.deps.dev/zillions-of-sboms/), and may lead to drift between the different endpoints.

If a user wants to retrieve the dependencies/vulns of a partial purl, they can just compose /v0/package/{purl} and the dependencies endpoint or /v0/package/{purl} and the vuln endpoint.

get:
summary: Get vulnerabilities for a Package URL (purl)
description: >
If a partial purl is passed in, then it will find all associated purls
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the other comment on using partial vs precise purls in these endpoints.

BadRequestJSONResponse: gen.BadRequestJSONResponse{
Message: "Neither a purl or a digest argument was provided",
}}, nil
unescapedPurl, err := url.QueryUnescape(purl)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for noticing this, it was missing before! It should be PathUnescape though.

Comment on lines +483 to +484
encodedPurl := url.QueryEscape(tt.purl)
encodedArtifact := url.QueryEscape(tt.digest)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the other comments on escaping, but this shouldn't be needed here.

}
}

func Test_ClientErrors(t *testing.T) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason that these tests were removed?

Comment on lines -41 to +40
// Only specify Purl or Digest. The test will set linkCondition, because both are tested
input api.RetrieveDependenciesParams
// Only specify a Purl or a Digest. But, both purls and digests are tested
purl string
digest string
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that the package and artifact functions are separate, I think it makes more sense to split this test suite into one for each.

if !cmp.Equal(v.PurlList, tt.expectedByName, cmpopts.EquateEmpty(), cmpopts.SortSlices(stdcmp.Less[string])) {
t.Errorf("RetrieveDependencies with byName returned %v, but wanted %v", v.PurlList, tt.expectedByName)
if tt.purl != "" {
/******** call the endpoint with byName link condition ********/
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this comment isn't relevant anymore

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-review Needs writer LGTM size/XL
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants