Frea as the backend for legacy packages

[retrohacker]

👋 😃

Heya, I’ve been chipping away at building https://freajs.com as a way to federate the global JavaScript namespace. Would entropic folks be interested in using it? It seems like it would make a great alternative to npm for providing legacy packages 😄

[iarna]

Maybe I'm missing it, but the website says:

none of them have solved for the global namespace in a way that doesn't fragment the community

With the implication that Frea does this, but I don't see any discussion of how?

Also, would you happen to have some discussion of how users can trust the metadata that the Frea registry serves up is the same as the origin registry?

I ask because with the standard npm protocol there are hashes of the package tarballs themselves but the document that contains those is not hashed or signed and anyone who can control that document can inject anything they feel like without consumers knowing any better.

[retrohacker]

With the implication that Frea does this, but I don't see any discussion of how?

Ah super valid, we should expand on that on the website. Frea is a wrapper around the existing global namespace that seeks to maintain parity w/ upstream. We never intend to "fork" the registry, so our origins should be the same as upstream sans frea specific features (nothing to date), and any of those features should gracefully degrade if you use npm as an origin (i.e. fields in the metadata objects that get ignored by non-frea tooling).

This keeps the global namespace homogeneous across projects, meaning you can get the same package from npm that you can get from frea and vice-versa (maybe with a slight propagation delay).

The goal of the project is to get folks to show up with infrastructure at the table willing to help host the registry. We are starting with the simple stuff: mirroring. From there we can start exploring ways to safely federate, or at least share the responsibility/cost for, other parts of the registry (search, security, publishing). But a self imposed constraint of the project is that anything we do w/ frea in the global namespace must remain compatible with what is hosted on npm.

Also, would you happen to have some discussion of how users can trust the metadata that the Frea registry serves up is the same as the origin registry?

You can't at the moment. It's unfortunate that there isn't any way to verify the metadata beyond comparing it to npm, which is one of the reasons we don't serve that metadata from our origins yet. Our cloudflare functions proxy the metadata requests back to npm right now. You can see the code for that here, but there isn't a way for the community to audit that this is what we are actually running (another bummer!). It's also a bummer that the hashes aren't stronger than they are.

It's worth noting that this isn't just a frea problem, we trust npm inc. and it's employees not to tamper with these files as well. I do believe frea is well positioned to help address this. I've been noodling on an idea where we would:

1. Generate a well guarded private/public keypair for frea
2. Have a blessed primary mirror responsible for initial ingress from npm
3. The primary mirror would add a signature to manifest tarball entry with a signed sha512sum using the private key
4. The other mirrors would pull from the primary mirror and wouldn't have the key

This would allow tooling to validate that the hash of the tarball you receive over the wire matches what is declared in the manifest, and that the manifest contains a valid signature. This would also open us up to be easily validated by 3rd parties (walk through CouchDB sequence numbers, grab the manifest from npm and compare it to frea to validate signatures match). This auditing would go both ways, files couldn't be changed on npm's side without the community maintained mirrors catching it, and community maintained mirrors couldn't change files without invalidating the shasums in the manifest files.

Furthermore, we have the ability to implement logic at the network layer with frea thanks to cloudflare functions. We can sample the traffic being delivered by mirrors and compare the shasums of the tarballs being delivered to the manifest to find folks trying to tamper with data. We can also compare what is being delivered by other mirrors to what is hosted on the primary mirror, which would let us detect if the private key was leaked. If we find a manifest that contains a valid hash of the tarball with a valid signature but it doesn't match what is on the primary mirror, we know a key has leaked.