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 > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
