5 ms·

A lock file, in my world, contains a cryptographic hash of dependencies. go.mod does not, it only lists tags, which are (in git) movable references. If go.sum

A lock file, in my world, contains a cryptographic hash of dependencies. go.mod does not, it only lists tags, which are (in git) movable references. If go.sum has "no observable effect on builds", you don't know what you're building and go can download and run unverified code. I'm not a go developer and must be misunderstanding something...

PunchyHamster 9mo ago
> I'm not a go developer and must be misunderstanding something... I think it's coz not EVERY language's lockfile comes with checksum So, Go's go.mod is functionally equivalent Ruby Gem lockfile (that doesn't have checksum) but need to get go.sum to be equivalent to npm's (that does come with checksum) Author just compared it to languages where lockfile means just version lock
- wereHamster 9mo ago
  Now I understand :) thanks for clarifying
inglor 9mo ago
You are not misunderstanding anything, I use Go and Rust/TypeScript in my daily work and you are correct - it is the OP that does not understand why people use lockfiles in CI (to prevent minor updates and changes in upstream through verifying a hash signature).
- alias_neo 9mo ago
  I would hazard a guess that the (former) head of the Go security team at Google (OP) _does_ in fact understand.
  - kibwen 9mo ago
    They may be an expert in Go, but from their writing they appear to be misunderstanding (or at least misrepresenting) how things work in other languages. See the previous discussion here: https://lobste.rs/s/exv2eq/go_sum_is_not_lockfile https://lobste.rs/s/exv2eq/go_sum_is_not_lockfile
    - typical182 9mo ago
      > They may be an expert in Go, but from their writing they appear to be misunderstanding (or at least misrepresenting) how things work in other languages Thanks for that link. Based on reading through that whole discussion there just now and my understanding of the different ecosystems, my conclusion is that certainly people there are telling Filippo Valsorda that he is misunderstanding how things work in other languages, but then AFAICT Filippo or others chime in to explain how he is in fact not misunderstanding. This subthread to me was a seemingly prototypical exchange there: https://lobste.rs/s/exv2eq/go_sum_is_not_lockfile#c_d26oq4 https://lobste.rs/s/exv2eq/go_sum_is_not_lockfile#c_d26oq4 Someone in that subthread tells Filippo (FiloSottile) that he is misunderstanding cargo behavior, but Filippo then reiterates which behavior he is talking about (add vs. install), Filippo does a simple test to illustrate his point, and some others seem to agree that he is correct in what he originally said. That said, YMMV, and that overall discussion does certainly seem to have some confusion and people seemingly talking past each other (e.g., some people mixing up "dependents" vs. "dependencies", etc.).
      - kibwen 9mo ago
        > but then AFAICT Filippo or others chime in to explain how he is in fact not misunderstanding. I don't get this impression. Rather, as you say, I get the impression that people are talking past each other, a property which also extends to the author, and the overall failure to reach a mutual understanding of terms only contributes to muddying the waters all around. Here's a direct example that's still in the OP: "The lockfile (e.g. uv.lock, package-lock.json, Cargo.lock) is a relatively recent innovation in some ecosystems, and it lists the actual versions used in the most recent build. It is not really human-readable, and is ignored by dependents, allowing the rapid spread of supply-chain attacks." At the end there, what the author is talking about has nothing to do with lockfiles specifically, let alone when they are applied or ignored, but rather to do with the difference between minimum-version selection (which Go uses) and max-compatible-version selection. Here's another one: "In other ecosystems, package resolution time going down below 1s is celebrated" This is repeating the mistaken claims that Russ Cox made years ago when he designed Go's current packaging system. Package resolution in e.g. Cargo is almost too fast to measure, even on large dependency trees.
