5 ms·

Go’s package repository is just GitHub. At the end of the day, it’s all a URL. You’re asking for a blessed set of URLs. You’d have to convince someone to spen

Go’s package repository is just GitHub. At the end of the day, it’s all a URL. You’re asking for a blessed set of URLs. You’d have to convince someone to spend time maintaining that.

Maskawanian 1y ago
Golang at least gives you the option to easily vendor-ize packages to your local repository. Given what has happened here, maybe we should start doing this more!
- paulddraper 1y ago
  npm has always downloaded to the current directory.
  - Maskawanian 1y ago
    That isn't the same as vendor-izing unless you are committing node_modules to your VCS, which would be insane.
- kelnos 1y ago
  This doesn't really help you. I assume Go records the sha1 hash of the commit it grabs, so it doesn't really matter if you vendor it, or download it every time. The problem comes when you want to upgrade your dependencies. How do you know that they are trustworthy on first use?
  - cyberax 1y ago
    Go uses the hash of the source code, not the commit ID. So there's no difference between vendoring and using the central repo.
mdaniel 1y ago
As hair splitting, that's actually not true: Go's package manager is just version control of which GitHub is currently the most popular hosting. And it also allows redirecting to your own version control via `go mod edit -replace` which leaves the sourcecode reference to GitHub intact, but will install it from wherever you like
- thunky 1y ago
  How does that relate to the bigger conversation here? Are you suggesting people stop pulling Go packages from GitHub and only use local dependencies?
  - mdaniel 1y ago
    I wasn't trying to relate anything to the bigger conversation, I just meant to draw attention to the fact that GitHub is not golang's package manager That said, I would guess the 'bigger conversation' is that it is much harder to tpyo <<import "github.com/DataaDog/datadog-api-client-go/v2/api/datadogV2">> than $(npm i dataadog) or similar in a "flat" package namespace (same for its $(uv pip install dataadog) friend) None of those cited ones fix the dependency lineage issue, proving that release 1.1 was authored by the same chain of custody as release 1.0 of any given package. One can opt in to gpg verified dependencies in Maven, but it is opt-in. The .jar artifacts can also be cryptographically signed, but the risk that's trying to drive down is tamperproofing and not lineage, AFAIK

Go’s package repository is just GitHub. At the end of the day, it’s all a URL. You’re asking for a blessed set of URLs. You’d have to convince someone to spend time maintaining that.

Maskawanian 1y ago

Golang at least gives you the option to easily vendor-ize packages to your local repository. Given what has happened here, maybe we should start doing this more!

paulddraper 1y ago
npm has always downloaded to the current directory.
- Maskawanian 1y ago
  That isn't the same as vendor-izing unless you are committing node_modules to your VCS, which would be insane.
kelnos 1y ago
This doesn't really help you. I assume Go records the sha1 hash of the commit it grabs, so it doesn't really matter if you vendor it, or download it every time. The problem comes when you want to upgrade your dependencies. How do you know that they are trustworthy on first use?
- cyberax 1y ago
  Go uses the hash of the source code, not the commit ID. So there's no difference between vendoring and using the central repo.

mdaniel 1y ago

As hair splitting, that's actually not true: Go's package manager is just version control of which GitHub is currently the most popular hosting. And it also allows redirecting to your own version control via `go mod edit -replace` which leaves the sourcecode reference to GitHub intact, but will install it from wherever you like

thunky 1y ago
How does that relate to the bigger conversation here? Are you suggesting people stop pulling Go packages from GitHub and only use local dependencies?
- mdaniel 1y ago
  I wasn't trying to relate anything to the bigger conversation, I just meant to draw attention to the fact that GitHub is not golang's package manager That said, I would guess the 'bigger conversation' is that it is much harder to tpyo <<import "github.com/DataaDog/datadog-api-client-go/v2/api/datadogV2">> than $(npm i dataadog) or similar in a "flat" package namespace (same for its $(uv pip install dataadog) friend) None of those cited ones fix the dependency lineage issue, proving that release 1.1 was authored by the same chain of custody as release 1.0 of any given package. One can opt in to gpg verified dependencies in Maven, but it is opt-in. The .jar artifacts can also be cryptographically signed, but the risk that's trying to drive down is tamperproofing and not lineage, AFAIK