Re: Guix - GNUnet binary ditribution roadmap

Re: Guix - GNUnet binary ditribution roadmap

[Sree Harsha Totakura]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/11/2014 08:14 PM, Pierre-Antoine Rault wrote:
> Hi,
> 
> Sorry for contacting you directly (without the guix mailing list),
> but Ludovic Courtès recommanded me to contact you as I would like
> to work [1] on integrating GNUnet in Guix as a binary deployment
> and sharing system.
> 
> [1]
> http://lists.gnu.org/archive/html/guix-devel/2014-03/msg00106.html

No problem; I was also following your thread on guix-devel.

> 
> For now I'm afraid I have to catch up with what has been said and
> thus made the following requirements/ideas list (all ideas are not
> from me): * required: users may run a server to share binaries
> (HTTP or GNUnet server).
Let's just stick with the GNUnet server (we call such a server as a
service in GNUnet, let's call it Guix service) as of now.  HTTP can be
done optionally.  Moreover the currently binary distribution is made
through a HTTP server.

> * required: users should use a gpg key to sign their packages.
OK, sounds good.

> * required: users would look for hashes on a dht node (GNUnet node)
> to find user servers.
I am assuming the hash lookup will be against the package and the
result will contain the peers offering the package.  This requires all
nodes which are running the Guix service to publish into DHT the
packages they built or downloaded from others.

> * required: users should be able to add/remove keys to their
> keyring of trusted keys (which would have official keys as a
> basis).

Yes.

> * optional: users' servers could be dht nodes themselves.
This may not be possible.  If you are running the Guix server, you
would want to publish the packages you built into the DHT and for this
you need to run the DHT service.

Anyway, why do you want this option at all?

> * optional: users should be able to share a magnet link [2][3] to 
> one's binaries.
> 
> [2] http://magnet-uri.sourceforge.net/ [3]
> http://magnet-uri.sourceforge.net/magnet-draft-overview.txt
> 
OK, this is a convenience feature.

> I am still reading the GNUnet manual at the moment and have tested
> the GNUnet package on my distribution successfully. Now I am trying
> to come up with a roadmap to develop the system. Do you have an
> idea of what such a roadmap should include/begin with ?

The requirements from Guix side are missing here.  IMO, you have to:
* Understand the current protocol used over HTTP to search and
download packages from Guix Hydra server.
* Implement a equivalent client/downloader in Guix using Guile to
download the packages using GNUnet.
* Extend the Guix daemon to publish package updates into GNUnet DHT,
whenever new packages are added to the Guix store.

The roadmap should contain a plan for implementing these requirements,
the order in which the implementation happens and estimates of how
long each step takes.

To begin with, I suggest you should start experimenting with GNUnet's
DHT by writing an service which publishes periodically some (key,
value) pairs.  In parallel, you may also try to understand the Hydra
protocol.

Regards,
Sree

PS: I could not find your PGP key on keyservers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQEcBAEBAgAGBQJTIK4EAAoJECthXLMALpxG20cH+wX6OyQrOh/AEAGWWDS3NE8P
cxOrABCO5STOQl/dtfBeK/tbk1or8h3IM4h2mB/E+v4bHGxiJ7ajoayRzHpiAc5n
ET0xzuU2UXkN70ld9nXNHqtCBICm43sAGnl+fchkP6kqbjuejoDt6eZLecGjGLMR
F55CuClxg9vqCMTuOaIXQQNLWxWcudLsrp1Qy/As9L7U6fuCZWmqHEgk7vy3CvUD
O3lBZcuR0CAcp8ADvVbywh5xTqCwX51epXNxDD83K13cOjlDNDp4+3dyq4vHr1f1
ZVbzk37Ac+yKSVrQa9XkRS/dermR9doktC9ta1EYofnZe6RcS/YeSRw2VCh0XGA=
=rM/g
-----END PGP SIGNATURE-----

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: Guix - GNUnet binary ditribution roadmap

[Ludovic Courtès]

Sree Harsha Totakura <sreeharsha@totakura.in> skribis:

