-
-
Notifications
You must be signed in to change notification settings - Fork 155
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
Fix/use go mod for go bom generation #42
Fix/use go mod for go bom generation #42
Conversation
…m, but gathers checksum data from go.sum
I just found one more edge case to handle when parsing the go.mod, so Ill close this for now and reopen once I have this fixed |
Hi @sullivtr Thank you for this significant contribution! If I understand correctly go.mod would have direct dependencies for a reproducible build where as go.sum would have all packages including direct and indirect dependencies right? From a bill of materials perspective we can include all dependencies both direct and indirect but set the Would you be able to implement this change? |
Hi @prabhu, thank you for the quick response on this. There are a couple of reasons the go.sum should not be the primary source of truth when building the bill of materials.
|
Thank you for the detailed clarification @sullivtr What we need is a way to retain both the old and new modes for go since we are more likely to return less results for existing users. Also noticed that this PR is changing the package lock file format. Let me take this PR to a new branch and add some flags to support both the invocation modes along with a clear warning that the old mode might be returning legacy package versions that are not in use. Once this is done I will share the PR with you for comments. |
@prabhu this should be fine. I think as long as we have the ability to generate with go.mod as the source of truth, it certainly does not hurt to have an option to generate based on go.sum if one so desires. I am happy to help in the effort to make this happen. |
…urce of truth for dependencies.
@prabhu So I just went and added the flag (see my latest commit). The output looks like this when passing the --gosum flag: Let me know if this works for you 😄 |
oh nice, love the warning! Instead of cli argument can we use env variable Last change is to revert package-lock.json change and submit it as a separate PR. |
@prabhu done on a bun. I now added the |
utils.js
Outdated
group = name; | ||
} | ||
const version = tmpA[1]; | ||
await getGoPkgComponent(gosumData, group, name, version) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to be an expensive operation since it is iterating all the lines in the text and constructing the string look to determine the hash. Is it possible to build a dict of key and hash as the value once and refer it here directly?
utils.js
Outdated
group = name; | ||
} | ||
const version = tmpA[3] | ||
await getGoPkgComponent(gosumData, group, name, version) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as above
index.js
Outdated
if (DEBUG_MODE) { | ||
console.log(`Parsing ${f}`); | ||
} | ||
goSumReader.push(fs.readFileSync(f, { encoding: "utf-8" })); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of holding the raw text perhaps here we build up an object with key being the full name and value containing the hash. This can be passed to parseGoModData directly.
I was about to click merge and then noticed few more issues. Any thoughts on the refactoring suggested? |
I was on the fence about optimizing this since its not something typically ran in a performance dependent state (as far as I know). However, I can refactor for the optimizations. |
…er lookup, instead of n * x iteration
@prabhu Just pushed some changes to use a dict for faster comparison with go.sum for hash. I did not benchmark the changes or anything, but theoretically, it should be much faster on larger datasets. |
This is looking a lot better and is quite fast too! I just started testing with some of the sample go apps and got the below error for one of them. Happy to still merge this but make a release after a bit more testing actually. Or can wait if you can take a look at what is going on.
Problematic file |
No worries. Ill look into this today, and see if I can repro |
@prabhu were you running this with USE_GOSUM enabled? Or do you also have a go.mod file I can use alongside the go.sum you attached? EDIT: NVM I was able to repo. Looking into this now |
Okay, so I found the issue (whitespace/empty line at the end of the sum file). I just need to ensure there is a value before I try to process it. I will have this fix in before the end of the day 😄 |
Can you try now, @prabhu? |
checkSums = data.split("\n") | ||
for (let d in checkSums) { | ||
const l = checkSums[d]; | ||
if (l.length > 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice one! Not a biggie that this might not be effective if the line is empty but with a space character.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, in this case the go.sum should always be generated, and the /linendings are likely dependent on the machine the go.sum was generated on. In theory a go.sum shouldn't ever contain an empty line with added whitespace
Thanks a ton @sullivtr ! Will do a bit more testing by setting FETCH_LICENSE=true and make a release tonight. |
Description
Changes
Checklist
References
https://github.com/golang/go/wiki/Modules#is-gosum-a-lock-file-why-does-gosum-include-information-for-module-versions-i-am-no-longer-using