gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] GNS changes


From: ng0
Subject: Re: [GNUnet-developers] GNS changes
Date: Thu, 23 Feb 2017 10:29:28 +0000

On 17-02-22 21:39:15, Christian Grothoff wrote:
> This is mostly for Lynx and Martin, but might be of interest to the rest...
> 
> I want to briefly explain what I've done with 9bc1c69e2..cd9531932 ...
> 
> 
> The above change *removes* support for reverse lookups and shortening
> from the GNU Name System. Entirely. Gone from the API....
> 
> But *not* gone from what we'd like to have!  Basically, with #4849 I'm
> fixing three things:
> 
> 1) GNS service must run as user 'gnunet', as it needs to access the
> 'dns' service, which is UID-restricted in the strict security model; at
> the same time, GNS service with shortening OR reverse lookup needs to
> run as $USER as it needs access to namestore (which is per-user). Eh,
> great, how am I supposed to setup my permissions again?  So by NOT
> having those two functions in GNS, I fix this BIG problem.  (Note that
> moving the 'publish GNS zone to DHT' into 'zonemaster' earlier, I
> removed the remaining namestore dependency of GNS.)

Does this mean that the previous requirement of a unix group "gnunetdns"
is gone as well?
 
> 2) Shortening was always a UX nightmare, as we ultimately would want the
> user to approve the shortening explicitly. By not having GNS do this,
> some UX can do it explicitly itself (by putting records into namestore
> based on NICKs it encounters), thereby addressing the UX issue.
> 
> 3) Reverse lookups don't really use the GNS protocol (no DHT!), and you
> both have discussed various "better" ways to reverse names.  If an app
> needs what GNS did provide, it can just go into NAMESTORE directly and
> grab the value there.  And by NOT having the reversal API conflated with
> GNS, we _also_ make it easier for both of you to develop fun new name
> reversal protocols/subsystems to your heart's content.
> 
> 
> Not to mention the GNS logic is complicated enough, no need to bamboozle
> GNS code reviewers with shortening and reversal which are really
> orthogonal issues to the simple task for forward name resolution. We
> don't need to recreate the DNS kitchen-sink.
> 
> 




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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]