JetSetIlly 9mo ago
By default, all go mod downloads go through the golang proxy (https://proxy.golang.org/ https://proxy.golang.org/). That is part of the verification process.
- zelphirkalt 9mo ago
  Does this mean, that when you change the proxy, you lose all guarantees?
  - arccy 9mo ago
    Only if you change checksum servers https://sum.golang.org/ https://sum.golang.org/ Note that the default one uses data from https://proxy.golang.org/ https://proxy.golang.org/
- wereHamster 9mo ago
  Let's assume I publish a github repo with some go code, and tag a particular commit with tag v1.0.0. People start using it and put v1.0.0 into their go.mod file. They use the golang proxy to fetch the code (and that proxy does the "verification", according to your comment). Now I delete the v1.0.0 tag and re-create the tag to point to different (malicious) commit. Will the golang proxy notice? How does it verify that the people that expect the former commit under the v1.0.0 tag will actually get that and not the other (malicious) commit?
  - compsciphd 9mo ago
    yes. From my understanding its stored forever in the proxy cache and your new tag will never be fetched by users who go through the language's centralized infrastructure (i.e. proxy). go can also validate the checksums (go.sum) against the languages central infrastructure that associates version->checksums. i.e. if you cut a release, realize you made a mistake and try to fix it quitely, no user will ever see it if even one user saw the previous version (and that one user is probably you, as you probably fetched it through the proxy to see the mistake)

PunchyHamster 9mo ago

> I'm not a go developer and must be misunderstanding something... I think it's coz not EVERY language's lockfile comes with checksum So, Go's go.mod is functionally equivalent Ruby Gem lockfile (that doesn't have checksum) but need to get go.sum to be equivalent to npm's (that does come with checksum) Author just compared it to languages where lockfile means just version lock

wereHamster 9mo ago
Now I understand :) thanks for clarifying

inglor 9mo ago

You are not misunderstanding anything, I use Go and Rust/TypeScript in my daily work and you are correct - it is the OP that does not understand why people use lockfiles in CI (to prevent minor updates and changes in upstream through verifying a hash signature).

alias_neo 9mo ago
I would hazard a guess that the (former) head of the Go security team at Google (OP) _does_ in fact understand.
- kibwen 9mo ago
  They may be an expert in Go, but from their writing they appear to be misunderstanding (or at least misrepresenting) how things work in other languages. See the previous discussion here: https://lobste.rs/s/exv2eq/go_sum_is_not_lockfile https://lobste.rs/s/exv2eq/go_sum_is_not_lockfile
  - typical182 9mo ago
    > They may be an expert in Go, but from their writing they appear to be misunderstanding (or at least misrepresenting) how things work in other languages Thanks for that link. Based on reading through that whole discussion there just now and my understanding of the different ecosystems, my conclusion is that certainly people there are telling Filippo Valsorda that he is misunderstanding how things work in other languages, but then AFAICT Filippo or others chime in to explain how he is in fact not misunderstanding. This subthread to me was a seemingly prototypical exchange there: https://lobste.rs/s/exv2eq/go_sum_is_not_lockfile#c_d26oq4 https://lobste.rs/s/exv2eq/go_sum_is_not_lockfile#c_d26oq4 Someone in that subthread tells Filippo (FiloSottile) that he is misunderstanding cargo behavior, but Filippo then reiterates which behavior he is talking about (add vs. install), Filippo does a simple test to illustrate his point, and some others seem to agree that he is correct in what he originally said. That said, YMMV, and that overall discussion does certainly seem to have some confusion and people seemingly talking past each other (e.g., some people mixing up "dependents" vs. "dependencies", etc.).
    - kibwen 9mo ago
      > but then AFAICT Filippo or others chime in to explain how he is in fact not misunderstanding. I don't get this impression. Rather, as you say, I get the impression that people are talking past each other, a property which also extends to the author, and the overall failure to reach a mutual understanding of terms only contributes to muddying the waters all around. Here's a direct example that's still in the OP: "The lockfile (e.g. uv.lock, package-lock.json, Cargo.lock) is a relatively recent innovation in some ecosystems, and it lists the actual versions used in the most recent build. It is not really human-readable, and is ignored by dependents, allowing the rapid spread of supply-chain attacks." At the end there, what the author is talking about has nothing to do with lockfiles specifically, let alone when they are applied or ignored, but rather to do with the difference between minimum-version selection (which Go uses) and max-compatible-version selection. Here's another one: "In other ecosystems, package resolution time going down below 1s is celebrated" This is repeating the mistaken claims that Russ Cox made years ago when he designed Go's current packaging system. Package resolution in e.g. Cargo is almost too fast to measure, even on large dependency trees.

JetSetIlly 9mo ago

By default, all go mod downloads go through the golang proxy (https://proxy.golang.org/ https://proxy.golang.org/). That is part of the verification process.

zelphirkalt 9mo ago
Does this mean, that when you change the proxy, you lose all guarantees?
- arccy 9mo ago
  Only if you change checksum servers https://sum.golang.org/ https://sum.golang.org/ Note that the default one uses data from https://proxy.golang.org/ https://proxy.golang.org/
wereHamster 9mo ago
Let's assume I publish a github repo with some go code, and tag a particular commit with tag v1.0.0. People start using it and put v1.0.0 into their go.mod file. They use the golang proxy to fetch the code (and that proxy does the "verification", according to your comment). Now I delete the v1.0.0 tag and re-create the tag to point to different (malicious) commit. Will the golang proxy notice? How does it verify that the people that expect the former commit under the v1.0.0 tag will actually get that and not the other (malicious) commit?
- compsciphd 9mo ago
  yes. From my understanding its stored forever in the proxy cache and your new tag will never be fetched by users who go through the language's centralized infrastructure (i.e. proxy). go can also validate the checksums (go.sum) against the languages central infrastructure that associates version->checksums. i.e. if you cut a release, realize you made a mistake and try to fix it quitely, no user will ever see it if even one user saw the previous version (and that one user is probably you, as you probably fetched it through the proxy to see the mistake)