3 ms·

The first thing I noticed is that the cryptographic packages are referenced by an unversioned GitHub URL. E.g.: https://github.com/candiddev/rot/blob/9168285d9c

The first thing I noticed is that the cryptographic packages are referenced by an unversioned GitHub URL. E.g.: https://github.com/candiddev/rot/blob/9168285d9ccfe783dc82343ef1a6468fc21971a1/go/cmdDecrypt.go#L6 https://github.com/candiddev/rot/blob/9168285d9ccfe783dc8234... This type of approach would not pass a code review of something as security-critical as a secrets management tool. E.g.: this generally prevents "reproducible builds", and allows you to "sneak in" changes even if downstream users aren't modifying anything themselves. It's a recipe for a supply-chain attack.

candiddevmike 3y ago
That library you linked to is part of a shared repo we use for all of our stuff, https://github.com/candiddev/shared https://github.com/candiddev/shared, it's versioned using git modules. We own all of the underlying code. We opted for git submodules because go modules hate CalVer, and we share a bunch of other stuff besides go libraries. In the end, things are versioned like any other Go program, builds are 100% reproducible.
jay-barronville 3y ago
I think you’re misunderstanding how Go imports work. In Go projects, the versioning happens in the go.mod file [0]. [0]: https://github.com/candiddev/rot/blob/9168285d9ccfe783dc82343ef1a6468fc21971a1/go.mod#L9 https://github.com/candiddev/rot/blob/9168285d9ccfe783dc8234...
- deleted 3y ago
  [deleted]
- jiggawatts 3y ago
  While admittedly I'm totally unfamiliar with Go package management, it's notable that the "shared" library reference in that link is un-versioned. It uses a pseudo-version of "v0.0.0-00010101000000-000000000000". If I understand the sibling comment by the author[1] correctly, then the versioning of the "shared" module is via Git submodules, which point at a specific commit hash. The only issue is that changes to submodule commit hashes are a little more difficult to audit, because they're embedded in the git repo files instead of the source code. [1] https://news.ycombinator.com/item?id=38596700 https://news.ycombinator.com/item?id=38596700
  - teeray 3y ago
    When used out-of-the-box, go.sum is what provides the cryptographic guarantees of the contents of modules retrieved using go.mod. There’s a distributed log system akin to the TLS certificate transparency log that hardens the system against the kinds of substitution you’ve referred to. You can read more about it here: https://sum.golang.org/ https://sum.golang.org/
  - oefrha 3y ago
    You only looked at the pseudo version and missed the important replace directives replace github.com/candiddev/shared => ./shared replace github.com/google/go-jsonnet => github.com/thequailman/go-jsonnet v0.0.0-20230924031349-110b4ca1dc1a The replacement with ./shared means it's using exactly the version on disk (which is in a submodule here). The go-jsonnet replacement points to a specific commit.

candiddevmike 3y ago

That library you linked to is part of a shared repo we use for all of our stuff, https://github.com/candiddev/shared https://github.com/candiddev/shared, it's versioned using git modules. We own all of the underlying code. We opted for git submodules because go modules hate CalVer, and we share a bunch of other stuff besides go libraries. In the end, things are versioned like any other Go program, builds are 100% reproducible.

jay-barronville 3y ago

I think you’re misunderstanding how Go imports work. In Go projects, the versioning happens in the go.mod file [0]. [0]: https://github.com/candiddev/rot/blob/9168285d9ccfe783dc82343ef1a6468fc21971a1/go.mod#L9 https://github.com/candiddev/rot/blob/9168285d9ccfe783dc8234...

deleted 3y ago
[deleted]
jiggawatts 3y ago
While admittedly I'm totally unfamiliar with Go package management, it's notable that the "shared" library reference in that link is un-versioned. It uses a pseudo-version of "v0.0.0-00010101000000-000000000000". If I understand the sibling comment by the author[1] correctly, then the versioning of the "shared" module is via Git submodules, which point at a specific commit hash. The only issue is that changes to submodule commit hashes are a little more difficult to audit, because they're embedded in the git repo files instead of the source code. [1] https://news.ycombinator.com/item?id=38596700 https://news.ycombinator.com/item?id=38596700
- teeray 3y ago
  When used out-of-the-box, go.sum is what provides the cryptographic guarantees of the contents of modules retrieved using go.mod. There’s a distributed log system akin to the TLS certificate transparency log that hardens the system against the kinds of substitution you’ve referred to. You can read more about it here: https://sum.golang.org/ https://sum.golang.org/
- oefrha 3y ago
  You only looked at the pseudo version and missed the important replace directives replace github.com/candiddev/shared => ./shared replace github.com/google/go-jsonnet => github.com/thequailman/go-jsonnet v0.0.0-20230924031349-110b4ca1dc1a The replacement with ./shared means it's using exactly the version on disk (which is in a submodule here). The go-jsonnet replacement points to a specific commit.