From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: Using a CDN or some other mirror? Date: Sun, 09 Dec 2018 14:58:51 +0100 Message-ID: <87pnua244k.fsf@gnu.org> References: <20181203154335.10366-1-ludo@gnu.org> <87tvju6145.fsf@gnu.org> <87ftv7l6gy.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49301) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gVzbi-0001Wx-Ay for guix-devel@gnu.org; Sun, 09 Dec 2018 08:58:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gVzbh-0005yK-9S for guix-devel@gnu.org; Sun, 09 Dec 2018 08:58:54 -0500 In-Reply-To: (Hartmut Goebel's message of "Sun, 9 Dec 2018 13:12:20 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Hartmut Goebel Cc: guix-devel@gnu.org, 33600@debbugs.gnu.org Hi Hartmut, Hartmut Goebel 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=E2=80=99t do that. :-) Clearly, I do understand the concerns you list. As a maintainer, I=E2=80= =99m looking for solutions that can address real problems (availability of substitutes and bandwidth) while not being a threat to our user=E2=80=99s 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 ), 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 =E2=80=98guix substitutes=E2=80=99 and only minor chang= es to =E2=80=98guix publish=E2=80=99 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? =E2=80=98guix weather=E2=80=99 can provide in= fo about storage size. Thanks, Ludo=E2=80=99.