Configuration updates during disruption and outage

Imagine this: you’re running a reasonably important site, and you decided to deploy LibResilient to make it, well, resilient.

Your config sets up the fetch plugin, then local cache, and then alt-fetch with some nice independent endpoints (say, an IPFS gateway here, an Tor Onion gateway there). Perhaps with some content integrity checking deployed too, for a peace of mind (no need to completely trust those third party gateway operators, after all).

Content integrity in LibResilient

So far most of LibResilient development was focused on proving the concept and implementing different content fetching plugins. After the project got a small NGI Assure grant, the focus for the previous milestone was instead making the project itself more, well, resilient.

Today another milestone was completed, focusing on integrity of content fetched via LibResilient, and thus on the security of websites deploying it.

LibResilient reaches a milestone!

Took a while (summer holidays got in the way), but LibResilient finally reached a milestone: “Improved resilience of libresilient”. It’s a reasonably big deal, for a number of reasons.

First, that means that development is actually happening again. Second, one of the goals of this milestone was to create a decent testing harness, so that any errors or breakage caused by code changes can be caught early and fixed.

Third, this is the first milestone covered by the NLnet grant for LibResilient. You read that right: LibResilient development is now supported as part of the NGI Assure project. There are six more milestones defined as part of that grant.