> On 03/11/2014 08:14 PM, Pierre-Antoine Rault wrote:
>> Hi,
>>
>> Sorry for contacting you directly (without the guix mailing list),
>> but Ludovic Courtès recommanded me to contact you as I would like
>> to work [1] on integrating GNUnet in Guix as a binary deployment
>> and sharing system.
>>
>> [1]
>> http://lists.gnu.org/archive/html/guix-devel/2014-03/msg00106.html
>
> No problem; I was also following your thread on guix-devel.

Cross-posting is fine for this discussion, IMO.

>> For now I'm afraid I have to catch up with what has been said and
>> thus made the following requirements/ideas list (all ideas are not
>> from me): * required: users may run a server to share binaries
>> (HTTP or GNUnet server).
> Let's just stick with the GNUnet server (we call such a server as a
> service in GNUnet, let's call it Guix service) as of now.  HTTP can be
> done optionally.  Moreover the currently binary distribution is made
> through a HTTP server.

Yeah, let’s keep HTTP optional.  The requirement will be to have a
server over GNUnet’s MESH, right?

>> * required: users should use a gpg key to sign their packages.
> OK, sounds good.

For consistency, I’d prefer to use our SPKI-style infrastructure (info
"(guix) Invoking guix archive").

>> * required: users would look for hashes on a dht node (GNUnet node)
>> to find user servers.
> I am assuming the hash lookup will be against the package and the
> result will contain the peers offering the package.  This requires all
> nodes which are running the Guix service to publish into DHT the
> packages they built or downloaded from others.
>
>> * required: users should be able to add/remove keys to their
>> keyring of trusted keys (which would have official keys as a
>> basis).
>
> Yes.

Again, SPKI:

  http://lists.gnu.org/archive/html/guix-devel/2013-12/msg00135.html
  http://theworld.com/~cme/spki.txt
  http://lists.gnu.org/archive/html/guix-devel/2013-12/msg00141.html

SPKI is very flexible, and would allow users to publish “delegation
certificates”.  For instance, I could sign a certificate that says “I
trust packages signed with this key.”  That’s a very useful feature.

(It’s of course similar to OpenPGP’s web of trust, except that OpenPGP
is engineered to handle specifically email/key bindings.)

>> * optional: users' servers could be dht nodes themselves.
> This may not be possible.  If you are running the Guix server, you
> would want to publish the packages you built into the DHT and for this
> you need to run the DHT service.

To me “could be DHT nodes” is the same as could “run the DHT service”.
I think you’re saying the same thing, no?  :-)

> The requirements from Guix side are missing here.  IMO, you have to:
> * Understand the current protocol used over HTTP to search and
> download packages from Guix Hydra server.
> * Implement a equivalent client/downloader in Guix using Guile to
> download the packages using GNUnet.
> * Extend the Guix daemon to publish package updates into GNUnet DHT,
> whenever new packages are added to the Guix store.

I think guix-daemon would remain unchanged.  Instead, the package
publisher could (say) periodically ask for the list of live store items
(as per ‘guix gc --list-live’) and publish those.

> The roadmap should contain a plan for implementing these requirements,
> the order in which the implementation happens and estimates of how
> long each step takes.

Agreed.

However, I think the protocol could be different from, and simpler than
Hydra’s.

Ideally, I imagine you could do something like:

  dht-get /gnu/store/ykmg6ydrmlkn600wklriw3wzc1z3dcli-emacs-24.3

and get as a reply (roughly) a tuple containing:

  1. a signature (as a canonical s-expression);

  2. a reference to a MESH channel from which to download the archive of
     that store item;

  3. additional information about the archive (see the <narinfo>
     structure at
     <http://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/substitute-binary.scm#n192>).

I’m not sure I’m using the right GNUnet terminology/concepts, so do
clarify this.  :-)

> To begin with, I suggest you should start experimenting with GNUnet's
> DHT by writing an service which publishes periodically some (key,
> value) pairs.  In parallel, you may also try to understand the Hydra
> protocol.

Sounds good.  Don’t hesitate to ask questions here and on IRC.

Thanks,
Ludo’.

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: [GNUnet-developers] Guix - GNUnet binary ditribution roadmap

[Sree Harsha Totakura]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/12/2014 09:56 PM, Ludovic Courtès wrote:
>>> Let's just stick with the GNUnet server (we call such a server
>>> as a service in GNUnet, let's call it Guix service) as of now.
>>> HTTP can be done optionally.  Moreover the currently binary
>>> distribution is made through a HTTP server.
> Yeah, let’s keep HTTP optional.  The requirement will be to have a 
> server over GNUnet’s MESH, right?

Yes, so the service should be using both DHT and MESH services of
GNUnet.  DHT to publish and lookup packages and MESH for downloading
and seeding packages.

> 
>>>>> * required: users should use a gpg key to sign their
>>>>> packages.
>>> OK, sounds good.
> For consistency, I’d prefer to use our SPKI-style infrastructure
> (info "(guix) Invoking guix archive").

OK.

>>>>> * optional: users' servers could be dht nodes themselves.
>>> This may not be possible.  If you are running the Guix server,
>>> you would want to publish the packages you built into the DHT
>>> and for this you need to run the DHT service.
> To me “could be DHT nodes” is the same as could “run the DHT
> service”. I think you’re saying the same thing, no?  :-)

Yes, if a node is a DHT node that basically implies that it is running
the DHT service.

>>> The requirements from Guix side are missing here.  IMO, you
>>> have to: * Understand the current protocol used over HTTP to
>>> search and download packages from Guix Hydra server. *
>>> Implement a equivalent client/downloader in Guix using Guile
>>> to download the packages using GNUnet. * Extend the Guix daemon
>>> to publish package updates into GNUnet DHT, whenever new
>>> packages are added to the Guix store.
> I think guix-daemon would remain unchanged.  Instead, the package 
> publisher could (say) periodically ask for the list of live store
> items (as per ‘guix gc --list-live’) and publish those.
> 

OK, I agree; this is also simple.  Does '--list-live' option list all
the items in the store or only the ones currently used?  I believe it
is helpful for other peers to push all items in the store, but then
how do packages age-out?

> However, I think the protocol could be different from, and simpler
> than Hydra’s.
> 
> Ideally, I imagine you could do something like:
> 
> dht-get /gnu/store/ykmg6ydrmlkn600wklriw3wzc1z3dcli-emacs-24.3
> 
> and get as a reply (roughly) a tuple containing:
> 
> 1. a signature (as a canonical s-expression);
> 
> 2. a reference to a MESH channel from which to download the archive
> of that store item;

We also need a peer identity in the tuple since establishing MESH
connections require both the peer identity and a channel number.  MESH
is the GNUnet's equivalent of TCP: peer identity ~= IP address;
channel number ~= port number.

Sree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQEcBAEBAgAGBQJTIOVgAAoJECthXLMALpxG49cH/A9uK5z3R7++uFfrp3LTs7UD
qTZV63wn7y01l2WfX2Yzvj7gMIHNhwojBkfpALgchHVDCbTXtfdDHo5OYFbmpxhN
MqJ6bmrkF2uQ1d1cgWqlByaOERDWEw8RwCjzAwJ0FzEv1P2/5KUXdlQCFwKyd+k+
g5//utsLrEfPzb5KvXEKUCloBCksnt7iBuyhUwy2KH7BaNOc1pmeWUShc5zErH2m
rrZJfa+vS7YqvbpqKN4ZorDoDHW8SqOXJOxStrBuV0qzNq4iCWZkDeomybKEQ/UA
b3YmtKwLIrMEf3f7/mPmAIy3A5mN2yKy4CP3m2dGVObDzuWWCEQX/WvuZCP4Upk=
=Gb1A
-----END PGP SIGNATURE-----

Re: [GNUnet-developers] Guix - GNUnet binary ditribution roadmap

[Ludovic Courtès]

Sree Harsha Totakura <totakura@in.tum.de> skribis:

> On 03/12/2014 09:56 PM, Ludovic Courtès wrote:
>>>> Let's just stick with the GNUnet server (we call such a server
>>>> as a service in GNUnet, let's call it Guix service) as of now.
>>>> HTTP can be done optionally.  Moreover the currently binary
>>>> distribution is made through a HTTP server.
>> Yeah, let’s keep HTTP optional.  The requirement will be to have a
>> server over GNUnet’s MESH, right?
>
> Yes, so the service should be using both DHT and MESH services of
> GNUnet.  DHT to publish and lookup packages and MESH for downloading
> and seeding packages.

OK.

[...]

