First of all, can you just simply not speak in gotchas? I don't even like engaging with this sort of thing. It's a valid question to ask how VCS is the source of truth in this case, but the way you're responding suggests you're not interested in discussing it productively, just a shit-flinging where we argue semantics about what it means for something to be a source of truth, without regards to what the actual important implications are supposed to be. I'm going to try to interpret this in good faith but I feel like I'm probably wasting my time doing so.

Yes, the VCS is still the source of truth, ultimately nothing in the cache or sumdb exists without having existed in the VCS source first. The sumdb is an integrity mechanism bolted on top, and then the module proxy cache is an availability mechanism bolted on top.

Consider the following: let's say Kubernetes depends on some library you have Git access to. So you, being evil, rewrite the tag Kubernetes currently uses to contain malware. There are two possible scenarios:

- By default: the user is using a module cache, so changing a tag that already existed is no different than a Git host being pulled offline from the perspective of the user. The cache continues to serve the original source code, no malware delivered.

- The decentralized case: a user disables both sumdb and the module cache. Guess what? The pull fails. The pull fails because the project has a go.sum file and your tag doesn't match it.

Let's say someone compromised Google's sumdb or module proxy cache. Same basic thing: the go get will fail, because of the local integrity checks.

See, it really changes nothing. The module proxy cache essentially just ensures that a module source code that was once available remains available indefinitely so that you can continue to build old software exactly and securely.

The only place where behavior ever changes meaningfully (as in, not just "available or unavailable") is when go getting a new package or package update. If you have GOPROXY=direct, the poisoned fetch will fail because of global sumdb. If you disable that too, it may still fail because of local sumdb. But if not, you may get someone to pull your mutated tag. (And then the resulting go.sum would fail for other people.)

If you knew for absolute certain that nobody had ever pulled the package before, then theoretically mutating an existing tag would be safe. However, I call shenanigans on this: if you knew for sure nobody had ever pulled it, how in the world did it end up in the sumdb and module proxy cache? Granted, it may have been because of your own CI or something, but still, it stands to reason that this mechanism is introducing a highly desirable property. If a given tag was available once with a given source code I would want to be able to pull it again later and know it isn't tampered with.

In general, I have never seen it interpreted that the possibility of a stale cache changes what the canonical source of truth is. I've also never seen anyone argue that a lockfile changes the canonical source of truth. The Go sumdb being a global integrity mechanism does make it fairly unique, but I don't see it as being categorically different than the integrity checks from lockfiles, it's just that but across multiple users.

Even if you don't like Go's implementation particularly, I still think it is highly worth copying. You can always change a few things. Like for example, you could make module fetch operations not backed by a local checksum skip the global module proxy cache as a safeguard against the proxy itself, only allowing it to be trusted once you already have evidence that the sumdb and canonical source currently agree by virtue of already having a sum.

Sorry I have dropped another text wall, I don't have time to make it shorter. It will happen again.

(I realize that I have ranted in two directions here, but my intention was to 1. Argue that the properties introduced by the design are actually important and desirable, 2. Then argue semantics about whether it changes what one would consider to be the canonical source of truth, second mainly because I consider this to be unimportant. I mean it could be discussed further but, there really should be a point to it other than just semantics.)

> The source of truth remains decentralized, in the individual VCSes.

That's not entirely true, if the VCS's tag changes the proxy might not pick it up.

Changed tags are not allowed in Go (though you can work around it if you really want to boil yourself). All references are hashed so any attempt to alter a published package version will get blocked.

Go has a decentralized append only auditable hashsum db protocol.

> Doesn't matter whether I need to stock up on milk, vegetables or hand peeled shrimp in garlic sauce

I don't even consider those when shopping online.

Density is not the correct measure here because empty land decreases density but doesn't need to be covered. What matters is how much the population is clustered.

But that makes it even worse because a lot of Switzerland is entirely unoccupied mountains whereas millions of people live in places like Kansas and Nebraska and expect to have internet access.

And they do have it, but it does not need to be 25 gbps. Even if they had access to it, they wouldn't/shouldn't pay for it.

25 Gbps is a silly (but illustrative / clickbaity) take in this context. The more relevant measures as others have pointed out is how well-covered clusters of population are, but also what their broadband quality is. I live in Sweden, where we have extremely well-built out broadband networks, especially in cities. (My professional take is that quality is often very poor, but that is comparing to the rest of the country). We are a small country too, but we have still chosen symmetric active ethernet over the assymmetric PON, we have largely discontinued DSL, our cable/coax offerings have largely been replaced with fibre, and where DSL was not profitable, 4G is generally built out well enough to cover most people. Swedes in rural areas buy Starlink not for their reach, but for redundancy or even price.

I would say most of those things are not true in the US market. The united states IS a much, much bigger country, but my guess is that the median reach, stability, and speed is way lower than the Swedish and Swiss examples, compared to what it could be. The US has way higher military costs, still relatively high taxes, and most of all a stronger buying power. I pay $35/month for 300/300 Mbps Active Ethernet FTTH, and consider that overprized. When I last looked, the median American could generally afford more than that, but had access to less. Sorry, I don't have the numbers at hand.

My 8mbps DSL line is $43USD/month after everything, and the cheapest internet I have access to.

The next tier up is Starlink or 250mbps Fiber, which have the same cost. I do not wish to support Starlink. But I also can't afford to almost double my internet bill.

I live on a major national highway in a crossroads town.

Which of the things you said don't also apply to the people in Zurich?

Also, if you say people in Kansas don't need fiber then you have to expect that to get averaged in. The population density in California is less than half what it is in Switzerland. Only 10% of US states have a higher population density than Switzerland and those states represent less than 10% of the US population (because of those 5 states the one with the largest land area is Maryland).

I graduated from a not so incredible university and we had multiple such rooms. Teaching assistants and some tutors helped supervising the exams and it wasn't easy to cheat without getting caught.

It has a Rust-like syntax, enums, matching, traits, etc etc. Yes, it also loses a lot of special characteristics of Rust, but it has to be different somewhere. Moreover a lot of people like Rust as a high level language, i.e. ignoring the lower level capabilities and lifetimes, and this seems to be a direct response to that feeling.

If you are into constructive logic then this will only work for proving negative statements (where indeed the definition is the same as what a proof by contradiction would give you). For positive statements you won't get back a direct proof term of your initial statement, but rather a proof of a double negation of it.

My understanding is that the "logical bits" view breaks down for unions, because the nth logical bit could be at different offsets depending on the union variant that's considered active.

Everyone talking about malware in dev dependencies as if dependabot only raises issues about that, but it does not. It raises warnings about all sort of "vulnerabilities" irrespective of the threat model.

Even worse, it incentivizes randomly updating dependencies, which is what actually allows supply chain attacks.

> I don't buy the notion that tests do not test relevant skills.

> In my long career I've noticed a strong correlation between SAT scores and academic performance as well as job performance.

A test doesn't need to test the relevant skills for that, it just needs to test _something_ that correlates with academic performance and job success.