The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:04:12Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9214Allow alternate bw limits in k/m/g bits2020-06-27T14:04:12ZTracAllow alternate bw limits in k/m/g bitsCurrently relay bw limits can be set in 10**n based bytes per seconds. Standard in ISP industry is to use 2**n bits per second.
Add alternative measurement units instead of KB/GB/MB defined:
1 Mbit = 1024*1024/8 bytes/sec
1 Kbit = 1024...Currently relay bw limits can be set in 10**n based bytes per seconds. Standard in ISP industry is to use 2**n bits per second.
Add alternative measurement units instead of KB/GB/MB defined:
1 Mbit = 1024*1024/8 bytes/sec
1 Kbit = 1024/8 bytes/sec
1 Gbit = (1024^3^) /8 bytes/sec
It will make bandwidth limit settings much easier to match bw limit given to you by ISP and you can easily compare it against graphs of traffic from ISP.
Nobody is using 10 based bytes per second.
**Trac**:
**Username**: hsnTor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9207Outdated configure advice concerning libssl2020-06-27T14:04:12ZDamian JohnsonOutdated configure advice concerning libsslIf you lack libssl tor's configure fails with...
```
checking for openssl directory... configure: WARNING: Could not find a linkable openssl. If you have it installed somewhere unusual, you can specify an explicit path using --with-ope...If you lack libssl tor's configure fails with...
```
checking for openssl directory... configure: WARNING: Could not find a linkable openssl. If you have it installed somewhere unusual, you can specify an explicit path using --with-openssl-dir
configure: WARNING: On Debian, you can install openssl using "apt-get install libssl"
configure: WARNING: You will probably need libssl-dev too.
configure: error: Missing libraries; unable to proceed.
```
This is all fine except the openssl package presently doesn't exist in either ubuntu or debian sid...
http://packages.debian.org/sid/libssl
https://launchpad.net/ubuntu/+source/libssl
Installing libssl-dev did the trick for me.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9176Make the predicted circuits timeout after a configurable amount of time2020-06-27T14:04:13ZMatthew FinkelMake the predicted circuits timeout after a configurable amount of timeThis was brought up by a user in #tor who expected that tor became dormant after a short amount of time (20 min). It may be a good idea to make the PREDICTED_CIRCS_RELEVANCE_TIME value configurable, currently it is hard coded at 1 hour.
...This was brought up by a user in #tor who expected that tor became dormant after a short amount of time (20 min). It may be a good idea to make the PREDICTED_CIRCS_RELEVANCE_TIME value configurable, currently it is hard coded at 1 hour.
I think one hour is still a good default.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9062Authorities should describe their bwauth version in their votes2020-08-05T20:44:52ZNick MathewsonAuthorities should describe their bwauth version in their votesRight now, there's not a great way to tell which authorities have upgraded their bwauths, which creates trouble as in the case of legacy/trac#8688 . If we have future bwauth software report its version, and we have future Tor authoritie...Right now, there's not a great way to tell which authorities have upgraded their bwauths, which creates trouble as in the case of legacy/trac#8688 . If we have future bwauth software report its version, and we have future Tor authorities check that version and report it in their networkstatus votes, then we'll not stumble into that situation again.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9043Replace `pkey_eq` with `EVP_PKEY_cmp`2020-06-27T14:04:19ZTracReplace `pkey_eq` with `EVP_PKEY_cmp`In tortls.c the comment says:
```
/* We'd like to do this, but openssl 0.9.7 doesn't have it:
return EVP_PKEY_cmp(a,b) == 1;
*/
```
Which is true, but AFAIK tor now depends on openssl 0.9.8 which seem to have this function:
```
...In tortls.c the comment says:
```
/* We'd like to do this, but openssl 0.9.7 doesn't have it:
return EVP_PKEY_cmp(a,b) == 1;
*/
```
Which is true, but AFAIK tor now depends on openssl 0.9.8 which seem to have this function:
```
openssl-0.9.8$ grep EVP_PKEY_cmp * -R
crypto/evp/evp.h:int EVP_PKEY_cmp(const EVP_PKEY *a, const EVP_PKEY *b);
```
**Trac**:
**Username**: marekTor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8961src/or/replaycache.c hashes entries with SHA-12020-06-27T14:04:22ZRobert Ransomsrc/or/replaycache.c hashes entries with SHA-1Tor is supposed to be moving away from SHA-1, and the replay-detection cache can be migrated _and_ protected against hash flooding at the same time (see also legacy/trac#4900) without a protocol change. Just add and use a `crypto_digest...Tor is supposed to be moving away from SHA-1, and the replay-detection cache can be migrated _and_ protected against hash flooding at the same time (see also legacy/trac#4900) without a protocol change. Just add and use a `crypto_digest_local` function which prepends a random bytestring (either 16 bytes or a full hash block), then applies either SHA-256 (if Tor was compiled for a 32-bit architecture) or SHA-512 (if Tor was compiled for a 64-bit architecture), then returns the first 160 bits.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8960replaycache_add_test_and_elapsed uses int for the length of a cache entry2020-06-27T14:04:22ZRobert Ransomreplaycache_add_test_and_elapsed uses int for the length of a cache entryThe rest of Tor uses `size_t` for buffer lengths.The rest of Tor uses `size_t` for buffer lengths.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8791munge_extrainfo_into_routerinfo would mishandle a non-extrainfo2020-06-27T14:04:27ZNick Mathewsonmunge_extrainfo_into_routerinfo would mishandle a non-extrainfoIf you could somehow make munge_extrainfo_into_routerinfo() get a document which wasn't an extrainfo, it would be in trouble, since it assumes that the relevant history lines are NUL-terminated.
For quality-of-implementation, it should ...If you could somehow make munge_extrainfo_into_routerinfo() get a document which wasn't an extrainfo, it would be in trouble, since it assumes that the relevant history lines are NUL-terminated.
For quality-of-implementation, it should check the return value of memchr().Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8787Check return values for more unix functions2020-07-24T14:58:06ZNick MathewsonCheck return values for more unix functionsReportedly, we lack checks for the return values of at least munmap, lseek, unlink. We should fix that for code-quality.Reportedly, we lack checks for the return values of at least munmap, lseek, unlink. We should fix that for code-quality.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8749Return information about the leaking application2021-06-18T18:21:28ZbastikReturn information about the leaking applicationLog from where the leaking request came.
When Tor says (in the Vidalia log):
> Potentially Dangerous Connection! - One of your applications established a connection through Tor to "!IP:PORT" using a protocol that may leak information a...Log from where the leaking request came.
When Tor says (in the Vidalia log):
> Potentially Dangerous Connection! - One of your applications established a connection through Tor to "!IP:PORT" using a protocol that may leak information about your destination. Please ensure you configure your applications to use only SOCKS4a or SOCKS5 with remote hostname resolution.
could Tor tell what port the connection was made from? Maybe the log could include SOCKS details (like username). I don't think it isn't able to identify the application.
Sure it's bad to use random stuff with Tor, but this information makes it easier to sort out applications that leak.https://gitlab.torproject.org/tpo/core/tor/-/issues/8712Authorities should not vote against Fast just because they vote against Running2020-06-27T14:04:30ZRoger DingledineAuthorities should not vote against Fast just because they vote against RunningNon-active relays get stripped of their Fast flag, even if the bwauth measurements put them above the Fast threshold.
Seems to me that if enough other authorities find the relay to be Running, we shouldn't be voting against giving him t...Non-active relays get stripped of their Fast flag, even if the bwauth measurements put them above the Fast threshold.
Seems to me that if enough other authorities find the relay to be Running, we shouldn't be voting against giving him the Fast flag.
Probably same with other flags like Guard, Stable, and Exit.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8415Use event_set_mem_functions2022-04-29T21:02:58ZNick MathewsonUse event_set_mem_functionsWe should use event_set_mem_functions so that Libevent also uses our memory allocation functions, as we do for openssl when we call CRYPTO_set_mem_ex_functions.We should use event_set_mem_functions so that Libevent also uses our memory allocation functions, as we do for openssl when we call CRYPTO_set_mem_ex_functions.Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/8297Do not start reading connection if any blocking reason still present2020-06-27T14:04:42ZcypherpunksDo not start reading connection if any blocking reason still presentTor can to start reading edge connection just because received SENDME cell, or cell queue reduced only or just refilled buckets. While all another reasons of blocking connection still present. No need to start reading edge connection if ...Tor can to start reading edge connection just because received SENDME cell, or cell queue reduced only or just refilled buckets. While all another reasons of blocking connection still present. No need to start reading edge connection if any of blocking reasons still true.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8278Wrap conditionally-compiled C files in #ifdefs2021-06-18T18:21:28ZNick MathewsonWrap conditionally-compiled C files in #ifdefsFor people editing Tor with an IDE, it can be helpful to have the files which won't get built surrounded with appropriate #ifdef blocks. That way, their IDE won't complain that the file is uncompileable when in fact it's not even suppos...For people editing Tor with an IDE, it can be helpful to have the files which won't get built surrounded with appropriate #ifdef blocks. That way, their IDE won't complain that the file is uncompileable when in fact it's not even supposed to get built.
This is also an issue for people writing their own build scripts/tools for Tor and getting it wrong, but I'm less interested in handling that case.
This ticket is more or less in "Lorax" status. ("Unless someone like you cares a whole awful lot / nothing is going to get better. It's not.") I'll take a clean patch for it in 0.2.5 or later if somebody writes one.https://gitlab.torproject.org/tpo/core/tor/-/issues/8206Check return values from fcntl and setsockopt2020-06-27T14:04:46ZNick MathewsonCheck return values from fcntl and setsockoptThese functions are allowed to fail, though in practice they won't (at least, not the way we're using them). Still, our failure to check the return values makes some tools (Coverity scan) unhappy. Let's clean up false positives by chec...These functions are allowed to fail, though in practice they won't (at least, not the way we're using them). Still, our failure to check the return values makes some tools (Coverity scan) unhappy. Let's clean up false positives by checking our 12 unchecked fcntls and our one unchecked setsockopt.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8197Do something about policies_parse_exit_policy()'s arguments2021-09-16T14:36:00ZRoger DingledineDo something about policies_parse_exit_policy()'s arguments```
r = policies_parse_exit_policy(&line, &policy, 1, 0, 0, 1);
...
test_assert(0 == policies_parse_exit_policy(NULL, &policy2, 1, 1, 0, 1));
```
Quick quiz: which of these booleans means what? And which one isn't a boolean at all? ...```
r = policies_parse_exit_policy(&line, &policy, 1, 0, 0, 1);
...
test_assert(0 == policies_parse_exit_policy(NULL, &policy2, 1, 1, 0, 1));
```
Quick quiz: which of these booleans means what? And which one isn't a boolean at all? :)
(Don't work on this ticket until we merge legacy/trac#5528.)Tor: 0.2.6.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/8180EntryNodes ignored when UseEntryGuards==0, warning can be overlooked2020-06-27T14:04:48ZcypherpunksEntryNodes ignored when UseEntryGuards==0, warning can be overlookedThe man page doesn't mention that the EntryNodes option only applies when Tor uses entry guards. I think this is not the expected bahaviour because the option is called "EntryNodes" and not "EntryGuards".
If you don't want to fix this, ...The man page doesn't mention that the EntryNodes option only applies when Tor uses entry guards. I think this is not the expected bahaviour because the option is called "EntryNodes" and not "EntryGuards".
If you don't want to fix this, at least let Tor exit with an error when it reads the torrc file, because if someone provides a list of EntryNodes, that can only mean he doesn't want his computer to connect to other nodes, and it might be dangerous for him if Tor does it anyway.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8051Broken check for empty "bridge-ips" line in validate_bridge_stats()2020-07-24T14:16:14ZGeorge KadianakisBroken check for empty "bridge-ips" line in validate_bridge_stats()`geoip_format_bridge_stats()` generates the `bridge-stats` file contents, and if `country_data` is NULL then it writes "bridge-ips \n" to the file.
Then when `validate_bridge_stats()` is called, if it can't find a populated `bridge-ips`...`geoip_format_bridge_stats()` generates the `bridge-stats` file contents, and if `country_data` is NULL then it writes "bridge-ips \n" to the file.
Then when `validate_bridge_stats()` is called, if it can't find a populated `bridge-ips` line it tries to match "bridge-ips\n", which should always fail because of the extra whitespace that was added in `geoip_format_bridge_stats()`. Isn't that right?
The only thing that confuses me is why this hasn't triggered so far. Maybe something in my analysis is incorrect, or the `bridge-stats` file is always generated after we accept a connection?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8042Reloaded md never be purged for platforms with unsigned time_t2020-06-27T14:04:54ZcypherpunksReloaded md never be purged for platforms with unsigned time_tmicrodesc_cache_reload() calls microdescs_add_to_cache() with listed_at == -1, so md->last_listed was defined by annotation loaded from disk only.
```
if (listed_at > 0) {
SMARTLIST_FOREACH(descriptors, microdesc_t *, md,
...microdesc_cache_reload() calls microdescs_add_to_cache() with listed_at == -1, so md->last_listed was defined by annotation loaded from disk only.
```
if (listed_at > 0) {
SMARTLIST_FOREACH(descriptors, microdesc_t *, md,
md->last_listed = listed_at);
```
But if unsigned time_t then last_listed updated to 0xFF..FF value so that md never be purged by microdesc_cache_clean(). If such md was flushed to disk during rebuild cache then it will forever live.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8037Specialy crafter microdesc could trigger to flush up to 16MB uninited heap al...2020-06-27T14:04:54ZcypherpunksSpecialy crafter microdesc could trigger to flush up to 16MB uninited heap allocated memory to mediamicrodescs_parse_from_string() and so on func do not count string as null terminated and allows to process "string" with zero byte in middle. md->body = tor_strndup(cp, md->bodylen) duplicate only partial of such string. dump_microdescri...microdescs_parse_from_string() and so on func do not count string as null terminated and allows to process "string" with zero byte in middle. md->body = tor_strndup(cp, md->bodylen) duplicate only partial of such string. dump_microdescriptor() flushes all bodylen of md's body to disk. Specially crafted bytes append to valid md sent by directory cache could lead to flush up to 16MB of memory data to media. Tor tries to clear sensitive data on free(), but some non cleared memory still no need to write in plain text to media.Tor: 0.2.4.x-final