-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I'm gruntled to announce txtorcon 24.8.0 with the following changes:
* Fix (test) issues with Twisted 24.7.0
(https://github.com/meejah/txtorcon/pull/400)
* Remove usage of "six" (https://github.com/meejah/txtorcon/issues/395
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I'm energized to announce txtorcon 23.11.0 with the following changes:
* Fix test-failures on Python 3.12
* Particular GETINFO hanging (https://github.com/meejah/txtorcon/issues/389)
(ultra-long lines over 16KiB caused problems in the pro
pypi.python.org/pypi/txtorcon/23.5.0
https://github.com/meejah/txtorcon/releases/tag/v23.5.0
Releases are also available from the hidden service:
http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtorcon-23.5.0.tar.gz
http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesl
inter-operate with asyncio or even with threaded code if
you want. However, it's not going to be a drop-in Stem replacement (and that
has never been txtorcon's goal).
https://github.com/meejah/txtorcon/
Documentation available via onion (which self-hosts on the Twisted webserver
with t
l txtorcon"):
https://pypi.python.org/pypi/txtorcon/22.0.0
https://github.com/meejah/txtorcon/releases/tag/v22.0.0
Releases are also available from the hidden service:
http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtorcon-22.0.0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I'm pleased to announce txtorcon 21.1.0. This fixes some incorrectly-skipped
tests in 21.0.0
* Fix some incorrect unit-test skipping logic (thanks Jean-Paul Calderone)
https://github.com/meejah/txtorcon/issues/354 and
https://github.com/m
lack" in
the Python community (I personally haven't used it).
For linting it's flake8 (and also pylint or pyflakes). They all seem to
come down to "how many warnings do you want to turn off". I have
most-often used flake8 which is a fine choice.
Find me as "meejah&q
I also found it confusing and hard
to read Python :)
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I'm pleased to announce txtorcon 20.0.0. This fixes a few bugs and
officially deprecates Python 2 support.
* Use real GeoIP database or nothing
(https://github.com/meejah/txtorcon/issues/250)
* Change abstract base classes import in preper
r-side control-port code that's "overwhelmed", or
is the controller-side not reading fast enough or something..? (It seems
odd to me that it's somehow faster/better to inband-signal via HTTP..)
What controller is being used?
--
meejah
_
decorators too.
See e.g. TorState.on_circuit_new()
* fixes to the CI setup to properly test Twisted versions
You can download the release from PyPI or GitHub (or of
course "pip install txtorcon"):
https://pypi.python.org/pypi/txtorcon/19.1.0
https://github.com/meejah/txtorcon/
"use SOCKS5") has
basically no choice but to launch its own instance of tor. Maybe this is
the best thing to do anyway?
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
r = await txtorcon.connect(...)
async with tor.onion_authentication("http://timaq4ygg2iegci7.onion/";,
"token-blob"):
agent = tor.web_agent()
resp = await agent.request(b'GET', "http://timaq4ygg2iegci7.onion/";)
body = await readB
Piyush Kumar Sharma writes:
> The application is doing a voice call using mumble.
Usually that error means the server couldn't be reached from the exit, I
believe. That could be for many reasons. Did it ever succeed? How many
exits did it try?
--
Piyush Kumar Sharma writes:
> Are there any possible reasons as to why this might be happening and
> any possible fixes for this situation?
What is your application doing?
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
en "carml stream --attach " to attach
streams.
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Both Stem and txtorcon
should work fine doing their own circuit building + stream attachment.
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
rcuit
You can download the release from PyPI or GitHub (or of
course "pip install txtorcon"):
https://pypi.python.org/pypi/txtorcon/19.0.0
https://github.com/meejah/txtorcon/releases/tag/v19.0.0
Releases are also available from the hidden service:
http://timaq4ygg2iegci7.onion/
ourse "pip install txtorcon"):
https://pypi.python.org/pypi/txtorcon/18.3.0
https://github.com/meejah/txtorcon/releases/tag/v18.3.0
Releases are also available from the hidden service:
http://timaq4ygg2iegci7.onion/txtorcon-18.3.0.tar.gz
http://timaq4ygg2iegci7.onion/txtorcon-18.3.
` via `single_hop=` kwarg
You can download the release from PyPI or GitHub (or of
course "pip install txtorcon"):
https://pypi.python.org/pypi/txtorcon/18.2.0
https://github.com/meejah/txtorcon/releases/tag/v18.2.0
Releases are also available from the hidden service:
http://timaq4y
s exchanged are only usable once)...
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
fying the remote vs local
connections.
You can download the release from PyPI or GitHub (or of
course "pip install txtorcon"):
https://pypi.python.org/pypi/txtorcon/18.1.0
https://github.com/meejah/txtorcon/releases/tag/v18.1.0
Releases are also available from the hidden service
lling to implement it in tor?
This would be a feature for scanners, not little-t-tor itself, right?
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Iain Learmonth writes:
> I will look again once this is resolved.
I believe 18.0.2 fixes this (also reported by Brian Warner for
magic-wormhole). Sorry about that!
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
ht
ot;):
https://pypi.python.org/pypi/txtorcon/18.0.2
https://github.com/meejah/txtorcon/releases/tag/v18.0.2
Releases are also available from the hidden service:
http://timaq4ygg2iegci7.onion/txtorcon-18.0.2.tar.gz
http://timaq4ygg2iegci7.onion/txtorcon-18.0.2.tar.gz.asc
Or via a "version 3
b release is updated.
thanks,
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
con/18.0.1
https://github.com/meejah/txtorcon/releases/tag/v18.0.1
Releases are also available from the hidden service:
http://timaq4ygg2iegci7.onion/txtorcon-18.0.1.tar.gz
http://timaq4ygg2iegci7.onion/txtorcon-18.0.1.tar.gz.asc
Or via a "version 3"
pport listening on Unix paths.
* make sure README renders on Warehouse/PyPI
You can download the release from PyPI or GitHub (or of course "pip
install txtorcon"):
https://pypi.python.org/pypi/txtorcon/18.0.0
https://github.com/meejah/txtorcon/releases/tag/v18.0.0
R
to remember NOT copy-paste the whole config when asking for
help... sounds like lots to go wrong :) and I don't think this can be
solved by tinkering with the names/layout of torrc options,
personally...
--
meejah
___
tor-dev mailing list
tor-dev@
/ threaded implementations but also async
(event-based) implementations (for example, someone could then
leverage the bulk of your work to make an asyncio binding without
having to re-write all the parsing and state-machine code)
- it's the new hotness
I'm usually idling in
ot;bad things" to happen which aren't a problem of "the
Tor network" necessarily.
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
I currently do not have
> an answer.
Would it be better, then, to pick one first hop and scan (sequentially)
every second-hop using that first hop? (And maybe have say 5 or 10 such
things going on at once?)
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
light at
any one time and am using random guards so it's "very unlikely" I'd even
have two connections to the same first hop at the same time. However, I
don't do anything about timing -- maybe we can take up this discussion
in an IRC channel?
--
meejah
__
ers always deleted following NEWCONSENSUS
* Issue 279: remember proxy endpoint if it was Deferred
You can download the release from PyPI or GitHub (or of course "pip
install txtorcon"):
https://pypi.python.org/pypi/txtorcon/0.20.0
https://github.com/meejah/txtorcon/releases/tag/v
Damian Johnson writes:
> Thanks meejah! Took a peek but they both look pretty old and it's
> unclear to me how complete either got. If there's something in
> particular you think is worthwhile integrating I'm all ears.
I haven't looked closely enough to know t
ese libraries: https://python-hyper.org
It would be really cool to have a Python implementation of the Tor
protocol -- and double-extra-useful if it's a "pure" protocol library
without any messy I/O constructs involved :)
Cheers,
meejah
Yawning Angel writes:
> It's worth keeping in mind that no one to my knowledge has implemented
> prop 279 in the tor code itself, though there is (IIRC) a python kludge
> that kind of allows development.
Said kludge is here, for completeness:
https://github.com/meeja
IRC channel on the OFTC network,
for "possibly real-time answers". (More information on how to connect to
that is at https://www.oftc.net/)
Feel free to ping me in that channel for specific Python help
--
meejah
___
tor-dev mailing list
Harshavardhan Reddy writes:
> How does the Tor Project deal with the malicious exit relays. Do you
> still run exitmap or something better?
If you have any ideas for 'things to scan for' that are not reflected in
exitmap already I'd love to h
a) which seems to be The Right Thing.
+1
I think the next step for a) isn't "implement it", but "write a spec for
it" instead.
> Ideally we would probably apply for some sort of grant on this work so
> that some actual developer time is allocated. I think this
d be two different things rather than
overloading "one" state to become two and have all users have to parse
colons. e.g. "status/hibernation" and "status/hibernation-reason" or
similar.
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
binary) to facilitate
copying them (if, e.g. you're upgrading from an on-disk v3 service to an
ADD_ONION v3 service)
cheers,
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Damian Johnson writes:
>> What do you propose exactly?
>
> Hi David. What I mean is that having an optional positional field...
I think the missing fact here is that there is *already* the
DescriptorID field and it's already optional (in the current
control-s
27;re just extending it
to accept possibly more characters?
So, yes, just making it "possibly bigger" is fine IMO. In other words,
we've already baked into the spec the thing Damian doesn't want (an
optional positional arg) so there's not really any way out of th
even a new one for this case (and future cases) of "recognized,
but not yet supported". "560 Not yet implemented" or similar?
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
an's comments on the positional-arg; making it [SP
"DescriptorID=" ] or similar (i.e. an optional kwarg) would mean easier
later extending and also it *should* then "just work" with most
controller libs already at least as far as parsing goes (because
controller libs in general have to accept new, unknown kwargs).
The rest all sounds good to me!
thanks,
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
odes as well) which supports
Python3 as well as of course Python2 and PyPy.
So, you can do async DNS (at least A and PTR lookups) via tor + txtorcon
nicely:
https://github.com/meejah/txtorcon/blob/master/examples/dns_lookups.py
--
meejah
___
tor-dev
e tor instance).
For example, "use any Tor circuit and make a Web request":
https://github.com/meejah/txtorcon/blob/master/examples/web_client_treq.py#L23
vs. "build a custom circuit and make a request over that":
https://github.
Jude Nelson writes:
> We plan to add support to the stdin/stdout protocol in Prop279 as
> well.
Neat!
In case you missed it, you could test this implementation with
https://github.com/meejah/torns -- which functions similarly to the Stem
/ OnionNS thing but speaks to the actual plugins
calls (to help
filtering-proxies).
You can download the release from PyPI or GitHub (or of
course "pip install txtorcon"):
https://pypi.python.org/pypi/txtorcon/0.19.3
https://github.com/meejah/txtorcon/releases/tag/v0.19.3
Releases are also available from the hidden servic
wnload the release from PyPI or GitHub (or of course "pip
install txtorcon"):
https://pypi.python.org/pypi/txtorcon/0.19.2
https://github.com/meejah/txtorcon/releases/tag/v0.19.2
Releases are also available from the hidden service:
http://timaq4ygg2iegci7.onion/txtorcon-0.19.2.tar.gz
htt
19.1
https://github.com/meejah/txtorcon/releases/tag/v0.19.1
Releases are also available from the hidden service:
http://timaq4ygg2iegci7.onion/txtorcon-0.19.1.tar.gz
http://timaq4ygg2iegci7.onion/txtorcon-0.19.1.tar.gz.asc
You can verify the sha256sum of both by running the following 4 lines
in a shell wh
SSEC support, although a quick grep does indicate some
"dnssec"-related attributes. See:
https://twistedmatrix.com/trac/wiki/TwistedNames
https://twistedmatrix.com/documents/current/names/
--
meejah
___
tor-dev mailing list
ver
stdin/stdout it can immediately be tested and used with this PoC:
https://github.com/meejah/torns
This should already work fine out-of-the-box with Tor Browser Bundle
(and of course a system Tor) as it sets (and re-sets) the appropriate
options (i.e. setting __LeaseStreamsUnattached back
of the documentation, including the new
Programming Guide:
https://txtorcon.readthedocs.io/en/latest/guide.html
* Issue 203: https://github.com/meejah/txtorcon/issues/203
* new helper: txtorcon.Router.get_onionoo_details which downloads
JSON for a particular relay from OnionOO
* new helper: t
;s easier to tell
"how new" a release is; and big version numbers are cool (just kidding).
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
iblity. The
names for the new things use "onion" (e.g. .create_onion_service)
Basically the idea is similar to (inspired by?) what Twisted itself
provides: if your code doesn't currently cause txtorcon to emit
warnings, then you can upgrade. Currently there are no
Existing code will continue to work for the forseeable future.
thanks,
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
robably be best if there was "a" robust
control-port filter that shipped as part of a Tor release. So if that
means "must implement it in C inside Tor" I guess so be it.
Maybe this would be a good target for "experiment with Rust" if anyone's
excited about writing control-port code in Rust...?
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
would need a little more fleshing out,
but should be sufficient to proceed with prototype implementations of
prop-279 clients.
https://github.com/meejah/TorNS
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.o
l-port of
Tor (and is thus "completely trusted") but then exposes "the Next Great
Control Protocol" to clients.
Nevertheless, there's still the question of what information to expose
(and how) -- i.e. the threat model, and use-cases.
Of
Although I don't have a concrete suggestion for the UI, I think this is
a good idea.
Similarly, it would be good to give people a clear way to tell us what
exit node they were using at the time (by fingerprint).
Maybe this could look like a "report possibly bad exit node behavior"
option in the
As per https://github.com/meejah/txtorcon/issues/203 all released
versions of txtorcon that have TorState.all_routers will, upon a
NEWCONSENSUS event, make this set empty. There is already a fix on
master for the real issue and it will be in the next release.
For users of released versions
doesn't do processing on it, per se.
Might be worth noting here that it's not always "a" hostname: if you
have an authenticated hidden-service, it is multiple lines. In "basic"
auth case, each line starts with the same .onion address -- in
isis agora lovecruft writes:
> meejah transcribed 1.0K bytes:
>> Feedback requested if this will negatively affect you!
> For whatever it's worth, all of Tor's infrastructure runs on Debian
> stable, and I'm not sure if weasel would make exceptions to enable
>
14 is for jessie ("stable"). jessie-backports has
16.2.0 and stretch has 16.6.0
Hence I do not believe upgrading this dependency will be a problem for
Debian packaging. I do not know the implications for other
distributions.
Feedback requested if this will negatively affect you!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
txtorcon 0.18.0 is released, improving error-reporting when you have
SAFECOOKIE or COOKIE authentication turned on but can't read the file.
* https://github.com/meejah/txtorcon/issues/200
You can download the release from PyPI or GitHub (
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ot; options go
away! These are already familiar to most service operators, presumably,
and your approach sounds great! It's also really easy to support from a
controller perspective. Also, the backwards-compatibility is very nice
too.
--
meejah
ll.
> We should probably speak with people that use client auth to tell us
> if this UX will break their model.
+1
It would be great to know how people actually exchange these things
currently :)
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
service-stuff -- so "just edit the config" isn't a
satisfying answer at all. Also, having every app launch its own Tor
instance (which is about the only answer currently) seems bad.
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
l still work).
In any case, I like it :)
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
ty API for `socks_hostname` was incorrectly named
You can download the release from PyPI or GitHub (or of
course "pip install txtorcon"):
https://pypi.python.org/pypi/txtorcon/0.17.0
https://github.com/meejah/txtorcon/releases/tag/v0.17.0
Releases are also available from the hidd
ces -- it's also the good API for applications that want to manage
their own private-key material. For these, they might like to know when
*all* descriptors are uploaded, etc.
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
o need to distinguish all 6 flavours (permanent vs ephemeral,
authenticated or not, stealth-auth or not). There's almost nothing
completely common -- e.g. stealth-auth'd services have N onion-address,
so there's not even "an" address.
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Why are you using the on-disk API if
you don't want to give your thing permission to read those directories?
I also don't see why you'd give something permission to use the
control-port, but *not* permission to read hostname/private_key
files...?
(p.s. I can&#x
ddress
that I know of is by reading the "hostname" file.
Can you describe what you're trying to do?
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
s for TorClientEndpoint
(thanks to "dawuud"). Also adds TLS support over SOCKS5.
You can download the release from PyPI or GitHub (or of
course "pip install txtorcon"):
https://pypi.python.org/pypi/txtorcon/0.16.1
https://github.com/meejah/txtorcon/releases/tag/v0.16.1
Releases ar
ave it running on a different
machine).
Probably there's some Debian policy guidance around this that I don't
know about :)
Thansk again for the packaging work!
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
t;pip install txtorcon"):
https://pypi.python.org/pypi/txtorcon/0.15.1
https://github.com/meejah/txtorcon/releases/tag/v0.15.1
Releases are also available from the hidden service:
http://timaq4ygg2iegci7.onion/txtorcon-0.15.1.tar.gz
http://timaq4ygg2iegci7.onion/txtorcon-0.15.1.
.g. because the file isn't readable).
* both TorState and TorConfig now have a ``.from_protocol``
class-method.
* spec-compliant string-un-escaping from https://github.com/coffeemakr
* fix https://github.com/meejah/txtorcon/issues/176
You can download the release from PyPI or GitHu
d if they're the same, but the
"onion:" prefix I think fits with the push to call these things Onion
Services (instead of "hidden services") too...
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
d
TBB, plot relays on xplanet, etc.
https://carml.readthedocs.org
maintainer: meejah
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
.g., Docker Notary is such an implementation (in Go) as
I understand it.
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Mridul Malpotra writes:
> As suggested in the proposal, using Selenium seems like the right
> choice. I have read about the RC and WebDriver and have decided to go
> forward with the latter [..]
+1 on this choice, WebDriver is the newer (and better) API.
-
I'm also planning to get rid of GeoIP support entirely -- it needs
binary packages, a (usually manually downloaded) database and it would
be cleaner and nicer to just use 'GETINFO ip-to-country/*' 100% of the
time (instead of just as a fallback). On top of that, it seems that the
Python packges do
oint)"
method on Circuit instances that gives you a Twisted
IStreamClientEndpoint implementation causing the stream resulting
from .connect() to be attached to that specific circuit.
- Introduce a configurable "CircuitBuilder" to more-easily control
construction of "typ
stance across multiple processes on the
> same host.
ZeroMQ has an "INPROC" transport that works for inter-thread
communication (and it's way faster than the networked ones, even
unix-sockets, at least a few years back when I benchmarked some thin
tps://summerofcode.withgoogle.com
what you posted earlier is a good start, but please follow the template
-- and I think it would be best if we could provide feedback on the GSoC
site itself.
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
htt
emaining Python3
problems. Also, txsocksx doesn't support Python3, but making that
optional is possible (althought then of course no client-side connection
support).
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.
probably be a good idea.
I do not know how many slots Tor has for GSoC 2016...
Cheers,
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
rently uses @inlineCallbacks and convert it to "just" callbacks +
Deferreds -- as txaio doesn't provide support for @inlineCallbacks /
@coroutine
As for "txtorcon tickets to work on", have a look on GitHub. One good
one might be https://github.com/meejah/txtorcon/issues/1
Regarding https://github.com/meejah/txtorcon/pull/155 does anyone have a
good reason not to move txtorcon to using "ipaddress" -- this is a built-in
library on Python3, with backports to Python2.
Thanks,
meejah
___
tor-dev mailing li
user" > foo
echo "GETINFO process/pid" >> foo
cat foo | carml cmd -
So, this will produce stdout like this:
process/user=debian-tor
process/pid=1234
(Of course, you can make the above shorter/different in various ways,
and GETINFO accepts multiple keys alr
https://pypi.python.org/pypi/txtorcon/0.14.2
https://github.com/meejah/txtorcon/releases/tag/v0.14.2
Releases are also available from the hidden service:
http://timaq4ygg2iegci7.onion/txtorcon-0.14.2.tar.gz
http://timaq4ygg2iegci7.onion/txtorcon-0.14.2.tar.gz.asc
http://timaq4ygg2ie
"tor related").
+1 for 94% test-coverage :)
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
#x27;t tried either of the above. I also recall a Python + Twisted
one, too, but I can't find it now.
--
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
meejah writes:
> * add .is_built Deferred to txtorcon.Circuit that gets callback()'d
> when the circuit becomes BUILT
This had a bug in it. I give you 0.14.1:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There was a subtle bug with the Circuit.is_built API introduce
hon.org/pypi/txtorcon/0.14.0
https://github.com/meejah/txtorcon/releases/tag/v0.14.0
Releases are also available from the hidden service:
http://timaq4ygg2iegci7.onion/txtorcon-0.14.0.tar.gz
http://timaq4ygg2iegci7.onion/txtorcon-0.14.0.tar.gz.asc
http://timaq4ygg2iegci7.onion/txtorcon-
eaking,
with a 1:1 relay-to-local-Tor/Stem instance this might not really matter
very much (i.e. if there's always 0 or 1 web browser clients it probably
doesn't matter how long you pause the reactor).
Cheers,
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
1 - 100 of 157 matches
Mail list logo