>>>> The requirements from Guix side are missing here.  IMO, you
>>>> have to: * Understand the current protocol used over HTTP to
>>>> search and download packages from Guix Hydra server. *
>>>> Implement a equivalent client/downloader in Guix using Guile
>>>> to download the packages using GNUnet. * Extend the Guix daemon
>>>> to publish package updates into GNUnet DHT, whenever new
>>>> packages are added to the Guix store.
>> I think guix-daemon would remain unchanged.  Instead, the package
>> publisher could (say) periodically ask for the list of live store
>> items (as per ‘guix gc --list-live’) and publish those.
>>
>
> OK, I agree; this is also simple.  Does '--list-live' option list all
> the items in the store or only the ones currently used?

It lists the items that cannot be garbage-collected because they are
referenced from a GC root (indirectly.)

> I believe it is helpful for other peers to push all items in the
> store, but then how do packages age-out?

When the garbage collector runs, some of the items that were previously
available may have disappeared.  Thus, they must not longer be
advertised in the DHT.

>> However, I think the protocol could be different from, and simpler
>> than Hydra’s.
>>
>> Ideally, I imagine you could do something like:
>>
>> dht-get /gnu/store/ykmg6ydrmlkn600wklriw3wzc1z3dcli-emacs-24.3
>>
>> and get as a reply (roughly) a tuple containing:
>>
>> 1. a signature (as a canonical s-expression);
>>
>> 2. a reference to a MESH channel from which to download the archive
>> of that store item;
>
> We also need a peer identity in the tuple since establishing MESH
> connections require both the peer identity and a channel number.  MESH
> is the GNUnet's equivalent of TCP: peer identity ~= IP address;
> channel number ~= port number.

Yes, sure.

Is it possible to have several values associated with a key in the DHT?

I’m asking because here we’d need to have the ability to get zero or
more tuples as described above, one tuple for each node that claims to
publish /gnu/store/ykmg6ydrmlkn600wklriw3wzc1z3dcli-emacs-24.3.

Ludo’.

Re: Guix - GNUnet binary ditribution roadmap

[Sree Harsha Totakura]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/13/2014 12:15 AM, Ludovic Courtès wrote:
> Is it possible to have several values associated with a key in the
> DHT?
> 
> I’m asking because here we’d need to have the ability to get zero
> or more tuples as described above, one tuple for each node that
> claims to publish
> /gnu/store/ykmg6ydrmlkn600wklriw3wzc1z3dcli-emacs-24.3.

Yes, it is possible to store multiple values under the same key.  The
results of the lookup for that key will then contain none, some or all
of those values.

Later, as an optimisation, we can build a custom DHT block plugin for
Guix packages.  This plugin can then combine several such values of
the same key.  So, in the end we can achieve a list of tuples from a
key lookup instead of getting a single tuple as a response multiple times.

Sree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQEcBAEBAgAGBQJTIWsMAAoJECthXLMALpxGirQH/11Ye/UscEox3yD4N6ns0dW+
goWJpwop6Q/OHnGbskiGa9CniXO9byzp7u5u6bzfWxQAAai61oRbiY41QLllMduN
dU6VzJl4KKnXR8cV6A2CzN0ysLGBMz3pscO2l4M5OyTq238l/oEwlZaD7RXpW/sB
Lu87eFxE3gu1oscfR5iGjP7lQCHwm2tSZHyqOLMlsGDUd9ycX0oI7XvfjifSLUbe
hBSG8KoF4KlYZggcwUyphkLsR2tnys9zShCPxNON3f5PLfyffINs5w0WD09Em3aB
3dqoI1I9QA0hLHRi3VDJ3E50ucth3J2RyH0A4lbbYEe2QMgIr+Kl0YimEU0qrsM=
=c5mk
-----END PGP SIGNATURE-----

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: Guix - GNUnet binary ditribution roadmap

[Christian Grothoff]

