Re: [tor-dev] Default bridges that are not publishing statistics

[Damian Johnson <atagar@xxxxxxxxxxxxxx>]

> You asked your bridge for its server descriptor and it gave it to you.
>
> Did you try:
>              print controller.get_extrainfo_descriptors("8B5F0BD647B3C4AF2C57F148FF6A1FB8B695B0AE")
>
> https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remote.DescriptorDownloader.get_extrainfo_descriptors

Hi teor, minor correction: you link to the DescriptorDownloader's method
but cite it as being part of Controller. This is why David didn't find it
later. The Controller can fetch some descriptor types. For instance...

https://stem.torproject.org/api/control.html#stem.control.Controller.get_server_descriptor
https://stem.torproject.org/tutorials/mirror_mirror_on_the_wall.html#can-i-get-descriptors-from-the-tor-process

However, the Controller doesn't provide extrainfo descriptors. This is
for a couple reasons...

1. The control protocol only allows it to be retrieved by the descriptor
   digest rather than relay fingerprint, which is a pita...

   https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n562

2. This isn't what you want anyway. Fetching decriptors from the tor
   process only gets you the cached descriptors which isn't what folks
   generally want. So you're right that the DescriptorDownloader is
   the way to go.

> I don't know how to find a server that caches *all* bridge extra infos.
> Maybe you should try running these queries against the bridge authority?

Bridge descriptors are not public like normal descriptors. To work of
course the tor client can retrieve it if you know the bridge address
but beyond that I think the only thing available is the sanitized
descriptors from CollecTor...

https://collector.torproject.org/recent/bridge-descriptors/

> I think the documentation at:
> https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remote.Query
> is out of date: as far as I know, newer stem versions try fallback
> directories rather than authorities.

Unfortunately it doesn't. I had to revert that because they lack
extrainfo docs...

https://gitweb.torproject.org/stem.git/commit/?id=758f632

> Thanks again for your suggestions. Passing endpoints= doesn't seem to do
> anything.
>         >>> import stem.descriptor.remote
>         >>> BIFROEST = ("37.218.247.217", 80)
>         >>> print list(stem.descriptor.remote.get_server_descriptors("C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4", endpoints=(BIFROEST,)))
>         []

For what it's worth stem has authority information so this can also be
done with...

>>> import stem.descriptor.remote
>>> bifroest = stem.descriptor.remote.get_authorities()['Bifroest']
>>> print list(stem.descriptor.remote.get_server_descriptors("C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4", endpoints=((bifroest.address, bifroest.dir_port),)))

> It also doesn't work when trying the fingerprint of another default
> bridge, or of one I just got from bridge.torproject.org.

Alas, this is getting into areas I'm not too familiar with. To prevent
enumaration
I'm sure bridges are handled specially.

> Atagar might be able to help with the stem side of things.

Happy to help if there's any other stem questions.

Cheers! -Damian
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev