Found by https://github.com/catenacyber/ngolo-fuzzing with oss-fuzz :
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=63873

I appear not to have the permissions needed to view that issue. Can you summarize it here?

This looks due to a quadratic complexity between the number of directories in GOPATH for the build.Context (which do not seem to get deduplicated)

How would the GOPATH field of the build.Context end up set to a long list of invalid or duplicated paths in the first place? (What is the threat model that results in treating quadratic complexity here as a problem?)

and the number of colon-separated entries in srcDir argument for [Context.Import]
The documentation does not seem to mention that srcDir gets interpreted as a colon-separated list of entries...

I don't see how it would end up being treated as such a list — what leads you to believe that it does?

I appear not to have the permissions needed to view that issue. Can you summarize it here?

There is nothing more there beyond the reproducer https://go.dev/play/p/R_pJ6FL70Ok

How would the GOPATH field of the build.Context end up set to a long list of invalid or duplicated paths in the first place? (What is the threat model that results in treating quadratic complexity here as a problem?)

I am not sure there is an issue indeed... But it looks a bit fishy (I do not see any warning in the documentation, and this is the first time ngolo-fuzzing finds something for go/build)

I don't see how it would end up being treated as such a list — what leads you to believe that it does?

If the value gets shorter, we do not get the timeout any longer...
If GOPATH gets shorter, we do not get the timeout any longer...
So, it looks to me that there is a multiplying effect between both... but I did not check the code...

So, it looks to me that there is a multiplying effect between both... but I did not check the code...

I would guess that the quadratic behavior comes from the calls to filepath.EvalSymlinks in hasSubdir, although of course I would want to see a profile or trace to confirm that guess.
(In my experience, calls to EvalSymlinks are usually not the best solution to problems, but in this case they've been there for a long time — I don't think we can just rip them out without a proposal and some analysis.)

Since we don't expect go/build to be used with an attacker-controlled GOPATH, I don't plan to make any changes here. We could probably accept a fix if someone wants to gather a profile or set up a benchmark and can identify a fix that isn't too invasive, but this probably isn't worth adding much (if any!) code complexity to address.

I ran a profile.
Most time is spent in
go/build.(*Context).Import doing a first loop over gopath

for _, root := range gopath { 
    if searchVendor(root, false) { 

Then searchVendor looping over the srcDir being split over `/

for { 
    vendor := ctxt.joinPath(root, sub, "vendor") 
    if ctxt.isDir(vendor) { 
...
    i := strings.LastIndex(sub, "/")
    if i < 0 {
        break
    }					
    sub = sub[:i]

I am ok for closing this