SISirSavary·Oct 8, 2025
Thank you for the reply. I'm designing a platform that will include dependency resolution and hosting, so I value input on these issues.
> This 'social phenomenon' should have been taken into account when designing a packaging system
I'm unsure how this would be accomplished in practice without banning certain Git hosts, which seems untenable. Even Maven/Gradle ecosystems concentrate around a few major repositories (Maven Central, JCenter historically). This appears to be an inherent social dynamic rather than a solvable design problem.
> Of which the non-github ones account to what... 15% of the deps
Same question: what's the solution? Developers publish where it's easiest and most popular, creating a positive feedback loop. I don't see how package system design can prevent this.
> Not using versions (semver) is a bad call, and having pe
Read the rest
ople be able to mutate the code of a version is a very bad call
Agreed on both counts. However, how do we enforce immutability beyond operational controls? Even systems with "immutable" version policies ultimately rely on the registry operator honouring that policy. The only technical guarantee would be embedding content hashes alongside version numbers (which is effectively what go.sum does, albeit awkwardly).
Sidebar: how should we handle vulnerable versions? Allow pulling with warnings, or remove them entirely?
> Git's sha1 hashes are not a security tool and must not be used in place of code signing
Fair point. I was under the impression that Git had moved to SHA-256, but it seems there's no practical way to use it yet. While Git moved to a hardened SHA-1 implementation (not vulnerable to the SHAttered attack) in v2.13.0, SHA-1 remains weak for security purposes [1]. The transition to SHA-256 has been in the works for some time, but as of 2022 it appears to be a partial implementation with no support from major Git hosts [2].
What would ideal package security look like to you?
> They are also not good for versioning, as you can't deduce whether a commit introduces breaking changes
Completely agree. Repository references are useful for development and testing, but painful in production. I avoid them in published packages.
> See end of linked go.mod
Thank you, I see it now. I'm still deeply unfamiliar with Go but this feels like a legitimate criticism.
Glancing at github.com/tencentcloud/tencentcloud-sdk-go: is this import ambiguous because there's no top-level `go.mod`? If so, that feels like a significant oversight. I'm a fan of monorepos myself but I'm surprised Go doesn't have better support for them. I'll be doing some research to understand this better.
[1] https://git-scm.com/docs/hash-function-transition
[2] https://lwn.net/Articles/898522/