unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Guix + GNUnet at GSoC?
@ 2015-03-04 21:12 Ludovic Courtès
  2015-03-05 13:48 ` Christian Grothoff
  0 siblings, 1 reply; 5+ messages in thread
From: Ludovic Courtès @ 2015-03-04 21:12 UTC (permalink / raw)
  To: gnunet-developers; +Cc: guix-devel

Hello GNUnetters!

Last year we submitted that project idea entitled “Supporting binary
package distribution through GNUnet”:

  http://www.gnu.org/software/soc-projects/ideas-2014.html#guix

It’s GSoC time again, so I was pondering whether we should put it on
display again.

I actually wonder if this is a good time: there hasn’t been a release in
a while, and my (limited) understanding is that the relevant GNUnet
components may not have fully settled yet (IIRC the “MESH” layer had
landed just about the same time last year.)  If we were to propose this
idea, we would need to make sure the rough design we have in mind, and
the APIs that would be used, would still be valid and stable enough when
the student starts working on it.

WDYT?

Thanks,
Ludo’.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Guix + GNUnet at GSoC?
  2015-03-04 21:12 Guix + GNUnet at GSoC? Ludovic Courtès
@ 2015-03-05 13:48 ` Christian Grothoff
  2015-03-05 22:33   ` [GNUnet-developers] " Ludovic Courtès
  0 siblings, 1 reply; 5+ messages in thread
From: Christian Grothoff @ 2015-03-05 13:48 UTC (permalink / raw)
  To: gnunet-developers; +Cc: guix-devel


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

Hi Ludo,

Yes, I think we should. MESH (now CADET) is much further along and the
API is stable.  I also don't see any other significant roadblocks.

Nevertheless, I agree that we should have some more design discussions,
as I can still imagine many ways how one _might_ do this -- and in any
case we need to come up with a reasonable feature list.  In fact, maybe
that's the best starting point: what are all the things you would like
"binary package distribution" to do?  I don't think we ever tried to
write a comprehensive feature list. I have in mind:

1) Transfer of source code (with signatures / integrity checking /
   build rules)
2) Transfer of binary packages (with signatures / integrity checking),
   which also requires
   - specification of platforms (what is binary-compatible)
   - specification of platform-independent resources
     ("noarch"/"all"/"data")
3) Incremental updates
   - to source (i.e. "diff")
   - to binaries (funky binary-diff)
4) Notification about available updates to sources (to individual
   packages or full distribution by distribution authority), or
   signed messages asserting no updates are available (also important
   to avoid adversary preventing upgrade)
5) Notification about available updates to binaries (including
   signatures of binary package builders arriving at the same
   (or different!?) deterministic build hash)
6) A trust graph / metric / WoT-like construction to determine
   how many (and which) binary package builders are needed before
   we trust third-party binaries (instead of building ourselves
   from source)
7) Automatically offering packages the local system has build to
   others (or not)
8) Delegation of build authority (i.e. Ludo (= Guix root), might
   delegate source code packaging for GnuPG to
   Werner (= GnuPG maintainer)); this creates questions of how
   to handle/specify/allow/prohibit transitive delegations
   (subpackages (KDE, Kedit), related packages (GnuPG/Enigmail)

Anyway, those are the main fun things that come to my mind, but I might
forget some ;-).

-Christian


On 03/04/2015 10:12 PM, Ludovic Courtès wrote:
> Hello GNUnetters!
> 
> Last year we submitted that project idea entitled “Supporting binary
> package distribution through GNUnet”:
> 
>   http://www.gnu.org/software/soc-projects/ideas-2014.html#guix
> 
> It’s GSoC time again, so I was pondering whether we should put it on
> display again.
> 
> I actually wonder if this is a good time: there hasn’t been a release in
> a while, and my (limited) understanding is that the relevant GNUnet
> components may not have fully settled yet (IIRC the “MESH” layer had
> landed just about the same time last year.)  If we were to propose this
> idea, we would need to make sure the rough design we have in mind, and
> the APIs that would be used, would still be valid and stable enough when
> the student starts working on it.
> 
> WDYT?
> 
> Thanks,
> Ludo’.
> 
> _______________________________________________
> GNUnet-developers mailing list
> GNUnet-developers@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnunet-developers
> 

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

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [GNUnet-developers] Guix + GNUnet at GSoC?
  2015-03-05 13:48 ` Christian Grothoff
@ 2015-03-05 22:33   ` Ludovic Courtès
  2015-03-09 16:48     ` Sree Harsha Totakura
  0 siblings, 1 reply; 5+ messages in thread
From: Ludovic Courtès @ 2015-03-05 22:33 UTC (permalink / raw)
  To: Christian Grothoff; +Cc: guix-devel, gnunet-developers

Hello Christian,

