-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/go: operations requiring a go.mod file should abort if go.sum is not present #31978
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
Comments
Since the go tool is the thing that makes the go.sum in the first place, I'd say no. I have definitely had to blow away my go.sum a few times because of a bad hash. At the very least there needs to be a command that'll (re)generate the go.sum. |
Isn't |
No, they should not abort. The go command does create the go.sum unconditionally but whether you check it in or want to remove it and start over is up to you. |
Thank you for your reply Russ. I would appreciate more consideration given to this issue.
I’m assured by Filippo that not having a go.sum file means there is no validation of the contents of the go.mod file. Saying it’s up to the individual developer to opt in to validation by providing a go.sum file feels like the wrong way to approach the work that you and he have done with the notary.
Modules should be secure by default. If a component of that validation story is missing, go.sum, then the go tool should not silently assume that the user wanted to disable module verification. I think that should instead be an explicit, I’m thinking a cli flag, decision.
I hope you’ll reconsider.
Thanks
Dave
… On 14 May 2019, at 06:54, Russ Cox ***@***.***> wrote:
No, they should not abort. The go command does create the go.sum unconditionally but whether you check it in or want to remove it and start over is up to you.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
There’s a bit of misunderstanding here. That is currently true but will not be in Go 1.13 with the checksum database, as the latter will be used to verify the new entries that are added on the fly to the go.sum. However, I still recommend checking in the go.sum file, as its threat model and mechanism is much simpler: if a user can get the source of a project securely, they are guaranteed integrity of its dependencies. It’s ultimate reproducibility for a portion of users (the ones not adding new dependencies) without having to think about gossip, misbehavior alerting or anything else. I don’t think we should fail on lack of go.sum partially because it might be subtle or impossible to distinguish between a new dependency and a missing go.sum line. The checksum database will be there to protect that scenario, even if not as simply as the go.sum file. As we gain more confidence in the checksum database, we might consider disabling the go.sum file by default, but it’s not its time yet. Trust that we care about security by default, and thanks for moving the discussion to an issue. |
@FiloSottile thank you for your response. I'm sorry I'm going to commit the cardinal sin of continuing the discussion on a closed issue but I must ask for a clarification to our discussion as i'm still not certain I understand.
With Go 1.13, do I need to commit a |
I would recommend you do, because that way you make the security of your project self-contained, so your users don't have to reach or rely on the mechanics of the checksum database to build your binary in a perfectly reproducible manner. If you don't, the checksum database will provide the best level of security we can without a |
Hello,
Today in Twitter it was highlighted that the upcoming notary will not replace the go.sum companion to go.mod. Furthermore it seems that operations that read go.mod are insecure unless there is a companion go.sum file.
Should to go tool abort if go.sum is not present or incomplete?
The text was updated successfully, but these errors were encountered: