Re: [tor-dev] regarding control spec for hidden service descriptor
> I am currently working on ticket 8510: > https://trac.torproject.org/projects/tor/ticket/8510 > > However, I notice that in the control spec, there is no event related to > hidden service descriptors. Should we add a new event in the spec? > > For example, we can have something like the following: > HS_DESC SP REQUESTED SP OnionAddress SP DescptorID SP AuthType SP HsDir SP > > Any thoughts? The above basics seem fine. The controller also needs to accept queries for onion descriptors, eg: getinfo n.onion [network] If the descriptor is not cached, or it is cached but it is just now checked at query time and found to be expired, set cache to NULL, then fetch and cache it. If the descriptor is cached and not expired, allow an optional 'network' flag to force a refetch from the network and cache it again, but do not update cache unless the refetch was successful. Now the current descriptor is cached or NULL, decode and print all the fields contained within it (all the v2 fields for example). I would suggest one line per field. 'getinfo ...' always prints an additional special return header field line: 'n.onion status ', where is 'fetchfail' or 'fetchok' or 'fromcache' depending on above modes/results. and also always prints the cached descriptor labels and data fields (if cache is NULL, just print empty date fields). ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] regarding control spec for hidden service descriptor
On 9/2/13, grarpamp wrote: >> https://trac.torproject.org/projects/tor/ticket/8510 > 'fetchfail' or 'fetchok' These two status need extended fields fetchfail fetchok ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] regarding control spec for hidden service descriptor
On 9/2/13, grarpamp wrote: >> https://trac.torproject.org/projects/tor/ticket/8510 > 'fetchfail' or 'fetchok' > These two status need extended fields > fetchfail > fetchok 'fromcache' also needs ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Searchable metrics archive - Onionoo-like API available online for probing
On Mon, Sep 2, 2013 at 2:20 PM, Karsten Loesing wrote:
> On 8/23/13 3:12 PM, Kostas Jakeliunas wrote:
> > [snip]
>
> Hi Kostas,
>
> I finally managed to test your service and take a look at the
> specification document.
Hey Karsten!
Awesome, thanks a bunch!
The few tests I tried ran pretty fast! I didn't hammer the service, so
> maybe there are still bottlenecks that I didn't find. But AFAICS, you
> did a great job there!
>
Thanks for doing some poking! There is probably space for quite a bit more
of parallelized benchmarking (not sure of term) to be done, but at least in
principle (and from what I've observed / benchmarked so far), if a single
query runs in good time, it's rather safe to assume that scaling to
multiple queries at the same time will not be a big problem. There's always
a limit of course, which I haven't yet observed (and which I should be able
to / would do well to find, ideally.) This is, however, one of the
strengths of PostgreSQL in any case: very nice parallel-query-scaling. Of
course, since the queries are, more or less, always disk i/o-bound, there
still could be hidden sneaky bottlenecks, that is very true for sure.
> Thanks for writing down the specification.
>
> So, would it be accurate to say that you're mostly not touching summary,
> status, bandwidth, and weights resources, but that you're adding a new
> fifth resource statuses?
>
> In other words, does the attached diagram visualize what you're going to
> add to Onionoo? Some explanations:
>
> - summary and details documents contain only the last known information
> about a relay or bridge, but those are on a pretty high detail level (at
> least for details documents). In contrast to the current Onionoo, your
> service returns summary and details documents for relays that didn't run
> in the last week, so basically since 2007. However, you're not going to
> provide summary or details for arbitrary points in time, right? (Which
> is okay, I'm just asking if I understood this correctly.)
>
(Nice diagram, useful-) responding to particular points / nuances:
summary and details documents contain only the last known information
> about a relay or bridge, but those are on a pretty high detail level (at
> least for details documents)
This is true: the summary/details documents (just like in Onionoo proper)
deal with the *last* known info about relays. That is how it works now,
anyway.
As per our subsequent IRC chat, we will now assume this is how it is
intended to be. The way I see it from the perspective of my original
project goals etc., the summary and details (+ bandwidth and weights)
documents are meant for Onionoo {near-, full-}compatibility; they must stay
Onionoo-like. The new network status document is the "olden archive browse
and info extract" part: it is one of the ways of exposing an interface to
the whole database (after all, we do store all the flags and nicknames and
IP addresses for *all* the network statuses.)
However, you're not going to
> provide summary or details for arbitrary points in time, right? (Which
> is okay, I'm just asking if I understood this correctly.)
There is no reason why this wouldn't be possible. (I experimented with new
search parameters, but haven't pushed them to master / changed the backend
instance that is currently running.)
A query involving date ranges could, for example, be something akin to,
"get a listing of details documents for relays which match this $nickname /
$address / $fingerprint, and which have run (been listed in consensuses
dated) from $startDate to $endDate." (would use new ?from=.., ?to=..
parameters, which you've mentioned / clarified earlier.)
As per our IRC chat, I will add these parameters / query options not only
to the network status document, but also to the summary and details
documents.
> - bandwidth and weights documents always contain information covering
> the whole lifetime of a relay or bridge, where recent events have higher
> detail level. Again, you're not going to change anything here besides
> providing these documents for relays and bridges that are offline for
> more than a week.
>
> - statuses have the same level of detail for any time in the past.
> These documents are new. They're designed for the relay search service
> and for a simplified version of ExoneraTor (which doesn't care about
> exit policies and doesn't provide original descriptor contents). There
> are no statuses documents for bridges, right?
>
Yes & yes. No documents for bridges, for now. I'm not sure of the priority
of the task of including bridges - it would sure be awesome to have bridges
as well. For now, I assume that everything else should be finished (the
protocol, the final scalable database schema/setup, etc.) before embarking
on this point.
The status entry API point is indeed about getting info from the whole
archives, at the same detail level for any portion of the archives.
(I should have articulated this / put into a design doc before,
Re: [tor-dev] #7167 (IRC meeting to discuss sponsor F progress)
On Fri, Aug 30, 2013 at 08:00:00AM +0200, Karsten Loesing wrote:
> If your name is on that list and you're working on sponsor F stuff, but
> the date or time doesn't work for you, please email me your progress and
> I'll report it for you at the meeting.
We have implementations of the client and server plugins for
obfs3|websocket.
Ximin wrote the client half. I think the client half is done except for
polishing and bugfixing (and facilitator integration, see below). It
doesn't need further protocol design work and will likely stay the same
even as we make changes in the server part.
https://trac.torproject.org/projects/tor/ticket/7167#comment:27
https://github.com/infinity0/obfs-flash/tree/master/mkii
I have been developing the server half. The tricky part of the server
was supporting the extended ORPort. I regard this implementation as more
than a prototype, but it still needs a lot of development.
https://trac.torproject.org/projects/tor/ticket/7167#comment:32
However, a major part that we overlooked earlier is that the flash proxy
facilitator needs to be modified to know about different transports and
hand appropriate transports to appropriate clients. (This should be
added to the milestones, because I don't see it mentioned on the wiki
page.) George has started making a design and writing code in #9349.
See also https://trac.torproject.org/projects/tor/ticket/7167#comment:17
("One thing we didn't think about...").
Currently our obfs3|websocket implementation works, as in Tor bootstraps
and passes traffic, but you have to start up a flash proxy manually
because the facilitator part is missing. We really need that part for a
serious deployment.
David Fifield
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [RELEASE] Torsocks 2.0.0-rc2
Greetings everyone! After a week or so, the release candidate 2 is now out after receiving various contributions for BSD and OS X support. A quick note. Please use the Github bug tracker for any issues and *not* trac.torproject.org. Until this code base is accepted as a potential replacement for the old version, please use the current repository issue tracker. Here is the ChangeLog: 2013-09-02 torsocks 2.0.0-rc2 * Fix: remove FAQ file from Makefile * Fix: remove out of date and inaccurate FAQ * Tests: add connection object unit test * Fix: Improve README file * Tests: add onion pool subsystem unit test * Use extern for tsocks_libc_* in torsocks.h * Define LIBC_SYSCALL_ for OS X * Make sure __darwin__ is defined * Fix: explicitly ignore fileno return value * Use AC_CHECK_FUNC rather than AC_LINK_IFELSE. * Find out if we really need libdl. * Define LIBC_SYSCALL_ for FreeBSD. * Use SYS_ from . * Include for AF_INET*. * Use getsockname(2) for finding out socket address family Please continue to test, review and contribute it! :) Tarball: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc2.tar.gz Big thanks to all contributors for that release! Cheers! David signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] regarding control spec for hidden service descriptor
___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] regarding control spec for hidden service descriptor
On 09/02/2013 05:01 AM, grarpamp wrote: > On 9/2/13, grarpamp wrote: >>> https://trac.torproject.org/projects/tor/ticket/8510 > >> 'fetchfail' or 'fetchok' > >> These two status need extended fields >> fetchfail >> fetchok > > 'fromcache' also needs > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > Thanks for your suggestion! Following is my summary for the stuffs we need to add, let me know if I missed anything :) # Asynchronous events for hs descriptors: HS_DESC SP REQUESTED SP OnionAddress SP DescptorID SP AuthType SP HsDir HS_DESC SP RECEIVED SP OnionAddress SP DescptorID SP AuthType SP HsDir HS_DESC SP PUBLISHED SP OnionAddress SP DescptorID SP AuthType SP HsDir # HS descriptor related extension to getinfo event: request: GETINFO desc/hs/n.onion [network] where network is an optional argument, if given, will force refetch of HS's descriptor. response: First line with one of following headers: n.onion fromcache n.onion fetchfail n.onion fetchok Then prints out cached descriptor labels and data fields, one line per field. If cache is NULL, print empty body. example: C: GETINFO desc/hs/n.onion S: 250+desc/hs/n.onion= S: n.onion fromcache S: [Descriptor for n.onion] S: . S: 250 OK Another question: How can I submit a patch to torspec repo? Create a ticket and attach my patch? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