Christian Grothoff <grothoff@gnunet.org> skribis:

> Yes, I think we should. MESH (now CADET) is much further along and the
> API is stable.  I also don't see any other significant roadblocks.

OK.  I gather from a recent Mumble meeting report that a new release is
in the works, right?

> 1) Transfer of source code (with signatures / integrity checking /
>    build rules)
> 2) Transfer of binary packages (with signatures / integrity checking),
>    which also requires
>    - specification of platforms (what is binary-compatible)
>    - specification of platform-independent resources
>      ("noarch"/"all"/"data")

I should mention that the GNUnet-based mechanism would become a
“substituter” in Guix parlance–i.e., a back-end queried by the build
daemon to determine whether there are “substitutes” to build results
available out there.  (See
<https://www.gnu.org/software/guix/manual/guix.html#Substitutes>.)

So the way it works is that when the user types ‘guix build emacs’, the
daemon invokes the “substituter” asking whether it has a substitute for
/gnu/store/8hin…-emacs-24.4; the hash here is a hash of all the relevant
info, including the architecture, etc.  The GNUnet-based substituter
would typically go find a list of peers that provide it, and fetch it
from them.

It’ll be up to the substituter to authenticate what it downloads, but
Guix already has a PKI for that (also mentioned in the “Substitutes”
section above.)

> 3) Incremental updates
>    - to source (i.e. "diff")
>    - to binaries (funky binary-diff)

Definitely.  (Content-based addressing comes to mind.)

> 4) Notification about available updates to sources (to individual
>    packages or full distribution by distribution authority), or
>    signed messages asserting no updates are available (also important
>    to avoid adversary preventing upgrade)

Definitely important, but technically different (it would have to be
hooked up in ‘guix pull’ and not in the substituter mechanism.)  I would
not make it part of the GSoC.

> 5) Notification about available updates to binaries (including
>    signatures of binary package builders arriving at the same
>    (or different!?) deterministic build hash)

Binaries are immutable.  However, being able to know which peers arrive
at a given hash for a given /gnu/store item would be a nice bonus
indeed.

> 6) A trust graph / metric / WoT-like construction to determine
>    how many (and which) binary package builders are needed before
>    we trust third-party binaries (instead of building ourselves
>    from source)

Interesting, but beyond GSoC IMO.

> 7) Automatically offering packages the local system has build to
>    others (or not)

That would have to be done so we can at least test the system.  :-)

> 8) Delegation of build authority (i.e. Ludo (= Guix root), might
>    delegate source code packaging for GnuPG to
>    Werner (= GnuPG maintainer)); this creates questions of how
>    to handle/specify/allow/prohibit transitive delegations
>    (subpackages (KDE, Kedit), related packages (GnuPG/Enigmail)

Beyond GSoC IMO.

I think getting the basic functionality of the substituter in place as
well as a tool to public local binaries would be a great achievement.

Who would like to (co-)mentor it?

Thanks,
Ludo’.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [GNUnet-developers] Guix + GNUnet at GSoC?
  2015-03-05 22:33   ` [GNUnet-developers] " Ludovic Courtès
@ 2015-03-09 16:48     ` Sree Harsha Totakura
  2015-03-09 22:13       ` Ludovic Courtès
  0 siblings, 1 reply; 5+ messages in thread
From: Sree Harsha Totakura @ 2015-03-09 16:48 UTC (permalink / raw)
  To: Ludovic Courtès, Christian Grothoff
  Cc: guix-devel, gnunet-developers, Bart Polot

On 03/05/2015 11:33 PM, Ludovic Courtès wrote:
> Who would like to (co-)mentor it?

Hi!

I and Bart would like to co-mentor this project.

Should I write to summer-of-code@gnu.org for including this project in
the list of ideas?

Regards,
Sree

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Guix + GNUnet at GSoC?
  2015-03-09 16:48     ` Sree Harsha Totakura
@ 2015-03-09 22:13       ` Ludovic Courtès
  0 siblings, 0 replies; 5+ messages in thread
From: Ludovic Courtès @ 2015-03-09 22:13 UTC (permalink / raw)
  To: Sree Harsha Totakura; +Cc: guix-devel, gnunet-developers

Hello!

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

> I and Bart would like to co-mentor this project.

Excellent.  I’ve emailed an updated description with your names to José
and summer-of-code@gnu.org.

Thank you!

Ludo’.

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-03-09 22:13 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-04 21:12 Guix + GNUnet at GSoC? Ludovic Courtès
2015-03-05 13:48 ` Christian Grothoff
2015-03-05 22:33   ` [GNUnet-developers] " Ludovic Courtès
2015-03-09 16:48     ` Sree Harsha Totakura
2015-03-09 22:13       ` Ludovic Courtès

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).