Open lukaspj opened 2 months ago
Hi @lukaspj,
Thank you for bringing this issue to our attention. This is a known issue that we are currently aware of.
Currently, we cannot fix CVE-discovered issues for repositories with multiple sub-directories without adding specific configurations. We have plans to enhance our support to remove this requirement in future versions, once we have prioritized this task.
If you have a repository with multiple go.mod
files, I suggest you utilize our Frogbot configuration and add each directory path that holds the go.mod
file to the workingDirs
attribute.
After adding this configuration, it should also work for this repository.
Please feel free to let us know if any other issues arise or if you have further questions regarding this matter. Thank you.
For our purposes, a short term fix is just fine!
I’m curious about the technical limitations though, since the working directory is clearly detected and available during the scanning phase, it’s only the fixing phase that is failing.
Is it because the path is lost during XRay scanning? Is that also why it doesn’t show affected files in the GitHub security tab?
What I'm talking about is this part of the logs:
11:04:35 [Info] Preforming 4 SCA scans:
[
{
"Technology": "go",
"WorkingDirectory": "/tmp/jfrog.cli.temp.-1714475072-1368965406/.pages",
"Descriptors": [
"/tmp/jfrog.cli.temp.-1714475072-1368965406/.pages/go.mod"
]
},
{
"Technology": "go",
"WorkingDirectory": "/tmp/jfrog.cli.temp.-1714475072-1368965406/<path>",
"Descriptors": [
"/tmp/jfrog.cli.temp.-1714475072-1368965406/<path>/go.mod"
]
},
{
"Technology": "go",
"WorkingDirectory": "/tmp/jfrog.cli.temp.-1714475072-1368965406/<path>",
"Descriptors": [
"/tmp/jfrog.cli.temp.-1714475072-1368965406/<path>/go.mod"
]
},
{
"Technology": "npm",
"WorkingDirectory": "/tmp/jfrog.cli.temp.-1714475072-1368965406",
"Descriptors": [
"/tmp/jfrog.cli.temp.-1714475072-1368965406/package.json"
]
}
]
Ah I see, at this point it has already gone kindda wrong because this is not 4 different projects, but a single project with 4 different roots and it gets confused because there are more than one Go root
@lukaspj,
The code for detecting and fixing the issues is located in different repositories and projects. We are utilizing our audit
CLI command to detect the issues, while Frogbot can also implement fixes for them. The log you shared is part of this process when we detect the locations to perform our SCA scan (i.e., part of the audit command).
Currently, after processing these issues, the Descriptors
information is not available and is not included in the results. Consequently, Frogbot assumes it only needs to fix issues in one repository (the root) since it lacks the detected information.
To work around this issue as a short-term solution, you can use our Frogbot configuration and define four working directories for the relative folders you see in the logs you shared. This way, Frogbot will also have this information available, and it should not fail while creating the fixes.
Please feel free to let us know if any other issues arise or if you have further questions regarding this matter. Thank you.
Hello @lukaspj Did @attiasas suggestion helped fixing your issue? Can I close this ticket?
Describe the bug
We just tried installing frogbot and running it in our repository, it finds several go.mod files in subdirectories and reports vulnerabilities just fine. However, it then reports the vulnerability on![image](https://github.com/jfrog/frogbot/assets/2369614/92224bd7-9e1b-4464-b2cd-c6149afee64b)
go.mod
in the root directory, where there isn't any, and subsequently fails to generate fix PRs:Current behavior
I can't share too much of the code and logs, but I can say that this works just fine in another repository with a single go.mod file in a subdirectory, but in this repository there are multiple go.mod files in subdirectories.
Configuration:
Reproduction steps
No response
Expected behavior
No response
JFrog Frogbot version
2.20.2
Package manager info
Go modules
Git provider
GitHub
JFrog Frogbot configuration yaml file
No response
Operating system type and version
ubuntu-latest
JFrog Xray version
No response