Re: [GNUnet-developers] GNS changes

[Daniel Golle]

Hi Christian,

reviewing your changes I noticed that in

commit c3e03e28f3 use of dns2gns proxy instead of DNS interceptor in VPN test

you modified gnunet-gns-import.sh in a way which will render the
gns-intercept service unusable, see below

diff --git a/contrib/gnunet-gns-import.sh b/contrib/gnunet-gns-import.sh
index 8c9d1b9d4c..8614821fe3 100755
--- a/contrib/gnunet-gns-import.sh
+++ b/contrib/gnunet-gns-import.sh
@@ -63,7 +63,7 @@ gnunet-identity -e master-zone -s gns-proxy $options
 
 # Use master-zone for intercepted DNS queries
 # (remove this entry to disable DNS interception by GNS service)
-gnunet-identity -e master-zone -s gns-intercept $options
+gnunet-identity -e master-zone -s dns2gns $options
 
 # 'gns-private' is not yet used (!)
 gnunet-identity -e private-zone -s gns-private $options

So to fix this, there are obvious two possibilities:
a) add back the gns-intercept default ego in addition to dns2gns
b) let both, dns2gns and gns-intercept use the same default ego

Which way should we choose?


Cheers


Daniel


On Wed, Feb 22, 2017 at 09:39:15PM +0100, 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.)
> 
> 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