unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 39575@debbugs.gnu.org, 28659@debbugs.gnu.org
Subject: bug#39575: guix time-machine fails when a tarball was modified in-place
Date: Mon, 17 Feb 2020 11:18:22 +0100	[thread overview]
Message-ID: <CAJ3okZ08ibXTBqsZMwnuEVdhpyXgHVp6+rNGXB02gsHVqwu53A@mail.gmail.com> (raw)
In-Reply-To: <87k14m3iiy.fsf@gnu.org>

Hi Ludo,

On Sun, 16 Feb 2020 at 11:59, Ludovic Courtès <ludo@gnu.org> wrote:
> zimoun <zimon.toutoune@gmail.com> skribis:
> > On Fri, 14 Feb 2020 at 22:34, Ludovic Courtès <ludo@gnu.org> wrote:

> >> Also, one could argue that we’d steer users towards downloading from our
> >> server, which could be a privacy concern (probably not a strong argument
> >> since one can easily change the substitute URLs.)
> >
> > I am not following the privacy concern.
> > What do you mean?
>
> I mean that by default, someone who’s disabled substitutes (presumably
> out of security or privacy concerns) would find themself downloading
> source code from ci.guix.gnu.org instead of various upstream sites.

I do not see the difference between mirroring and traveling back in
time with missing upstream sources.
And because it is content-addressed, it seems even more secure than
downloading from a upstream URL, IMHO.
If one trusts Guix, then an attacker needs to corrupt in the same time
the Guix history and Berlin (and/or any other farm).
If one does not trust Guix, why does they use the recipe coming from
Guix? To be precise, this person has to check all the recipes of all
the dependencies.

Well, I do not see a security concern because we are talking about
serving the sources.
It is another story when the substitutes serve the results of the
build (binaries); because one does not have any strong guarantee that
the substitute serves the expected binaries.

By privacy concern, do you mean that Guix could collect who downloads
what; in a central fashion? Which is not the case when one downloads
from several distributed upstream sources. Right?
Well, I am not convinced because the case of missing upstream source
is rare. And it is easy to protect against such collecting data
process.
In paranoid mode, traveling back in time is becoming difficult because
of the reliability of the sources; I mean if the sources were
reliable, SWH would not exist. ;-) The solution should be an IPFS /
GNUnet / full distributed archive... which is not ready... yet! :-)


Well, maybe for the TODO list of the time-machine: add an option to
allow substitutes *only* for the sources (substitutes meaning
ci.guix.gnu.org and/or SWH). If this option does not exist yet. ;-)


Cheers,
simon

  reply	other threads:[~2020-02-17 10:19 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-12 13:40 bug#39575: guix time-machine fails when a tarball was modified in-place Jan Nieuwenhuizen
2020-02-12 14:55 ` zimoun
2020-02-13 21:34 ` Ludovic Courtès
2020-02-14  1:05   ` zimoun
2020-02-14 10:03   ` Giovanni Biscuolo
2020-02-14 10:56     ` zimoun
2020-02-14 10:47   ` zimoun
2020-02-14 12:26     ` Ludovic Courtès
2020-02-14 13:24       ` Jan Nieuwenhuizen
2020-02-14 13:51         ` Ludovic Courtès
2020-02-15 15:32           ` zimoun
2020-02-15 20:01             ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2020-02-15 23:57               ` Bengt Richter
2020-02-17  8:47               ` zimoun
2020-02-17 13:26                 ` Efraim Flashner
2020-02-17 15:02                 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2020-02-17 18:32         ` zimoun
2020-02-19 11:58           ` Jan Nieuwenhuizen
2020-02-21 15:58             ` zimoun
2020-02-21 20:48               ` Ludovic Courtès
2020-02-14 12:45     ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2020-02-14 13:14       ` Ludovic Courtès
2020-02-15 15:51         ` zimoun
2020-02-14 13:45   ` Jan Nieuwenhuizen
2020-02-14 21:34     ` Ludovic Courtès
2020-02-15 15:43       ` bug#28659: " zimoun
2020-02-16 10:59         ` Ludovic Courtès
2020-02-17 10:18           ` zimoun [this message]
2020-02-17 14:40             ` Ludovic Courtès
2020-02-17 15:04               ` zimoun
2020-09-09 14:31       ` bug#28659: Content-addressed mirror is not used upon invalid hash zimoun
2020-09-10  8:14         ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJ3okZ08ibXTBqsZMwnuEVdhpyXgHVp6+rNGXB02gsHVqwu53A@mail.gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=28659@debbugs.gnu.org \
    --cc=39575@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).