Re: [tor-dev] Proposal 274: A Name System API for Tor Onion Services

David Fifield: > So here, the browser thinks it is connecting to debian.zkey (the URL bar > says "debian.zkey"). But Tor is really connecting to sejnfjrq6szgca7v.onion > in the background. What name does the browser put in its Host header? It > can't be the onion name, because there's no feedback f

Re: [tor-dev] Proposal 274: A Name System API for Tor Onion Services

Hi George, Here are my comments: 2.3.1 > If there are multiple name plugins that correspond to the requested > address, Tor queries all relevant plugins sorted by their priority > value, until one of them returns a successful result. It's unclear whether the sort operation referred to here is a

Re: [tor-dev] Proposal 274: A Name System API for Tor Onion Services

George Kadianakis writes: I have skimmed over this proposal, and it all sounds plausible. This: >In the beginning, name plugins should be third-party applications that can >be installed by interested users manually or through package managers. > Users >will also have to add the appr

Re: [tor-dev] Proposal 274: A Name System API for Tor Onion Services

On Fri, Oct 07, 2016 at 04:06:51PM -0400, George Kadianakis wrote: >In particular, onion addresses are currently composed of 16 random base32 >characters, and they look like this: > > 3g2upl4pq6kufc4m.onion > vwakviie2ienjx7t.onion >

Re: [tor-dev] Proposal 274: A Name System API for Tor Onion Services

Hi George, A nice proposal! A question that occurs to me is how the name plugin will interact with the network. Presumably it will make requests over Tor, either periodically to update its local database, or just-in-time, whenever a RESOLVE request is made. If name resolution requires a just-in-t

[tor-dev] Proposal 274: A Name System API for Tor Onion Services

Hello list, we've been busy discussing secure name systems for the past few months, and how we could integrate them with Tor. We had a few people ask us for precise interfaces, so here is an attempt for a modular name system API. It's largely based on the PT API, which has been pretty successful.

[tor-dev] 0.2.9 freeze dates, and fun bugs to work on, and important code to review

Hello, all! Here is an incomplete list of takeaways from network-team meeting last week, plus some more scheduling things, and other fun stuff for new (and experienced) Tor developers! * 0.2.9 is now frozen for big/risky changes. I'll put out the final alpha around 14 or 17 Oct, and fork 0.3.0

Re: [tor-dev] Proposal 273: Exit relay pinning for web services

On Wed, Oct 5, 2016 at 4:09 PM, Philipp Winter wrote: > The proposal is in draft state. We have several open questions that we > are still wrestling with in Section 2.6. Any feedback is greatly > appreciated. You can track the evolution of our proposal online: >

[tor-dev] CollecTor Release 1.0.2

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi there! CollecTor continues with a smaller release: https://dist.torproject.org/collector/1.0.2/ This release makes features available that have been running on the main CollecTor [4] instance for a while now. The three most significant c