Page MenuHome GnuPG
Create Task
Maniphest T3392

keyserver default should include pool onionbalance hkp://jirk5u4osbsr34t5.onion
Open, WishlistPublic
Actions

Description

the SKS pool documentation points out an onionbalance load balancer that can distribute requests over all the known tor onion services.

There are actually more keyservers that offer onion services than there are that offer hkps, afaict.

If dirmngr's default were to include hkp://jirk5u4osbsr34t5.onion as well as hkps://hkps.pool.sks-keyservers.net then the tor auto-detection (or an explicit use-tor) could make use of the onionbalance. This would spread the load more evenly among the existing keyservers.

Event Timeline

dkg created this task.Sep 7 2017, 4:49 PM
• werner triaged this task as Normal priority.Sep 8 2017, 8:17 AM
• werner edited projects, added Feature Request; removed Bug Report.
• werner added subscribers: kristianf, • werner.

Do you mean this?

if no keyserver configured
  if tor_usable
     use jirk.....onion
  else
     use hpks.pool.....
else
    ...

@kristianf is the onion support for keyservers out of the testing phase?

I change that to feature request. Whether it can be backported to 2.2 is different question and should not only be decided upon the bug/feature tag.

kristianf added a comment.Sep 21 2017, 4:27 PM

I'm not entirely sure whether it is due to low usage or little problems with the service, but it seems to work pretty OK. My primary concern is that as opposed to DNS based system, the onionbalance system requires my node to be running and available and as such constitutes a SPOF. Although I've cleaned up my scripts sufficiently, e.g network outage will make this service unavailable whereby the hkps pool will continue to function.

dkg added a comment.Sep 22 2017, 7:35 PM

I spoke with the author of onionbalance, and they said:

normally the single onionbalance daemon is the SPOF. One solution for this is to run multiple onionbalance daemons with the same configuration on different machines.

Each onionbalance daemon will publish it's own master descriptor and these descriptors will replace each other on the HSDirs. If either daemon stops, then the other daemon will keep publishing an updated master descriptor.

So if the SPOF is the only thing @kristianf has a concern, he could:

  • run a second instance of onionbalance, on distinct infrastructure
  • share the config information (and, presumably the coresponding secret key) with another party, so that they can run the second instance.

I note that back when we were shipping "skeleton" options files, the default dirmngr.conf actually did include the onionbalance address as well, so some people may already have inherited that configuration. However, i think that was before dirmngr tried to opportunistically connect to tor, so presence of that configuration would have been masked except for those folks who manually set use-tor.

kristianf added a comment.Sep 22 2017, 7:45 PM

Thanks, that is interesting info, I need to look into that.

• werner added a project: Keyserver.Sep 24 2017, 10:03 AM
matheusmoreira added a subscriber: matheusmoreira.May 9 2019, 9:05 PM
• werner lowered the priority of this task from Normal to Wishlist.Nov 27 2020, 5:39 PM
thesamesam added a subscriber: thesamesam.Sep 1 2023, 5:33 AM