From mboxrd@z Thu Jan 1 00:00:00 1970 From: Subject: Re: [GSoC] Draft of my proposition Date: Wed, 23 Mar 2016 22:37:27 +0000 (GMT) Message-ID: References: < (vincent@cloutier.co's message of "Mon, 21 Mar 2016 00:40:12 +0000 (GMT)")> <87h9g09nrr.fsf@gnu.org> < (vincent@cloutier.co's message of "Mon, 21 Mar 2016 22:19:09 +0000 (GMT)")> <87fuvhvhu2.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_29510_775579293.1458772647036" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1airPF-0002Hg-56 for guix-devel@gnu.org; Wed, 23 Mar 2016 18:37:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1airPB-0002aM-O6 for guix-devel@gnu.org; Wed, 23 Mar 2016 18:37:37 -0400 Received: from w1.tutanota.de ([81.3.6.162]:51950) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1airPB-0002Zh-E4 for guix-devel@gnu.org; Wed, 23 Mar 2016 18:37:33 -0400 Received: from localhost (unknown [127.0.0.1]) by w1.tutanota.de (Postfix) with ESMTP id A3918FA82C0 for ; Wed, 23 Mar 2016 22:37:30 +0000 (UTC) Received: from w1.tutanota.de ([127.0.0.1]) by localhost (w1.tutanota.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvYSTYKlNV_s for ; Wed, 23 Mar 2016 22:37:27 +0000 (UTC) Received: from w1.tutanota.de (unknown [127.0.0.1]) by w1.tutanota.de (Postfix) with ESMTP id 0CB49FA82FC for ; Wed, 23 Mar 2016 22:37:27 +0000 (UTC) In-Reply-To: <87fuvhvhu2.fsf@gmail.com> 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Guix Devel ------=_Part_29510_775579293.1458772647036 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 23. Mar 2016 02:17 by cmmarusich@gmail.com: > <> vincent@cloutier.co> > writes: > >> Since Guix users know in advance the hash of the data they want, >> downloading from peers has no security implications (and privacy can >> be done trough proxies). > > How will trust work in the IPFS world? I think maybe you touch on this > when you later mention "building consensus on a package=E2=80=99s hash", = but it > wasn't entirely clear to me. IPFS checks the integrity of the content you download and that's it. You ha= ve=20 to validate in other ways that the content you want has effectively a given= =20 hash. I think it's a very big advantage, because it totally uncouples the p2p=20 sharing from the trust system. Users do not have to agree to be on the same= =20 security scheme. One could configure his system in a way that it will only= =20 download content signed by, let's say the FSF and the EFF, and another user= =20 downloads only when signed by his employers. Both those users will be able = to=20 share the same data with one another, because the data is separated from th= e=20 signature. That's what I meant by "building consensus on a package=E2=80=99s hash", be= cause the=20 community will be able to innovate to build a trust system. :) =C2=A0 > My understanding is that because Guix uses a cryptographic hash > function, it's true that if you have some data, you know the expected > hash value of that data, and the computed hash value of the data matches > the expected hash value, then you can be confident that the data hasn't > been corrupted or tampered with. However, how do you know the expected > hash value was correct to begin with? How can you trust it? =C2=A0 IPFS does not aim to solve the last part.=C2=A0 > Currently, I believe that Guix handles trust by refusing to use > substitutes that are not signed by a trusted key. The substitutes built > and vended by hydra.gnu.org are signed with Hydra's key, and users of > Guix must trust Hydra's key in order to use Hydra's substitutes. Users who trust Hydra will be able do download substitutes from one another= ,=20 if the package is signed by Hydra. This should come as a relief to hydra's= =20 servers! :) I could also add that a package must be signed by the all the user's truste= d=20 substitutes before downloading. >> I have a fascination for peer-to-peer tech and I am constantly looking >> for the innovative new tech in this area (Bitcoin, Ethereum, >> etc). Less than a year ago I discovered IPFS, a project that takes the >> best ideas from BitTorrent and Git to create a simple and elegant >> protocol. >> >> IPFS allows one to find who has a piece of content and is ready to >> share it, when knowing only the content=E2=80=99s hash. Content is added= in a >> reproducible manner and deduplication can be added via Merkle >> trees. IPFS is also content-agnostic, one could serve Guix=E2=80=99s pro= grams >> without even running Guix. It would also be possible to share text or >> video documentation using IPFS. > > This is a very compelling idea! Thank you for sharing it; IPFS is new > to me, and it looks intriguing. I understand that in the past, R=C3=A9mi > Birot-Delrue did some work on a similar project to enable publication of > packages over GNUnet: > > https://lists.gnu.org/archive/html/guix-devel/2015-05/msg00022.html > > Although progress was made, I don't think the project to publish > packages over GNUnet was fully completed. This seems to be the last > email thread from R=C3=A9mi: > > https://lists.gnu.org/archive/html/guix-devel/2015-08/msg00455.html > > Have you considered picking up where R=C3=A9mi left off? Even if you cho= ose > not to use GNUnet instead of IPFS, perhaps R=C3=A9mi's prior work can hel= p > you as you work on your project. I think IPFS simpler and more stable API is a must. But I will definitely b= e=20 looking into reusing parts of his code, either for IPFS or making it usable= =20 for both. I could be an interesting stretch goal. >> A couple of years ago I realized that every tool I had learn and >> everything that I tinkered with was free and open source >> software. Almost everything I achieved with computers was because of >> people who shared their knowledge and technologies and I want to >> contribute back. > > That's fantastic! Thank you for stepping up and helping. Thanks to you for making it possible :) - Vincent ------=_Part_29510_775579293.1458772647036 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


