Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote: > On Wed, Sep 20, 2006 at 12:15:27PM +0200, Fabian Keil wrote: > > With Tor 0.1.2.1-alpha running on FreeBSD 7.0-CURRENT > > my exit nodes used to hit: > > > > [err] dns.c:596: dns_cancel_pending_resolve: Assertion ! > > resolve->expire failed; aborting. > Okay; we've had a fix for this one in the subversion repository for > while; the fix should come out in the next alpha. OK. > > several times a day, until I replaced the assertion with > > a simple warning. Before the assertion is triggered, > > launch_resolve() always complaints about: > > > > 'eventdns rejected address "$URL": error 1.' > > > > $URL always is a complete urlencoded URL > > and never a valid host name as it's supposed to be. > > > > While this isn't Tor's fault, I think it would make > > sense if the Tor client did some simple URL sanity > > checks before passing forward any requests. From time to > > time these broken URLs contain usernames and passwords. > > That's quite weird; it looks like somebody is trying to resolve URLs > rather than hostnames. How bizarre! I assume most of these URL are caused by Privoxy 3.0.3 in combination with broken URLs. The fast-redirects action in Privoxy 3.0.3 doesn't decode urlencoded URLs before checking for redirection URLs. If the redirection URL is properly encoded, Privoxy 3.0.3 will just miss it, but if "http://"; is not encoded and the rest of the URL is, Privoxy 3.0.3 will cause a redirect to the mostly urlencoded URL. Privoxy 3.0.5 beta (released yesterday) can decode the URLs before checking, and should no longer cause these broken redirects. > Ordinarily, this shouldn't be showing up in your log unless you have > SafeLogging turned off, or unless we screwed it up in 0.1.2.1-alpha > (it works now). I intentionally enabled SafeLogging for debugging purposes. > But yeah, I agree that we should check that hostnames are plausible > before trying to resolve them. I'll add that to the 0.1.2.x TODO > list. Great. > > Another assertion that I only got once so far is: > > > > [err] purge_expired_resolves(): The expired resolve we purged didn't > > match any in the cache. Tried to purge delb.myspace.com (0xb948200); > > instead got delb.myspace.com (0x804b99c). [err] dns.c:319: > > purge_expired_resolves: Assertion removed == resolve failed; aborting. > > I think we solved this one too, but let me know if it comes back, > especially after the next alpha release is out. A stack trace there > might be really handy. OK. Fabian -- http://www.fabiankeil.de/
Attachment:
signature.asc
Description: PGP signature