For regular updates, because you can minimize but not eliminate risk. As I say in the article that might or might not work for your requirements and practices. For libraries, you also cause compounding churn for your dependents.
For security vulnerabilities, I argue that updating might not be enough! What if your users’ data was compromised? What if your keys should be considered exposed? But the only way to have the bandwidth to do proper triage is by first minimizing false positives.
>For libraries, you also cause compounding churn for your dependents.
This is the thing that I don't really understand but that seems really popular and gaining. The article's section "Test against latest instead of updating" seems like the obvious thing to do, as in, keep a range of compatible versions of dependencies, and only restrict this when necessary, in contrast to deployment- or lockfile-as-requirement which is restricted liberally. Maybe it's just a bigger deal for me because of how disruptive UI changes are.
I would love to learn more. What's the package integrity story of Java and .NET?
All I can find is documentation about artifacts on e.g. Maven Central being signed with any PGP key, which can freely change across package versions. If that's correct, it's no more than a convoluted checksum (without anything resembling the Checksum Database and its transparency log). If that's not correct, I am very curious what the workflow is when a package author loses a key.
Or, more concretely: what's stopping Maven Central from serving a fake version of someone else's package to a targeted victim?
There is no criticism of GitHub in the post, aside from throwing a bit of shade at them using mutable git tags for Actions instead of actually building a package manager.
The lack of verification of ecosystem-specific authenticity is natural, as the post says, in reading source directly from any code host.
NPM has the same problem if you click through to the source repository and expect what you read to match the package. It’s been used to hide attacks in that ecosystem in the same way, and the NPM web UI recently added a code browser similar to the one in this post.
If anything, the extra upload step of NPM (and similar centralized registries) makes things worse by encouraging and normalizing publishing different source from what is in the VCS.
(Also, Go doesn't use GitHub as a package manager. It's just one of the many supported code hosts. In fact, anything that can serve a VCS repo or a zip file is supported.)
Everyone* using AT is using it through BlueSky. If you're not trying to reach those people there isn't any reason to use AT, it's just RSS with an identity centrally tied to BlueSky PBC.
The majority still use bluesky PBC's infra but that's increasingly less true.
- Blacksky has their own full appview for bluesky nowadays + relays and PDS w/ something like 60-70k users. It's small compared to the total bluesky count but it's still very sizable.
- There are countless atproto relays running independent of "big bluesky" and they only cost like 20usd/month max nowadays to run.
- Likewise it's trivial to host your data on any thirdparty PDS and scaling up a PDS community isn't terribly hard (PDS scale linearly up to like 500k users and then it scales linearly past that by just periodically launching a new PDS part of your "cluster")
- And most importantly the UX on migration is getting a lot better so it's reasonably approachable for average users.
--------
Side note but I noticed your name. Are you "the direwolf20"?
You only needed the full copy of all atproto data for the first version of the relay protocol. Since "relay 1.1" relays became a lot thinner.
Nowadays you can run a relay which maintains the current firehose of events + some amount of backfill (commonly a day, week, or month).
Appviews listen to the relay and can save what they care about and can look to other relays if they need more backfill.
So in practice you have your relays for regular use which handle large amounts of outbound traffic and then you have "archival relays" which store all or large portions of the history.
And in the eventual future "archival relays" will likely end up providing backfill for extremely old history via something closer to IPFS (it's the same underlying data structures so this isn't a major change, just nobody has done it yet).
And of course in the event a particular bit of history is missing, a relay can just ask the PDS for a new copy of the data.
-----
TLDR: The 20usd/month is for a relay with like a month or so worth of backlog attached and you can get by with less/cheaper or with more.
Not at all. There are several active relays, some of which serve unique purposes such as the backlinks relay from microcosm.blue. Anyone can run a relay and it is cheap. The expensive thing is running a fully copy of the network in an appview.
The example.com/mod2 go.mod does not in fact affect version resolution, because it's not even fetched. However, it affects the example.com/mod1 go.mod, and the example.com/mod1 go.mod affects version resolution.
This doesn't help with the problem you are describing, but it still has value from a security point of view, because example.com/mod2 truly doesn't matter except to the extent that was already checked into example.com/mod1, which you do need to trust.
If you try to "go build" or "go test" something in example.com/mod2, you actually do get an error since Go 1.17, as if it was not in your dependency tree at all. You need to "go get" it like any new dependency.
As explained in the post, if a transitive dependency asks for a later version than you have in go.mod, that’s an error if -mod is readonly (the default for non-get non-tidy commands).
I encourage you to experiment with it!
This is exactly how the “stricter” commands of other package managers work with lockfiles.
For security vulnerabilities, I argue that updating might not be enough! What if your users’ data was compromised? What if your keys should be considered exposed? But the only way to have the bandwidth to do proper triage is by first minimizing false positives.
reply