[pkg-gnupg-maint] Bug#863221: Bug#863221: Bug#863221: dirmngr doesn't reload resolv.conf

[Daniel Kahn Gillmor]

On Wed 2017-05-24 16:14:22 +0200, Stefan Bühler wrote:
> On 05/24/2017 02:14 PM, Werner Koch wrote:
>> Hi!
>> 
>> When you switch the laptop connection you should flush dirmngr anyway
>> and thus I do not consider the need to do this just for the resolver.
>> 
>>  gpgconf --reload dirmngr
>> 
>> in the ifup script should do that job.  Note that gpgconf won't start a
>> component on --reload or --kill if it is not yet started.
>
> 1) How would I install an if-up.d hook without being root?
> 2) The dirmngr package should work out of the box, i.e. install the
>    required hooks.
> 3) There are many network managers.  I'd consider hooking only ifupdown
>    not sufficient.
> 4) Calling "gpgconf --reload dirmngr" as root doesn't reload my user
>    dirmngr.
> 5) I see no documentation regarding the need for such hook.  The debian
>    manpage only says (regarding SIGHUP):
>
>>> This  signal  flushes  all internally cached CRLs as well as any
>>> cached certificates.  Then the certificate cache is reinitialized as
>>> on startup.  Options are re-read  from  the  configuration  file.
>
>    I don't see why it would be necessary to reload CRLs and
>    certificates on network connection changes from this comment.
>
>
> Also I think this way (adding a hook in a global configuration to reload
> user space components) is a very bad design.
>
> How about simply reloading everything when /etc/resolv.conf or friends
> were touched?  This also won't cover every scenario (e.g. running a
> local resolver and never changing resolv.conf), but it'd be a start.
>
> You could also try to monitor netlink messages for new default routes to
> detect network changes, but this is obviously more platform specific
> than stat()ing resolv.conf.


If resolv.conf is the main concern, it seems like we could place an
inotify watch on resolv.conf as well, to learn when it is updated. (at
least for platforms which support inotify)

Without inotify, doing a stat() on resolv.conf seems like an entirely
reasonable thing to do if we're concerned about the DNS resolver having
changed.  Is there a specific objection to doing a stat() on resolv.conf
when a dns lookup is about to be made? I'm inclined to open a ticket
upstream recording this as a request for enhancement.

i think from a privacy perspective, we'd generally not want to trigger a
full dirmngr flush on every network change -- in particular, that would
mean that every time we join the network, we would be more likely to
announce to the network about the various CRLs and keyservers that we're
interested in.  it doesn't take too many specific and non-universal URLs
to produce an highly-distinguishable network fingerprint.

   --dkg