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.

Sign up for GitHub

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

external-sources: throttle requests to maven central to avoid being rate limited for large sets of java dependencies #2384

Merged
merged 3 commits into from
Jan 22, 2025
Merged

external-sources: throttle requests to maven central to avoid being rate limited for large sets of java dependencies #2384

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
629e71a
external-sources: throttle requests to maven central to avoid being r…
rawlingsj Jan 21, 2025
510acf3
incorporate review feedback, add a unit test for the rate limiter beh…
rawlingsj Jan 21, 2025
a99e15e
fix linting issues
wagoodman Jan 22, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion go.mod
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -67,6 +67,7 @@ require (

require (
github.com/invopop/jsonschema v0.13.0
golang.org/x/time v0.8.0
golang.org/x/tools v0.29.0
)

Expand Down Expand Up @@ -278,7 +279,6 @@ require (
golang.org/x/sys v0.29.0 // indirect
golang.org/x/term v0.28.0 // indirect
golang.org/x/text v0.21.0 // indirect
golang.org/x/time v0.8.0 // indirect
golang.org/x/xerrors v0.0.0-20231012003039-104605ab7028 // indirect
google.golang.org/api v0.215.0 // indirect
google.golang.org/genproto v0.0.0-20241118233622-e639e219e697 // indirect
Expand Down
18 changes: 11 additions & 7 deletions grype/db/v5/matcher/java/matcher.go
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,8 +1,10 @@
package java

import (
"context"
"fmt"
"net/http"
"strings"

v5 "github.com/anchore/grype/grype/db/v5"
"github.com/anchore/grype/grype/db/v5/search"
Expand Down Expand Up @@ -34,11 +36,8 @@ type MatcherConfig struct {

func NewJavaMatcher(cfg MatcherConfig) *Matcher {
return &Matcher{
cfg: cfg,
MavenSearcher: &mavenSearch{
client: http.DefaultClient,
baseURL: cfg.MavenBaseURL,
},
cfg: cfg,
MavenSearcher: newMavenSearch(http.DefaultClient, cfg.MavenBaseURL),
}
}

Expand All @@ -55,7 +54,10 @@ func (m *Matcher) Match(store v5.VulnerabilityProvider, d *distro.Distro, p pkg.
if m.cfg.SearchMavenUpstream {
upstreamMatches, err := m.matchUpstreamMavenPackages(store, d, p)
if err != nil {
log.Debugf("failed to match against upstream data for %s: %v", p.Name, err)
if strings.Contains(err.Error(), "no artifact found") {
log.Debugf("no upstream maven artifact found for %s", p.Name)
}
log.WithFields("package", p.Name, "error", err).Warn("failed to resolve package details with maven")
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@wagoodman was chatting to @luhring and he mentioned that this could still mean that errors could occur and mean results get missed. During my testing I saw 0 failures but am wondering about the semantics of how Grype handled failures like this. Is logging the right way to go as opposed to returning the err?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Anyways, not to distract from this PR, maybe it's a followup thing. Thanks for all the feedback so far!

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, since we're just logging the error and not returning it, I don't think this completely prevents the "silent failure" case, where vuln matches are missing from scan to scan.

My two cents is that we shouldn't let that stop us from merging this. If we start returning an error instead, we'll have a different kind of problem, even though we'd have solved silent failures.

From what I can tell, this PR is forward progress on the issue, and other work will be needed to make other kinds of improvements to the Maven lookups, like #2216. And then the ideal scenario would be a mechanism where Grype could do these lookups offline.

Copy link
Contributor

Choose a reason for hiding this comment

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

@kzantow and I were chatting this through -- we agree that there should be some conditions that halt and force grype to return 1 (e.g. http 429 / 503). We also think there are common cases that should be notable but not change execution (keep on matching... e.g. http 404). All of these cases should probably end up as evidence in a new errors section in the JSON document, and in the table output be reported as a footer noting any issues found.

I'm ok with merging this PR as is since it alleviates a direct problem and iterating towards these other more impactful suggestions as follow ons.

Copy link
Contributor

Choose a reason for hiding this comment

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

fyi -- new issue created #2393

} else {
matches = append(matches, upstreamMatches...)
}
Expand All @@ -76,10 +78,12 @@ func (m *Matcher) Match(store v5.VulnerabilityProvider, d *distro.Distro, p pkg.
func (m *Matcher) matchUpstreamMavenPackages(store v5.VulnerabilityProvider, d *distro.Distro, p pkg.Package) ([]match.Match, error) {
var matches []match.Match

ctx := context.Background()

if metadata, ok := p.Metadata.(pkg.JavaMetadata); ok {
for _, digest := range metadata.ArchiveDigests {
if digest.Algorithm == "sha1" {
indirectPackage, err := m.GetMavenPackageBySha(digest.Value)
indirectPackage, err := m.GetMavenPackageBySha(ctx, digest.Value)
if err != nil {
return nil, err
}
Expand Down
Loading
Loading