undefined | Better HN

0 pointsverdverm2y ago0 comments

The CUE team worked with the Go team on the module system. From these interactions, and community input, they decided against using a proxy like Go has. The "exploit" in the article was one of the reasons they made this decision, and chose to use OCI registries instead. The V1 proposal actually proposed using the same Go proxy servers as a stopgap, which received significant pushback from the community (I was probably the loudest voice against the idea). The Go team was supportive at the time, but this would have been exactly what OP talks about, having non-Go projects in the proxy/sumdb.

So CUE's module design can be seen as an evolution on Go's, building on the good parts while addressing some of the shortcomings.

Fun fact, CUE started as a fork of Go, mainly for the internal compiler tooling and packages

0 comments

2 comments · 1 top-level

infogulch2y ago· 1 in thread

One thing that the Go module system solves that seems to be unaddressed in CUE's design based on OCI is the sum database / transparency log.

I could add a "Statement that we might wish to make for a module M" to the "Module contents assurance" section:

- The content of module M is the same content that everyone else sees for the same `$path@$version`.

Though I guess users can utilize existing solutions like https://github.com/sigstore/cosign or rekor (mentioned elsewhere itt).

verdvermOP2y ago

yup, the plan is to enable sigstore for all users, which provides more than just the sumdb hashing integrity.

https://docs.sigstore.dev/verifying/attestation/

j / k navigate · click thread line to collapse