search

meejah / txtorcon

Twisted-based asynchronous Tor control protocol implementation. Includes unit-tests, examples, state-tracking code and configuration abstraction.
http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/
MIT License
249 stars 72 forks source link

hanging GETINFO #390

Closed meejah closed 1 year ago

meejah commented 1 year ago

Fixes #389

coveralls commented 1 year ago

Coverage Status

coverage: 99.574%. remained the same when pulling caf0b389e16e63dd06992f0a2234bbca6ed5ca75 on 389.hang-getinfo into c0c98ff4bb888b9e1e2b5b53e6a0ce5a8be3ba69 on main.

meejah commented 1 year ago

@hellais if it's easy to test, would appreciate your feedback as to whether this fixes your issue?

hellais commented 1 year ago

I have tested this PR and am happy to confirm it fixes the issue reported in #389.

I will run this branch against the full exit list and once it's done report back if it's causing any issues due to maximum length being reached.

Question ❓ : What will happen if there is a descriptor line which is longer than 2^20? Will it produce an error that hints at the fact this is the reason for the failure?

meejah commented 1 year ago

Question ❓ : What will happen if there is a descriptor line which is longer than 2^20? Will it produce an error that hints at the fact this is the reason for the failure?

No, it'll nuke the connection like it does now :( Not ideal, obviously --- I've filed https://github.com/meejah/txtorcon/issues/391 to remind future humans to produce a better message.

Another solution would be to have "no limit". Twisted's implementation doesn't allow for this directly, but either re-writing or "more overriding" should be able to remove it (or set the limit to MAX_INT). There'd still be a limit of course (available memory).