[-- Attachment #1.1.1: Type: text/plain, Size: 970 bytes --]

Ludo, would you please consider moving to the GNU Name System?  GNS is
based on SDSI/SPKI (delegation certificates!), and has many other
advantages (not to mention uses Curve25519 instead of RSA).  GNUnet's
identity management is based on Curve25519 ECDSA signatures, and we are
using libgcrypt for those.

My 2 cents

-Christian

On 03/12/2014 09:56 PM, Ludovic Courtès wrote:
> Again, SPKI:
> 
>   http://lists.gnu.org/archive/html/guix-devel/2013-12/msg00135.html
>   http://theworld.com/~cme/spki.txt
>   http://lists.gnu.org/archive/html/guix-devel/2013-12/msg00141.html
> 
> SPKI is very flexible, and would allow users to publish “delegation
> certificates”.  For instance, I could sign a certificate that says “I
> trust packages signed with this key.”  That’s a very useful feature.
> 
> (It’s of course similar to OpenPGP’s web of trust, except that OpenPGP
> is engineered to handle specifically email/key bindings.)
> 

[-- Attachment #1.1.2: 0x48426C7E.asc --]
[-- Type: application/pgp-keys, Size: 14446 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

[-- Attachment #2: Type: text/plain, Size: 162 bytes --]

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: Guix - GNUnet binary ditribution roadmap

[Ludovic Courtès]

Christian Grothoff <grothoff@in.tum.de> skribis:

> Ludo, would you please consider moving to the GNU Name System?

Guix uses the SPKI-like infrastructure for purposes unrelated to the
project at hand (to sign/authenticate archives.)

However, it probably makes sense to rely more on GNS in whatever will be
developed as part of this GSoC.

> GNS is based on SDSI/SPKI (delegation certificates!), and has many
> other advantages (not to mention uses Curve25519 instead of RSA).
> GNUnet's identity management is based on Curve25519 ECDSA signatures,
> and we are using libgcrypt for those.

Guix uses libgcrypt too, essentially manipulating canonical sexps.  So
it could be that integration would be fairly simple?

Ludo’.

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: Guix - GNUnet binary ditribution roadmap

[Christian Grothoff]

On 03/14/2014 12:08 AM, Ludovic Courtès wrote:
> Christian Grothoff <grothoff@in.tum.de> skribis:
> 
>> Ludo, would you please consider moving to the GNU Name System?
> 
> Guix uses the SPKI-like infrastructure for purposes unrelated to the
> project at hand (to sign/authenticate archives.)

Yes, so what? My point is that once you move to ECDSA/Curve25519
to sign/authenticate archives, you will have better crypto and
open the door for a potentially tight integration with GNS.

> However, it probably makes sense to rely more on GNS in whatever will be
> developed as part of this GSoC.
> 
>> GNS is based on SDSI/SPKI (delegation certificates!), and has many
>> other advantages (not to mention uses Curve25519 instead of RSA).
>> GNUnet's identity management is based on Curve25519 ECDSA signatures,
>> and we are using libgcrypt for those.
> 
> Guix uses libgcrypt too, essentially manipulating canonical sexps.  So
> it could be that integration would be fairly simple?

GNUnet doesn't use sexps in the wire format as it it both verbose and
not really the canonical way to represent Curve25519 points (for that,
there is a nice, compact 32-byte binary encoding).  But of course the
conversion is trivial and we do that in libgnunetutil in various
places.

So sexps is really not the issue, the use of RSA vs. Curve25519 is
more what I am concerned about -- as that will increase the complexity
without good reason. (Yes, I can sign RSA keys with Curve25519 and
vice-versa, but that gives us the weaker of the two systems in terms
of security, and the implementation complexity would be higher than
just one of them on top of that.)

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: Guix - GNUnet binary ditribution roadmap

[Ludovic Courtès]

Christian Grothoff <grothoff@in.tum.de> skribis:

> On 03/14/2014 12:08 AM, Ludovic Courtès wrote:
>> Christian Grothoff <grothoff@in.tum.de> skribis:
>> 
>>> Ludo, would you please consider moving to the GNU Name System?
>> 
>> Guix uses the SPKI-like infrastructure for purposes unrelated to the
>> project at hand (to sign/authenticate archives.)
>
> Yes, so what? My point is that once you move to ECDSA/Curve25519
> to sign/authenticate archives, you will have better crypto and
> open the door for a potentially tight integration with GNS.

Sure, but we also want this sort of basic functionality to be available
even when Guix is used without GNUnet support.  So we can’t just get rid
of it.

>> However, it probably makes sense to rely more on GNS in whatever will be
>> developed as part of this GSoC.
>> 
>>> GNS is based on SDSI/SPKI (delegation certificates!), and has many
>>> other advantages (not to mention uses Curve25519 instead of RSA).
>>> GNUnet's identity management is based on Curve25519 ECDSA signatures,
>>> and we are using libgcrypt for those.
>> 
>> Guix uses libgcrypt too, essentially manipulating canonical sexps.  So
>> it could be that integration would be fairly simple?
>
> GNUnet doesn't use sexps in the wire format as it it both verbose and
> not really the canonical way to represent Curve25519 points (for that,
> there is a nice, compact 32-byte binary encoding).  But of course the
> conversion is trivial and we do that in libgnunetutil in various
> places.
>
> So sexps is really not the issue, the use of RSA vs. Curve25519 is
> more what I am concerned about

Guix is not tied to any particular public key crypto algorithm.
Currently we typically use RSA key, as you note, but we could just as
well tell libgcrypt to use something else, no?

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(guix pk-crypto)
scheme@(guile-user)> (generate-key (string->canonical-sexp "(genkey (ecc (curve Ed25519)(flags transient-key)))"))
$6 = #<canonical-sexp 18b3ae0 | 7f1c4bc35030>
scheme@(guile-user)> (canonical-sexp->string $6)
$7 = "(key-data \n (public-key \n  (ecc \n   (curve Ed25519)\n   (q #23D88D433C8350EE110814B9E0B352C42687898B2DDC1A8025016A64049E9118#)\n   )\n  )\n (private-key \n  (ecc \n   (curve Ed25519)\n   (q #23D88D433C8350EE110814B9E0B352C42687898B2DDC1A8025016A64049E9118#)\n   (d #47DF363B3B9A07D98700F1EF4914034C66D6750CA55604EBCE1F37F062E73278#)\n   )\n  )\n )\n"
--8<---------------cut here---------------end--------------->8---

Thanks,
Ludo’.

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: Guix - GNUnet binary ditribution roadmap

[Christian Grothoff]

[-- Attachment #1.1.1: Type: text/plain, Size: 482 bytes --]

On 03/14/2014 02:27 PM, Ludovic Courtès wrote:
> Guix is not tied to any particular public key crypto algorithm.
> Currently we typically use RSA key, as you note, but we could just as
> well tell libgcrypt to use something else, no?

Yes, and my point is you should.  I also do not believe in giving
users choices in this respect, as they will invariably make bad
choices.

For GNS-compatibility, you should use ECDSA on Curve25519 with RFC 6979
(deterministic ECDSA).

[-- Attachment #1.1.2: 0x48426C7E.asc --]
[-- Type: application/pgp-keys, Size: 14446 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

[-- Attachment #2: Type: text/plain, Size: 162 bytes --]

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: Guix - GNUnet binary ditribution roadmap

[Ludovic Courtès]

Christian Grothoff <grothoff@in.tum.de> skribis:

> On 03/14/2014 02:27 PM, Ludovic Courtès wrote:
>> Guix is not tied to any particular public key crypto algorithm.
>> Currently we typically use RSA key, as you note, but we could just as
>> well tell libgcrypt to use something else, no?
>
> Yes, and my point is you should.  I also do not believe in giving
> users choices in this respect, as they will invariably make bad
> choices.

Heh, right.

> For GNS-compatibility, you should use ECDSA on Curve25519 with RFC 6979
> (deterministic ECDSA).

OK, then we should make it the default.  IIUC, this should be:

  (genkey (ecdsa (curve Ed25519) (flags rfc6979)))

Thanks for your feedback!

Ludo’.

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: Guix - GNUnet binary ditribution roadmap

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> Christian Grothoff <grothoff@in.tum.de> skribis:
>
>> On 03/14/2014 02:27 PM, Ludovic Courtès wrote:
>>> Guix is not tied to any particular public key crypto algorithm.
>>> Currently we typically use RSA key, as you note, but we could just as
>>> well tell libgcrypt to use something else, no?
>>
>> Yes, and my point is you should.  I also do not believe in giving
>> users choices in this respect, as they will invariably make bad
>> choices.
>
> Heh, right.
>
>> For GNS-compatibility, you should use ECDSA on Curve25519 with RFC 6979
>> (deterministic ECDSA).
>
> OK, then we should make it the default.  IIUC, this should be:
>
>   (genkey (ecdsa (curve Ed25519) (flags rfc6979)))

Done:
<http://git.savannah.gnu.org/cgit/guix.git/commit/?id=1cbfce16691327bd309d6b03d8cbe3aef38e57bf>.

Ludo’.

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: Guix - GNUnet binary ditribution roadmap

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Ideally, I imagine you could do something like:
>
>   dht-get /gnu/store/ykmg6ydrmlkn600wklriw3wzc1z3dcli-emacs-24.3
>
> and get as a reply (roughly) a tuple containing:
>
>   1. a signature (as a canonical s-expression);

Why only one signature?  I think this should be a set of signatures.

Nodes should accumulate a set of signatures asserting that a given build
output is the result of a given derivation, just as GPG accumulates a
list of signatures on each user id, no?

This is the only way I know of to achieve confidence that the build
outputs are authentic.

      Mark

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: Guix - GNUnet binary ditribution roadmap

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Ideally, I imagine you could do something like:
>>
>>   dht-get /gnu/store/ykmg6ydrmlkn600wklriw3wzc1z3dcli-emacs-24.3
>>
>> and get as a reply (roughly) a tuple containing:
>>
>>   1. a signature (as a canonical s-expression);
>
> Why only one signature?

Because as I view it, everyone would publish its own signature.  Then,
as a user, one can see all those signatures, which is a good thing for
the reasons you mention.

(No I didn’t forget about your very valid ideas on this topic.  ;-))

Ludo’.

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: Guix - GNUnet binary ditribution roadmap

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> Ideally, I imagine you could do something like:
>>>
>>>   dht-get /gnu/store/ykmg6ydrmlkn600wklriw3wzc1z3dcli-emacs-24.3
>>>
>>> and get as a reply (roughly) a tuple containing:
>>>
>>>   1. a signature (as a canonical s-expression);
>>
>> Why only one signature?
>
> Because as I view it, everyone would publish its own signature.  Then,
> as a user, one can see all those signatures, which is a good thing for
> the reasons you mention.

If the accumulation of signatures happens in the DHT, that's fine, but
in that case, did you mean to write that in reply to the 'dht-get'
request that you'd receive "a set of tuples" instead of "a tuple"?

I suppose I'm showing my ignorance of how the GNUnet DHT works.
I apologize for not yet finding the time to study GNUnet properly.

      Mark

Re: Guix - GNUnet binary ditribution roadmap

[Christian Grothoff]

[-- Attachment #1.1.1: Type: text/plain, Size: 401 bytes --]

On 03/13/2014 03:30 PM, Mark H Weaver wrote:
> If the accumulation of signatures happens in the DHT, that's fine, but
> in that case, did you mean to write that in reply to the 'dht-get'
> request that you'd receive "a set of tuples" instead of "a tuple"?

You'll receive a series of replies, each with what we call a 'block' of
information (which would in particular contain one signature).


[-- Attachment #1.1.2: 0x48426C7E.asc --]
[-- Type: application/pgp-keys, Size: 14446 bytes --]

[-- Attachment #1.1.3: 0x48426C7E.asc --]
[-- Type: application/pgp-keys, Size: 14446 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

[-- Attachment #2: Type: text/plain, Size: 162 bytes --]

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: Guix - GNUnet binary ditribution roadmap

[Pierre-Antoine Rault]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

So far, I've summarized the info in a small roadmap I intend to follow
: (source [1] )

Roadmap:
#1 work on the GNUnet service: handling of requests from users
  (tuple(s) answers[see below for structure]). tests with static database.
  * work on a client-side binary list request
  ['--dht' command option developped]
#2 work on the client-side downloading via MESH protocol.
  ['--dht' command option updated]
  * from a known channel and ID.
  * from a dht-requested tuple.
#3 work on the GNS SDSI/SPKI signing of user builds.
  ['spki-sign' command developped]
  [see signing below]
  * work on key generation.
  * work on key storage in a keyring.
  * work on signature via key on a build.
#4 work on the client-side checking of binary signature.
  [update of the download process to include checks at the end]
#5 work on the trust of signatures and filtering of tuples.
  ['--dht' command option updated]
- --- pre-alpha release for user evaluation ? ---
#6 work on the user-side sharing feature.
  ['--dht-share command option added]
  * work on the GNUnet service: use of dht to publish new binary
    proposals.
  * automating listing of and signature on the built packages.
  * automating retrieval of proposed packages from dht database
    as the packages are removed from the user store (sync dht
    proposal with real availability).

#n are consistent units to me ; if you feel they are misordered or
contain an unnecessary/wrong feature, just tell me. Of course, this is
a collaborative pad and you may edit it directly [2].

[1] https://etherpad.fr/p/r.kFGvM6pOS1rnEdBy
[2] https://etherpad.fr/p/guixp2p

If everything if fine, I shall come up with more specific questions
about each step by the time I gather info on it.

Thanks,

- - rigelk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTKKMGAAoJEHfJ0QE7gLd6WxUIAJEj14DdilJZjbuvxT5sHVmy
s93Tv6M83e8c+ShVdMfClHyatLO1ouO83fqTPTZ58CjYdgfCuWNoakLA9vH4YYL0
oAkIydQMqb6h3q6LxOoxJXwEWiVGueP2yaXOIjm/q5wkC2VwmAunHYibiFeYjbXX
Zqykdv0+1e4kLpEqRwfpE2V1WPGpplLAlRsyEczv0B+oXNso2wpmIvni0LoBGiB4
LS8SmJmROc9pnP98U132sa+pGByedg8BUUMrFe1lesP8Ffdima7fKy3Kgz0CPVWq
9cEo2NEUXtvj85guwa2RVZ6EFErA4pQ3ddTawVAbXjDul7nyAXXLqh6EpZ/NqOU=
=RHTi
-----END PGP SIGNATURE-----

Re: Guix - GNUnet binary ditribution roadmap

[Ludovic Courtès]

Hi,

Thanks for sharing your tentative roadmap.

Pierre-Antoine Rault <par@rigelk.eu> skribis:

> Roadmap:
> #1 work on the GNUnet service: handling of requests from users
>   (tuple(s) answers[see below for structure]). tests with static database.
>   * work on a client-side binary list request

This is so abstract that I’m not sure what is meant here.  I’d like to
see clearer connections to the Guix and GNUnet code.

For instance, “requests from users” and “client-side binary list
request” are very abstract (and slightly misleading, because every
client is likely to be also a server, that’s p2p.)

Could you instead specify the underlying mechanisms involved?

I’d like to see something like:

  Publication of build products works like this:

    1. users runs the new ‘guix publish’ command, which inserts in the
       GNUnet DHT a key/tuple pair, where the tuple contains [list the
       fields etc.].

    2. ‘guix publish’ opens a GNUnet MESH channel to serve these files
       [explain how it’s used, possibly using the ‘gnunet-mesh’ command
       to illustrate, showing the kind of “channel identifier” that you
       get, describing how this interacts with the GNUnet peer
       identity, etc.]

       Files are served as Guix archives signed by the daemon’s key (?).

  Lookup of build products works like this:

    1. users look up the store file name, such as
       /gnu/store/...-emacs-24.3 in the GNUnet DHT.  This lookup is
       implemented as a substituter (akin to ‘guix substitute-binary’
       except that it uses GNUnet instead of direct HTTP connections.)
       Thus it’s completely transparent for the user: ‘guix build’,
       ‘guix package’ etc. magically get to use GNUnet to look for
       binaries.

    2. upon the list of matching answers, the substituter selects the
       first one offered by a peer whose trusted key is in the guix
       archive ACL.

    3. substituter connects to remote peer’s MESH channel specified in
       the tuple, retrieves the archive, checks their signature like
       ‘guix archive --import’ does.

There are a number of dots to be filled in here.  I think it’s important
to understand the mechanisms involved, and from there to fill in the
dots.

Then we can devise the milestones and a general roadmap.

WDYT?

> #3 work on the GNS SDSI/SPKI signing of user builds.
>   ['spki-sign' command developped]
>   [see signing below]
>   * work on key generation.
>   * work on key storage in a keyring.
>   * work on signature via key on a build.

Is there something to implement at all?  What about using what Guix or
what GNUnet provides?  This needs to be clarified.

> #4 work on the client-side checking of binary signature.
>   [update of the download process to include checks at the end]

Likewise.

> #5 work on the trust of signatures and filtering of tuples.
>   ['--dht' command option updated]

Likewise.

Ludo’.

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers