Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:56:22Zhttps://gitlab.torproject.org/legacy/trac/-/issues/296clients potentially overwhelm circuits with new streams2020-06-13T13:56:22Zgoodellclients potentially overwhelm circuits with new streamsWell-behaved Tor clients SHOULD not attach a stream to a circuit
if the circuit has more than N not-yet-connected streams on it.
In particular, some exit nodes cannot handle so many new TCP
connections to open, even if middleman nodes ju...Well-behaved Tor clients SHOULD not attach a stream to a circuit
if the circuit has more than N not-yet-connected streams on it.
In particular, some exit nodes cannot handle so many new TCP
connections to open, even if middleman nodes just see all of the
traffic as cells to pass along.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.1.xRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/511htw3.png is misleading2020-06-13T17:18:16ZRoger Dingledinehtw3.png is misleadinghttp://tor.eff.org/images/htw3.png says
"If the user wants access to another site,"
and this is wrong.
It should perhaps say "Later," or "After a while,"?
[Automatically added by flyspray2trac: Operating System: All]http://tor.eff.org/images/htw3.png says
"If the user wants access to another site,"
and this is wrong.
It should perhaps say "Later," or "After a while,"?
[Automatically added by flyspray2trac: Operating System: All]post 0.2.1.xhttps://gitlab.torproject.org/legacy/trac/-/issues/518outgoing socks proxy support2020-06-13T13:58:44ZTracoutgoing socks proxy supportI'd like to request outgoing socks proxy support in order for the tor client on
heavily firewalled machines to be able to connect out in the case where the
firewall only accepts socks connection.
machine behind fw --> tor client --> s...I'd like to request outgoing socks proxy support in order for the tor client on
heavily firewalled machines to be able to connect out in the case where the
firewall only accepts socks connection.
machine behind fw --> tor client --> socks proxy on fw --> internet
Nickm said on irc that it wouldn't be too hard so here's wishing :).
Thanks
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: kuzepost 0.2.1.xhttps://gitlab.torproject.org/legacy/trac/-/issues/652Tor doesn't detect when the world cannot reach it anymore2020-06-13T14:07:28ZSebastian HahnTor doesn't detect when the world cannot reach it anymoreThis is Tor r14297. When my internet connection dies (as it does every 24 hours),
and I come back up with a different IP address, Tor doesn't seem to notice that
the world cannot connect to it anymore. This used to be different in the p...This is Tor r14297. When my internet connection dies (as it does every 24 hours),
and I come back up with a different IP address, Tor doesn't seem to notice that
the world cannot connect to it anymore. This used to be different in the pre-RC
versions, I haven't checked the previous RCs for that behaviour. Even after 6 hours,
Tor has nothing in the Notice-level log.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.1.xhttps://gitlab.torproject.org/legacy/trac/-/issues/696WFU not computed right for never-down relay2020-06-13T13:59:59ZRoger DingledineWFU not computed right for never-down relaycorfu has been up since it generated its key -- it has never been down.
Its entry in moria1's router-stability file is
R 7CAA2F5F998053EF5D2E622563DEB4A6175E49AC
+MTBF 0 0.00000 S=2008-05-15 23:26:01
+WFU 0 0
But in the cached-consens...corfu has been up since it generated its key -- it has never been down.
Its entry in moria1's router-stability file is
R 7CAA2F5F998053EF5D2E622563DEB4A6175E49AC
+MTBF 0 0.00000 S=2008-05-15 23:26:01
+WFU 0 0
But in the cached-consensus, we have
r corfu fKovX5mAU+9dLmIlY960phdeSaw fuzu6FZU2vwuiT47PLMblVITIAI 2008-06-09 06:19:48 140.247.60.83 443 80
s Fast Guard Running V2Dir Valid
It has no stable flag. Because its WFU is 0. Even though its only uptime
run is currently at about 26 days.
moria1 has been up since May 19.
So are we forgetting to update our WFU entries for relays that don't have
an up or down event? I wonder how much this is skewing our 'stable'
calculations.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.1.xhttps://gitlab.torproject.org/legacy/trac/-/issues/816Tor server endlessly hibernates2020-06-13T14:00:31ZAndrew LewmanTor server endlessly hibernates0.2.1.5-alpha compiled from source on 64bit redhat4. torrc options set for bandwidth are:
AccountingMax 900GB
AccountingStart month 19 00:00
On start up, tor states:
"Configured hibernation. This interval began at 2008-08-19 00:00:00...0.2.1.5-alpha compiled from source on 64bit redhat4. torrc options set for bandwidth are:
AccountingMax 900GB
AccountingStart month 19 00:00
On start up, tor states:
"Configured hibernation. This interval began at 2008-08-19 00:00:00; the scheduled wake-up time was
2008-08-19 00:00:00; we expect to exhaust our quota for this interval around 2008-09-19 00:00:00;
the next interval begins at 2008-09-19 00:00:00 (all times local)"
Watching traffic from my node, which before was easily 2-3 mb/s, is now nearly zero. IIRC, 0.2.1.2-alpha ran correctly
and consumed all 900GB in the time interval.
My state file is:
# How many bytes have we read in this accounting period?
AccountingBytesReadInInterval 65724230656
# How many bytes have we written in this accounting period?
AccountingBytesWrittenInInterval 66265904128
# How many bytes did we expect to use per minute? (0 for no estimate.)
AccountingExpectedUsage 2083252
# When did this accounting period begin?
AccountingIntervalStart 2008-08-19 05:00:00
# How long have we been awake in this period?
AccountingSecondsActive 1983625
# When does the last-recorded read-interval end?
BWHistoryReadEnds 2008-09-11 04:15:41
# When does the last-recorded write-interval end?
BWHistoryWriteEnds 2008-09-11 04:15:41
[Automatically added by flyspray2trac: Operating System: Redhat/CentOS Linux]post 0.2.1.xhttps://gitlab.torproject.org/legacy/trac/-/issues/871Allow Advertiseing of Dirport with accounting max enabled2020-06-13T14:00:51ZTracAllow Advertiseing of Dirport with accounting max enabledOne should be able to choose how to spend the bandwidth. Currently when accounting max is
enabled, the Dirport is not advertised.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: JonOne should be able to choose how to spend the bandwidth. Currently when accounting max is
enabled, the Dirport is not advertised.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Jonpost 0.2.1.xhttps://gitlab.torproject.org/legacy/trac/-/issues/917Nameserver probes can give strange results2020-06-13T14:01:12ZNick MathewsonNameserver probes can give strange resultsWe should not actually retry nameserver probes, nor should we _ever_ reattach them to a new nameserver after
clear and resume.
Fortunately, the worst that happens here now is that we erroneously mark a down nameserver as up, retry it,
...We should not actually retry nameserver probes, nor should we _ever_ reattach them to a new nameserver after
clear and resume.
Fortunately, the worst that happens here now is that we erroneously mark a down nameserver as up, retry it,
fail, and mark it down again. Still, that's pretty ugly.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.1.xhttps://gitlab.torproject.org/legacy/trac/-/issues/920don't bundle libevent with Tor2020-06-13T14:01:14ZTracdon't bundle libevent with TorHi,
I am the maintainer of Tor in Gentoo Linux and we have an open report in our issues tracker: http://bugs.gentoo.org/show_bug.cgi?id=206969
The report states that the asynchronous DNS part of libevent is bundled with Tor, which is t...Hi,
I am the maintainer of Tor in Gentoo Linux and we have an open report in our issues tracker: http://bugs.gentoo.org/show_bug.cgi?id=206969
The report states that the asynchronous DNS part of libevent is bundled with Tor, which is true (see src/or/evendns.{c,h}). This gives our security team and myself a headache as a security problem found in libevent has to be tracked in all messages that bundle it or just only parts. Please remove that bit and try to bring your modifications upstream to libevent if needed.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: V-Lipost 0.2.1.xhttps://gitlab.torproject.org/legacy/trac/-/issues/921clients avoid *all* authority types when avoiding any2020-06-13T14:01:14ZRoger Dingledineclients avoid *all* authority types when avoiding anyClients doing directory fetches avoid authorities of all types when trying
to avoid authorities of any type. So a client asking for a v3 consensus will
never ask moria2, because moria2 is an authority of some type. Similarly,
caches want...Clients doing directory fetches avoid authorities of all types when trying
to avoid authorities of any type. So a client asking for a v3 consensus will
never ask moria2, because moria2 is an authority of some type. Similarly,
caches wanting a v3 consensus won't ask moria2, because it's not a v3
authority. Same goes for Tonga, our bridge authority.
See
is_trusted = router_digest_is_trusted_dir(status->identity_digest);
in router_pick_directory_server_impl() in routerlist.c
We should instead ask if it's a trusted dir for the type of authority
we're wondering about.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.1.xhttps://gitlab.torproject.org/legacy/trac/-/issues/937Tor does not support OpenSSL dynamic hardware engines2020-06-13T14:01:26ZcodermanTor does not support OpenSSL dynamic hardware enginesNOTE: fix due in 0.2.2.x.
branch hardware_accel_improvements at git://git.torproject.org/~coderman/git/tor.git
The existing support for crypto acceleration in Tor via the HardwareAccel 1 option is not able to load dynamic engines.
For ...NOTE: fix due in 0.2.2.x.
branch hardware_accel_improvements at git://git.torproject.org/~coderman/git/tor.git
The existing support for crypto acceleration in Tor via the HardwareAccel 1 option is not able to load dynamic engines.
For example, padlock acceleration with Via processors. See also http://archives.seul.org/or/talk/Dec-2008/msg00314.html
To fix this the src/common/crypto.c should be extended to attempt dynamic engine loading.
NOTE: I have fixed the engine name to "padlock"; robust support for this feature will require a config option
like "HardwareEngineName" or such.
In crypto_global_init():
if (useAccel > 0) {
ENGINE *e = NULL;
log_info(LD_CRYPTO, "Initializing OpenSSL engine support.");
ENGINE_load_builtin_engines();
ENGINE_register_all_complete();
e = ENGINE_by_id ("padlock");
if (!e) {
log_info(LD_CRYPTO, "Trying to load dynamic Padlock OpenSSL engine.");
e = try_load_engine ("padlock");
if (!e) {
log_info(LD_CRYPTO, "Unable to load Padlock OpenSSL engine.");
}
}
if (e) {
log_info(LD_CRYPTO, "Loaded Padlock OpenSSL engine, setting default ciphers.");
ENGINE_set_default (e, ENGINE_METHOD_ALL);
}
}
Where the try_load_engine for dynamic libs is:
/* Try to load a dynamic engine library. */
static ENGINE *
try_load_engine(const char *engine)
{
ENGINE *e = ENGINE_by_id ("dynamic");
if (e)
{
if (!ENGINE_ctrl_cmd_string (e, "SO_PATH", engine, 0)
|| !ENGINE_ctrl_cmd_string (e, "LOAD", NULL, 0))
{
ENGINE_free (e);
e = NULL;
}
}
return e;
}
Depending on VIA processor/stepping this results in:
Mar 08 06:32:00.473 [info] crypto_global_init(): Initializing OpenSSL engine support.
Mar 08 06:32:00.473 [info] crypto_global_init(): Loaded Padlock OpenSSL engine, setting default ciphers.
Mar 08 06:32:00.473 [info] Using default implementation for RSA
Mar 08 06:32:00.473 [info] Using default implementation for DH
Mar 08 06:32:00.473 [info] Using default implementation for RAND
Mar 08 06:32:00.473 [notice] Using OpenSSL engine VIA PadLock: RNG (not used) ACE2 PHE(8192) PMM [padlock] for SHA1
Mar 08 06:32:00.473 [info] Using default implementation for 3DES
Mar 08 06:32:00.473 [notice] Using OpenSSL engine VIA PadLock: RNG (not used) ACE2 PHE(8192) PMM [padlock] for AES
...
[Automatically added by flyspray2trac: Operating System: All]post 0.2.1.xcodermancodermanhttps://gitlab.torproject.org/legacy/trac/-/issues/1023Authorities should avoid voting on Running if they just came up2020-06-13T14:02:17ZRoger DingledineAuthorities should avoid voting on Running if they just came upthe reason this came up is when an authority comes up near to voting time,
it ends all the uptimes in its router-stability file, because it votes 'no'
on all of them, and the act of deciding its vote changes the router-stability
line.
<...the reason this came up is when an authority comes up near to voting time,
it ends all the uptimes in its router-stability file, because it votes 'no'
on all of them, and the act of deciding its vote changes the router-stability
line.
<nickm> Proposed other behavior: If we have been up less than N minutes, don't
vote on Running. For N == 30? 45?
> 30 should be fine
<nickm> We'd probably want this to be overridable for test networks, alas.
> hey, we have a config option for that.
> V(TestingTorNetwork, BOOL, "0"),
> which could override it automatically
[Automatically added by flyspray2trac: Operating System: All]post 0.2.1.x