The git protocol is more complex and harder to scale. It's especially wasteful if people are going to redownload all packages every time their amnesiac CI runs.
Single-file archives are much easier to distribute.
Digests and signatures have standard algorithms, not unique to git. Key/identity management is the hard part, but git doesn't solve it for you (if you don't confuse git with GitHub).
Someone has to run the git server. Then, someone has to find the git server to pull each gem from, since not every git server is likely to be up-to-date with the each gem, or the correct version. Since these are all decentralized, each individual owner of a git server has to independently scale as more people start using each one.
The benefit to being centralized is... everything is in one place. Everything scales at once. Every update is available at the same time.
We did this back in the day using artifactory and co. to proxy NPM and a few other package managers as well as docker containers and some other things. No third party service going down could keep us from deploying.
Not everyone does it because as a solo developer or a small team, as it feels like pointless overhead.
So GitHub would be one option. Developers already discover all kind of things there. And each gem can still be provided by its “main repository”, but I don’t mind on whatever domain that repository is located. Somewhat how container images are referenced/distributed already. I think go already does it like that too.
having a decentralized, and maybe sometime unavailable, infrastructure would make more people think about the problem and maybe brings us more stable solutions than we have now.
1. Heavy dependency on Github. AKA Microsoft owns much of the golang ecosystem. Not just the source... The package distribution as well!
2. Many packages are referencing a git (short!) commit hash instead of a version. It still boggles my mind that this is an acceptable practice. Not to mention that git tags can be deleted and recreated... A pinnacle of secure package distribution practices.
3. Stuff like ambiguous imports because apparently nothing enforces proper go.mod files? They are not packages to be compiled after all, they're just repos with some conventional structure (optional)...
Mind you, this is popular production-grade software...
I think this is much worse than even node packages, let alone bundler and rubygems...
1. GitHub dominance is a social phenomenon, not a technical requirement. The go.mod file you linked references ~14 different Git hosts other than GitHub. Go's design doesn't create this centralization; it merely reflects where developers choose to host code.
2. You complain about commit hashes while simultaneously noting that tags can be deleted and recreated. Hashes are precisely the solution to mutable tags. The "short hash" concern is a red herring; Git uses sufficient entropy that collisions are not a practical concern for dependency resolution.
As for "secure package distribution," go.sum files verify files verify consistent downloads. What additional security do you believe centralized registries provide?
3. Can you provide a concrete example of an ambiguous import you've encountered? I'm not familiar enough with Go to understand this criticism.
Exactly. This 'social phenomenon' should have been taken into account when designing a packaging system so that the language's ecosystem does not end up entirely dependent on Microsoft due to 'social reasons'.
> The go.mod file you linked references ~14 different Git hosts
Of which the non-github ones account to what... 15% of the deps in the file?
> You complain about commit hashes while simultaneously noting that tags can be deleted and recreated
Yes. Not using versions (semver) is a bad call, and having people be able to mutate the code of a version is a very bad call. Once a version has been tagged, the only viable choice must be to pull that version and push a new higher version.
> As for "secure package distribution," go.sum files verify files verify consistent downloads
Based on git's hash.
> Git uses sufficient entropy that collisions are not a practical concern
Unless crafted by an adversary? Git's sha1 hashes are not a security tool and must not be used in place of code signing.
They are also not good for versioning, as you can't deduce whether a commit introduces breaking changes. Rubygems has the ability to reference git repos. It's always a pain to update these compared to other semver deps -- you have to go to github and do a comparison between the old and new hashes to try and deduce whether bumping this will break you.
> Can you provide a concrete example of an ambiguous import you've encountered
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 people 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.
I thought chrome was already doing this for some google domains and using their own DNS vs. the operating DNS? Maybe I’m wrong, but I thought this was a thing.
Thanks for that note. I receive „spam“ by a US based Car Rentel/Leasing Company, cause they prevent me from unsubscribing because i am in European IP-Range (geo-blocking). Especially „nice“ cause they send me contract specific details of one of their customers, who misspelled his email address.
I'm in a similar boat. A UK bank thinks I'm one of their customers (someone with a similar name). The reply address is no-reply@ and I'm not about to call a foreign bank.
I had the same happen with a AU insurance company that also made it hard to reach them.
I sent an email to their regulator that this company keeps sending me confidential information about one of their clients. It took one day until I received an email from the company informing me that they've corrected the mistake and I shall no longer receive any emails, and it worked, I haven't received a single one since.
If I made a mistake while entering data, I'd be happy if someone told me they receive emails from me that they probably shouldn't be getting, so I do the same when it's not obvious spam/scam.
same. although, if it's a reservation you're being sent, you can cancel it to let the person know they're using the wrong email (plausible deniability because you don't recognize it, yet are getting a reservation)
Getting a U.K. bank account without having a U.K. mailing address isn't the
easiest thing in the world to do. Maybe someone would be interested
in acquiring it from you.
Is this Hertz? Somehow Hertz in Mexico decided to add my email address to their mailing list, and I tried to complain to every level of Hertz to get them to stop. Their hosters didn't care, their upstream didn't care.
I decided to download larger files from their web site a few tens of millions of times, which I think cost them a few hundred dollars. Unethical? Perhaps, but I'm not the kind of person who just accepts that companies are too large to have humans that can communicate and that I should just accept their harassment.
It worked, though. I finally got a response from Hertz saying they were going to "get to the bottom of it", and I finally stopped getting their spam.
When you say "it worked" referring to you downloading big files to generate cost for Hertz, it mean you told them you were doing this and would stop if they remove you from the mailing list?
I received spam for quite a while from Robinhood, back when they suggested they were going to enter the UK market and to sign up for more details.
They didn't but I still recieved spam which I couldn't opt out of because they wanted me to log into my account, even for support, which obviously didn't exist.
At least back then we had Twitter and messaging them publicly got a customer service response.
I know that feeling all too well. There's an Australian guy with a very similar email address that keeps entering it incorrectly, and I end up with the promo emails for these accounts. And because some of them are geolocked to Australian IPs, it's impossible to unsubscribe via the links in the footer.
kinda true, but I'm surprised how some apps expect you to watch movies upright (TV+, Disney), which makes watching movies laying down quite "non ergonomic". ;)
The Meta Quest 2/3 finally fixed that a few months ago [1], where you "tilt" the horizon of the entire OS [2]. So it doesn't matter if an app doesn't support it -- you can lie on your bed and watch a screen directly above you even if it was only designed for horizontal use. It's a game-changer if you have back/neck problems.
Does the AVP not have something equivalent? To be honest, I was surprised it took Meta so long to get around to implementing it.
AVP doesn't support it when in 'theater mode' but if your video is a typical window you can simply lie down and recenter it onto the ceiling. The horizon stays locked but any windows can be parallel to the ground.