23. Mar 2016 02:17 by cmmarusich@gmail.com:

<vincent@cloutier.co> writes:
Since Gui= x users know in advance the hash of the data they want,
downloading fr= om peers has no security implications (and privacy can
be done trough = proxies).

How will trust work in the IPFS world? I think= maybe you touch on this
when you later mention "building consens= us on a package=E2=80=99s hash", but it
wasn't entirely clear to = me.


IPFS checks the integrity of the content yo= u download and that's it. You have to validate in other ways that the conte= nt you want has effectively a given hash.


I think= it's a very big advantage, because it totally uncouples the p2p sharing fr= om the trust system. Users do not have to agree to be on the same security = scheme. One could configure his system in a way that it will only download = content signed by, let's say the FSF and the EFF, and another user download= s only when signed by his employers. Both those users will be able to share= the same data with one another, because the data is separated from the sig= nature.


That's what I meant by "building con= sensus on a package=E2=80=99s hash", because the community will be abl= e to innovate to build a trust system. :)

 

My understanding is that because Guix = uses a cryptographic hash
function, it's true that if you have some da= ta, you know the expected
hash value of that data, and the computed ha= sh value of the data matches
the expected hash value, then you can be = confident that the data hasn't
been corrupted or tampered with. Howev= er, how do you know the expected
hash value was correct to begin with?= How can you trust it?

 

IPFS does not aim to s= olve the last part. 


Currently, I believe that Guix handles trust by refusing to= use
substitutes that are not signed by a trusted key. The substitute= s built
and vended by hydra.gnu.org are signed with Hydra's key, and u= sers of
Guix must trust Hydra's key in order to use Hydra's substitute= s.


Users who trust Hydra will be able do downlo= ad substitutes from one another, if the package is signed by Hydra. This sh= ould come as a relief to hydra's servers! :)


I could als= o add that a package must be signed by the all the user's trusted substitut= es before downloading.


I have a fascination for peer-to-peer tech and I = am constantly looking
for the innovative new tech in this area (Bitcoi= n, Ethereum,
etc). Less than a year ago I discovered IPFS, a project t= hat takes the
best ideas from BitTorrent and Git to create a simple an= d elegant
protocol.

IPFS allows one to find who has a piece= of content and is ready to
share it, when knowing only the content=E2= =80=99s hash. Content is added in a
reproducible manner and deduplicat= ion can be added via Merkle
trees. IPFS is also content-agnostic, one = could serve Guix=E2=80=99s programs
without even running Guix. It woul= d also be possible to share text or
video documentation using IPFS.
This is a very compelling idea! Thank you for sharing it; = IPFS is new
to me, and it looks intriguing. I understand that in the = past, Rémi
Birot-Delrue did some work on a similar project to e= nable publication of
packages over GNUnet:

https://lists.gnu.org/archive/html/guix-devel/2015-05/msg00022.html<= /a>

Although progress was made, I don't think the project to pub= lish
packages over GNUnet was fully completed. This seems to be the l= ast
email thread from Rémi:

h= ttps://lists.gnu.org/archive/html/guix-devel/2015-08/msg00455.html

Have you considered picking up where Rémi left off? Even if = you choose
not to use GNUnet instead of IPFS, perhaps Rémi's pr= ior work can help
you as you work on your project.


I think IPFS simpler and more stable API is a must. But I will def= initely be looking into reusing parts of his code, either for IPFS or makin= g it usable for both. I could be an interesting stretch goal.

<= br />

A couple of = years ago I realized that every tool I had learn and
everything that I= tinkered with was free and open source
software. Almost everything I = achieved with computers was because of
people who shared their knowled= ge and technologies and I want to
contribute back.

T= hat's fantastic! Thank you for stepping up and helping.

Thanks to you for making it possible :)



- Vincent

------=_Part_29510_775579293.1458772647036--