GitLab

Currently Samizdat is unable to notice if, for whatever reason, content returned by any transport plugin (fetch, or any other that does not inherently provide end-to-end verification of content) is has been maliciously modified.

Scenario 1:

1. Website is deployed with Samizdat in the current default configuration (fetch->cache->gun+ipfs).
2. An adversary takes over the original domain, and deploys a new SSL certificate
3. The adversary then deploys their own versions of some content (index.html, for example)
4. When a user visits the site, fetch succeeds and the adversary-controlled index.html is displayed; alternative transports are not ever used for that file.

Scenario 2:

1. Website is deployed with Samizdat configured to pull content from Google Drive as an alternative endpoint, in case original website is unavailable.
2. An adversary gains access to the Google Drive folder by whatever means and modifies content.
3. Then, the adversary blocks the original domain.
4. Content modified by the adversary is now served to users.

This could be mitigated to some extent with some for of content signing, at least for HTML/CSS/JS, but at a cost of added complexity. Perhaps it could be implemented as an optional plugin, which would wrap any other plugin, and verify the content signature against a known public key of some sort. If the signature does not match (or is absent), throw an error.

The signature could be added as a comment in the last line of text-based files, for example. Headers won't work, since in case of most plugins there is no way to control the headers.