Subject: [bug#33600] Using a CDN or some other mirror?

From: Ludovic Courtès <[email-masked]>
Date: Sun, 09 Dec 2018 14:58:51 +0100

Hi Hartmut,

Hartmut Goebel <[email-masked]> skribis:

> Am 09.12.2018 um 04:33 schrieb Chris Marusich:
>> Instead, we would be using a CDN as a performance optimization that is
>> transparent to a Guix user.  You seem unsettled by the idea of
>> entrusting any part of substitute delivery to a third party, but
>> concretely what risks do you foresee?
>
> I have serious privacy concerns.
>
> TL;DR: A CDN is a centralized infrastructure, allowing to collect
> information about valuable vulnerability information of almost all
> Guix-users and -systems. This is might become a thread to freedom of
> speech, human rights, democracy and economics. Guix should build on a
> decentralized infrastructure.

Heck it would be ironic to find myself arguing in favor of centralized
commercial services.  So I won’t do that.  :-)

Clearly, I do understand the concerns you list.  As a maintainer, I’m
looking for solutions that can address real problems (availability of
substitutes and bandwidth) while not being a threat to our user’s
privacy and security.

The operator of a substitute server (or caching proxy), in general,
knows which IPs downloaded vulnerable software.  This is the main
threat.

This can be mitigated by talking to nearby mirrors and not just
ci.guix.info, a feature we implemented a year ago (see
<https://gnu.org/s/guix/blog/2017/reproducible-builds-a-status-update/>),
or by using several substitute servers, or by not using (or not always
using) substitutes.  Few distros have all these options.

We might also be able to somehow balance requests between several CDNs
or mirrors.

But again, medium- to long-term, the goal is to move towards IPFS or
GNUnet/Bittorrent.  IPFS is attractive because it would probably require
no modifications to ‘guix substitutes’ and only minor changes to ‘guix
publish’ since the IPFS daemon has an HTTP interface.

>> Regarding your suggestion to ask universities to host mirrors (really,
>> caching proxies), I think it could be a good idea.  As Leo mentioned,
>> the configuration to set up an NGINX caching proxy of Hydra (or berlin)
>> is freely available in maintenance.git.  Do you think we could convince
>> some universities to host caching proxies that just run an NGINX web
>> server using those configurations?
>
> The difference is: For a traditional "ftp"-mirror, an organization just
> needs to add another source to its existing configuration and administer
> to the save way as all other mirrors. Whereas for a caching proxy they
> need to change the setup of the web-server and learn how to administer
> the cache. This difference might make it difficult to convince
> organizations to mirror.
>
> I could try and ask a few organizations in my area, but I would need
> figures for this.

What would you need to know?  ‘guix weather’ can provide info about
storage size.

Thanks,
Ludo’.