Re: [GNUnet-developers] Using GNUnet for binary package distribution

[Sree Harsha Totakura]

On 03/21/2013 07:01 PM, Christian Grothoff wrote:
> On 03/21/2013 02:02 PM, Ludovic Courtès wrote:
>> Hello GNUnet!
>>
>> GNU Guix provides a transparent binary/source deployment model.  A
>> server can claim: “hey, I have the binary for
>> /nix/store/v9zic07iar8w90zcy398r745w78a7lqs-emacs-24.2!”, where the
>> base32 string uniquely identifies a build process.  If you trust that
>> server to provide genuine binaries, then you can grab them instead of
>> building Emacs locally.
>>
>> The “traditional model” has been to have a build farm build and serve
>> binary packages.  In that model, users trust the build farm to provide
>> authentic binaries.
>>
>> I’m interested in providing a /practical/ decentralized distribution
>> model.  It seems to me that GNUnet’s DHT would be the most appropriate
>> (as opposed to AFS).  WDYT?
>>
>> One of the problems to be solved is authentication: users would have to
>> specify a list of GNUnet pseudonyms of trusted binary providers, or
>> something like that.  Managing this list would have to be as easy as
>> possible, to allow the system to scale.
>>
>> Another issue is privacy: we want to give users an incentive to share
>> their binaries, but at the same time, they should have control over what
>> gets shared (for instance, Christian may want to hide the fact that he’s
>> installed Python and not Guile ;-)).
>>
>> What do you think of the idea?  Would the DHT retain files long enough
>> for this to be practical?
> 
> Well, the GNUnet DHT expects that the data source periodically refreshes
> the values by re-issuing the PUT; without that, it cannot work.
> Furthermore, you need to consider that DHTs are typically only useful
> for small data pieces (think <= 64k), not for large files.  So what
> you'd store in the DHT is the meta data (where to find the large files),
> not the actual files.
> 
> gnunet-update (svn/gnunet-update/) is a little project where we started
> to work on a GNUnet installer that is supposed to include an update
> mechanism that downloads updates via GNUnet --- after all, if you are
> using a recent version of GNUnet, sharing your installation binaries
> costs you at least no disk space at all, and if censorship kicks in,
> having a way to update in a decentralized fashion might become important.
> 
> So gnunet-update is planned to provide the means to locate files based
> on some package description (signatures, meta data) and download them
> via the P2P network.  Fundamentally, there is nothing wrong with using
> the basic ideas to distribute packages other than GNUnet itself.
> 
> Our current approach to package management is essentially to look at ldd
> and grab all dependencies (unless compatible versions are already
> available on the target system, based on libtool versioning info); the
> idea was to make it work with 'any' distribution as long as the
> architecture matches.  Naturally, that doesn't mean that in principle a
> different package manager could not be used/supported.
> 
> gnunet-update is not yet finished, we're currently planning to revise
> some internal part that gnunet-update will depend on (stream); still,
> help in moving this area along would be of course welcome.

For authentication, we intend to use GPG with gnunet-update.  The idea
is that the gnunet-updater would search for updates using GNUnet's File
Sharing service and downloads meta-data files.  It then verifies if the
meta-data files are signed by a trusted key (which is user-configurable)
and proceeds with the download of actual binaries.

Using this approach the meta-data files and the binaries pointed in
meta-data can be published by anyone and still be verified.  This could
improve the availability of both meta-data and the binaries.

--
Harsha