Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:02:11Zhttps://gitlab.torproject.org/legacy/trac/-/issues/67We need to pass a string back along with the http status codes2020-06-13T14:02:11ZRoger DingledineWe need to pass a string back along with the http status codesThe dirserver gives back a status code (e.g. 403) plus a string. We need to make that string
configurable based on what the error/status actually is, and have the client parse out the
string.
Currently, there's no distinction between "y...The dirserver gives back a status code (e.g. 403) plus a string. We need to make that string
configurable based on what the error/status actually is, and have the client parse out the
string.
Currently, there's no distinction between "you're an unverified server" and "your clock is
extremely wrong". So people don't know there's anything to fix.
In addition, since we *do* accept unverified servers now, we should be giving back a "200 unverified server accepted" rather than a 403.
[Automatically added by flyspray2trac: Operating System: All]0.1.0.1-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/68Tor complains about missing epoll2020-06-13T14:02:11ZRoger DingledineTor complains about missing epollIt prints out
"tor: epoll_create: Function not implemented"
every time I start
on Red Hat FC1
Would it make sense to auto-detect better and/or disable epoll?
This will generate an unending stream of bug reports, as is.
[Automatically a...It prints out
"tor: epoll_create: Function not implemented"
every time I start
on Red Hat FC1
Would it make sense to auto-detect better and/or disable epoll?
This will generate an unending stream of bug reports, as is.
[Automatically added by flyspray2trac: Operating System: Other Linux]0.1.0.1-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/69Add flag to tor to verify config2020-06-13T14:02:11ZTracAdd flag to tor to verify configRight now if you edit the torrc incorrectly and HUP tor, it dies (and only says so in the log file so you
may not even notice for awhile. Anyways, it would be nice if tor had something equivalent to Apache's -t
flag which says "verify m...Right now if you edit the torrc incorrectly and HUP tor, it dies (and only says so in the log file so you
may not even notice for awhile. Anyways, it would be nice if tor had something equivalent to Apache's -t
flag which says "verify my config and tell me what if anything is broken". That way we could have a
torctl script which has a 'reload' option which would first verify the config and if OK, would HUP tor.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: synfinatic0.1.0.1-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/70Don't force BandwidthBurst to be 2x + 1 BandwithRate2020-06-13T14:02:11ZTracDon't force BandwidthBurst to be 2x + 1 BandwithRateForcing BandwidthBurst to be 2x + 1 (or even 2x) the BandwidthRate is silly for people who
would like Tor to be able to burst to their full link speed, but average above 50% of the link speed.
Ie: I have a 768K link and want tor to aver...Forcing BandwidthBurst to be 2x + 1 (or even 2x) the BandwidthRate is silly for people who
would like Tor to be able to burst to their full link speed, but average above 50% of the link speed.
Ie: I have a 768K link and want tor to average 512K and burst up to 768K. Current limitation would require
me to set BandwidthRate to 384K not 512K.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: synfinatichttps://gitlab.torproject.org/legacy/trac/-/issues/71Warn when exit policy allows private:*2020-06-13T14:02:11ZNick MathewsonWarn when exit policy allows private:*Too many people are telling us that the sky is falling because that Tor allows connections to private networks. This is, of course, because people aren't setting their exit policies to block them. Nevertheless, we should probably have ...Too many people are telling us that the sky is falling because that Tor allows connections to private networks. This is, of course, because people aren't setting their exit policies to block them. Nevertheless, we should probably have Tor give a warning when you start a server and the exit policy allows x:* connections to a non-public address.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/72Open LDAP and LDAPS ports in the default policy2020-06-13T14:02:11ZshamrockOpen LDAP and LDAPS ports in the default policyTor currently does not proxy the LDAP (389/tcp) and LDAPS (636/tcp) ports.
Feature Request: proxy the LDAP and LDAPS ports.
Background:
LDAP(S) is the standard protocol to obtain recipients' cryptographic keys on the Internet. Any enti...Tor currently does not proxy the LDAP (389/tcp) and LDAPS (636/tcp) ports.
Feature Request: proxy the LDAP and LDAPS ports.
Background:
LDAP(S) is the standard protocol to obtain recipients' cryptographic keys on the Internet. Any entity making an LDAP server available to the public does so to permit public dissemination of their users' directory information. The abuse potential of permitting these ports to be proxied is negligible, no higher than the abuse potential of permitting the proxying of http and inarguably lower than permitting the proxying of other ports already available via tor, such as ssh or IRC.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/73Issues with Tor server and XP SP22020-06-13T14:02:11ZTracIssues with Tor server and XP SP2Operating System(s)
Windows System : Microsoft Windows XP/2002 Professional (Win32 x86)
5.01.2600 (Service Pack 2)
Model : AMD Athlon(tm) XP 2400+
Speed : 2.00GHz
Model Number : 2400 (estimated)
Performance Rating : PR2904 (estimated)
Ty...Operating System(s)
Windows System : Microsoft Windows XP/2002 Professional (Win32 x86)
5.01.2600 (Service Pack 2)
Model : AMD Athlon(tm) XP 2400+
Speed : 2.00GHz
Model Number : 2400 (estimated)
Performance Rating : PR2904 (estimated)
Type : Standard
L2 On-board Cache : 256kB ECC Synchronous Write-Back (16-way, 64 byte line size)
Mainboard
Bus(es) : AGP PCI USB FireWire/1394 i2c/SMBus
MP Support : No
MP APIC : No
System BIOS : Phoenix Technologies, LTD ASUS A7N8X2.0 Deluxe ACPI
BIOS Rev 1008
Mainboard : ASUSTeK Computer INC. A7N8X2.0
Total Memory : 1023MB
Chipset 1
Model : ASUSTeK Computer Inc nForce2 AGP Controller
Front Side Bus Speed : 2x 134MHz (268MHz data rate)
Problem:
Everything is going fine.
All of a sudden upload and download go to 0.
Cannot open any programs.
Any browser windows that are open and connecting will
never connect.
Programs that are already running will
minimize/restore/exit and work to some degree.
Sometimes everything will start working after 2 to 10
minutes.
Longer than that i reset the computer.
Seems to get stuck at one certain spot and very little
else can happen until it gets past that point.
Even the task manager will not open with ctrl alt delete.
It seems to occur when it is trying to establish a connection of some type and can't establish it.
My intuition tells me it is conflicting with one of the XP services but I cannot verify that.
Logs available upon request.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: ZincoAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/74Servers bloat memory from spawned children2020-06-13T14:02:11ZRoger DingledineServers bloat memory from spawned childrenWhen we fork, our children inherit the memory from the main Tor
process, which can be 50MB or more. Since it's copy-on-write, no
problem so far. But when the main Tor process changes the memory,
or frees it, then it gets copied so the ch...When we fork, our children inherit the memory from the main Tor
process, which can be 50MB or more. Since it's copy-on-write, no
problem so far. But when the main Tor process changes the memory,
or frees it, then it gets copied so the child has a clean copy.
So we end up using 50+MB per child. When we spawn a lot of dnsworkers,
this becomes really bad.
[Automatically added by flyspray2trac: Operating System: All]0.1.0.1-rchttps://gitlab.torproject.org/legacy/trac/-/issues/76don't ask unverified nodes for a directory2020-06-13T14:02:11ZRoger Dingledinedon't ask unverified nodes for a directoryUnverified nodes sometimes have really weird bandwidth shaping, and they also sometimes have
really wrong clocks. So asking them for a directory is just asking for trouble, and there are
enough other mirrors that we should be ok.
[Autom...Unverified nodes sometimes have really weird bandwidth shaping, and they also sometimes have
really wrong clocks. So asking them for a directory is just asking for trouble, and there are
enough other mirrors that we should be ok.
[Automatically added by flyspray2trac: Operating System: All]0.1.0.1-rchttps://gitlab.torproject.org/legacy/trac/-/issues/77clients are believing really old recommended-versions2020-06-13T14:02:11ZRoger Dingledineclients are believing really old recommended-versionsClients believe recommended-versions no matter how old the directory is.
Option one: don't check recommended-versions if massive clock skew is detected on the dir.
Option two: remember the timestamp of the last recommended-versions you...Clients believe recommended-versions no matter how old the directory is.
Option one: don't check recommended-versions if massive clock skew is detected on the dir.
Option two: remember the timestamp of the last recommended-versions you saw, and discard
newly received ones that are older than it.
Option three: both.
[Automatically added by flyspray2trac: Operating System: All]0.1.0.1-rchttps://gitlab.torproject.org/legacy/trac/-/issues/78please add 'opt hibernating yes' in the descriptor2020-06-13T14:02:11Zweasel (Peter Palfrader)please add 'opt hibernating yes' in the descriptorIt would be nice if the server descriptor of hibernating nodes just said
conclusively that this node is in fact hibernating right now.
Probably something like "opt hibernating yes" would work. If you want
to make it fancy you could eve...It would be nice if the server descriptor of hibernating nodes just said
conclusively that this node is in fact hibernating right now.
Probably something like "opt hibernating yes" would work. If you want
to make it fancy you could even well when it expects to wake up again.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/79clients pick you as an exit node if there's even a chance you can exit there2020-06-13T13:57:14ZRoger Dingledineclients pick you as an exit node if there's even a chance you can exit thereWhen clients don't know the IP of foobarbaz.com:80, they pick a random exit node that
will allow *any* exits to port 80. But if they pick a node that allows w.x.y.z:80
and then rejects *:80, they are almost certain to be told "here's the...When clients don't know the IP of foobarbaz.com:80, they pick a random exit node that
will allow *any* exits to port 80. But if they pick a node that allows w.x.y.z:80
and then rejects *:80, they are almost certain to be told "here's the IP, now go somewhere
else." We should short-circuit this process and only pick exit nodes that accept "most"
IPs for the port in question.
[Automatically added by flyspray2trac: Operating System: All]0.0.9.5Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/80Max dir size is 500 kilobytes2020-06-13T13:57:14ZRoger DingledineMax dir size is 500 kilobytesCurrently the max dir size, both receiving the http request from the client and providing
the http answer to the client, is 500kB. If something we try to send exceeds this, the http
attempt will fail.
Should we just keep raising this li...Currently the max dir size, both receiving the http request from the client and providing
the http answer to the client, is 500kB. If something we try to send exceeds this, the http
attempt will fail.
Should we just keep raising this limit as the directory size grows, or is there some better
solution?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/81streams end badly when server runs out of fd's2020-06-13T13:57:14ZRoger Dingledinestreams end badly when server runs out of fd'sWe need to put better reasons on stream end cells, so when a server is unwilling to make any
more exits streams, the client doesn't end up with a failed stream -- he should treat it like
a dns resolve failure and try somewhere else.
[Au...We need to put better reasons on stream end cells, so when a server is unwilling to make any
more exits streams, the client doesn't end up with a failed stream -- he should treat it like
a dns resolve failure and try somewhere else.
[Automatically added by flyspray2trac: Operating System: All]Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/82tor opens too many file descriptors2020-06-13T13:57:14Zgoodelltor opens too many file descriptorsFor those of us with systems with high-bandwidth connections, running a
Tor router causes the Tor process to open many file descriptors. So
many, in fact, that Tor routinely runs into the ceiling specified by
ulimit -n. Thus, either (a...For those of us with systems with high-bandwidth connections, running a
Tor router causes the Tor process to open many file descriptors. So
many, in fact, that Tor routinely runs into the ceiling specified by
ulimit -n. Thus, either (a) the init script included with the tor
package should manually set a large value for ulimit -n, or (b) Tor
itself should somehow set its own ulimit to be large, perhaps based upon
a configuration parameter.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/83show which dirserver said we have a skewed clock/are unverified2020-06-13T14:20:11Zweasel (Peter Palfrader)show which dirserver said we have a skewed clock/are unverifiedIn
Jan 30 00:39:44.266 [warn] connection_dir_client_reached_eof(): http
status 403 (unapproved server) response from dirserver. Is your clock
skewed? Have you mailed us your identity fingerprint? Are you using the
right key? Are you usi...In
Jan 30 00:39:44.266 [warn] connection_dir_client_reached_eof(): http
status 403 (unapproved server) response from dirserver. Is your clock
skewed? Have you mailed us your identity fingerprint? Are you using the
right key? Are you using a private IP address? See
http://tor.eff.org/doc/tor-doc.html#server.
it would be nice if tor said which dirserver said we are unverified/have a skewed clock.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/84we should handle the case where the client has no cert2020-06-13T13:57:14ZRoger Dingledinewe should handle the case where the client has no certCurrent cvs refuses connections from clients that don't have a cert chain. We ought to handle
clients that don't have one, just to be more generally compatible, and to deal with JAP
clients that apparently don't provide them.
[Automatic...Current cvs refuses connections from clients that don't have a cert chain. We ought to handle
clients that don't have one, just to be more generally compatible, and to deal with JAP
clients that apparently don't provide them.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/85Doc/Installer mismatch on MacOS X2020-06-13T13:57:14ZTracDoc/Installer mismatch on MacOS XThe website documents that you need to click "install TOR startup script," but its pre-selected in latest builds.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: adam667The website documents that you need to click "install TOR startup script," but its pre-selected in latest builds.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: adam667https://gitlab.torproject.org/legacy/trac/-/issues/86No logs in default mac package2020-06-13T13:57:14ZTracNo logs in default mac packageI installed the new mac package, and it doesn't log at all.
I suppose there may be a security argument for this, but it makes it hard to figure out what's going wrong.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 ...I installed the new mac package, and it doesn't log at all.
I suppose there may be a security argument for this, but it makes it hard to figure out what's going wrong.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: adam667Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/87Our clock skew allowances differ, leading to problems2020-06-13T13:57:14ZRoger DingledineOur clock skew allowances differ, leading to problemsdirserv_set_cached_directory(): Ignoring future directory; not caching.
This happens, causing dir mirrors to not have anything to give out, if they're more than
ROUTER_ALLOW_SKEW (30 minutes) in the past.
Yet they need to be ROUTER_MAX...dirserv_set_cached_directory(): Ignoring future directory; not caching.
This happens, causing dir mirrors to not have anything to give out, if they're more than
ROUTER_ALLOW_SKEW (30 minutes) in the past.
Yet they need to be ROUTER_MAX_AGE (24 hours) in the past before we flag any warnings
about their time skew.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewson