Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:07:07Zhttps://gitlab.torproject.org/legacy/trac/-/issues/21664prop278: Make the current 'torgzip' module a submodule of a new 'compression'...2020-06-13T15:07:07ZAlexander Færøyahf@torproject.orgprop278: Make the current 'torgzip' module a submodule of a new 'compression' module- Create a new 'compression' module to handle all compression schemes.
- Refactor the current 'torgzip' module into a module that handles only GZip and deflate, but adheres to the 'compression' module API.
- Create modules for the new co...- Create a new 'compression' module to handle all compression schemes.
- Refactor the current 'torgzip' module into a module that handles only GZip and deflate, but adheres to the 'compression' module API.
- Create modules for the new compression schemes: LZMA2 and Zstd.Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21665Prop278: Establish an upper-bound for LZMA2 memory usage2020-06-13T15:07:07ZAlexander Færøyahf@torproject.orgProp278: Establish an upper-bound for LZMA2 memory usageOur initial analysis shows that LZMA2 can be quite a memory hog, which means we should establish some sort of upper-bound for its memory usage and how we can actually enforce it.Our initial analysis shows that LZMA2 can be quite a memory hog, which means we should establish some sort of upper-bound for its memory usage and how we can actually enforce it.Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21666Prop278: Code to decide whether we want to request and/or provide CPU-intensi...2020-06-13T15:07:08ZAlexander Færøyahf@torproject.orgProp278: Code to decide whether we want to request and/or provide CPU-intensive compression methodsWe need some code in Tor to decide if or when we want to use and provide CPU-intensive compression operations. The biggest concern in Prop278 is LZMA2.We need some code in Tor to decide if or when we want to use and provide CPU-intensive compression operations. The biggest concern in Prop278 is LZMA2.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21667Prop278: Handle new headers in directory.c2020-06-13T15:07:09ZAlexander Færøyahf@torproject.orgProp278: Handle new headers in directory.cHandle the newly defined headers and their new values from Prop#278 in the directory server/client code.Handle the newly defined headers and their new values from Prop#278 in the directory server/client code.Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21668Prop278: Update cached_dir_t and related types to no longer assume single com...2020-06-13T15:07:09ZAlexander Færøyahf@torproject.orgProp278: Update cached_dir_t and related types to no longer assume single compresison methodUpdate the data-types for cached_dir_t to handle multiple available compression schemes.
See also: #21651Update the data-types for cached_dir_t to handle multiple available compression schemes.
See also: #21651Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21673prop140: Handle signatures correctly2020-06-13T15:07:10ZNick Mathewsonprop140: Handle signatures correctlyFor diffs to work properly, we need to check the input document and the output document in their entirety, including their signatures. Otherwise, the diffs won't apply correctly when they change the signatures!
But for *that* to work, ...For diffs to work properly, we need to check the input document and the output document in their entirety, including their signatures. Otherwise, the diffs won't apply correctly when they change the signatures!
But for *that* to work, we need to do what we can to minimize the odds that anybody has a consensus with different signatures, or with signatures organized differently.
As an alternative, we could change the diff format so that it always replaces all the old signatures with the new ones.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21677Prop140: analyze diff performance2020-06-13T15:07:11ZNick MathewsonProp140: analyze diff performanceTor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21694Tor source tarball signed with sha12017-10-25T16:49:13ZcypherpunksTor source tarball signed with sha1$ gpg --verify -v tor-0.2.9.10.tar.gz.asc
gpg: assuming signed data in 'tor-0.2.9.10.tar.gz'
gpg: Signature made Wed 01 Mar 2017 13:09:27 GMT
gpg: using RSA key 6AFEE6D49E92B601
gpg: using subkey 6AFEE6D49E92B601 instead ...$ gpg --verify -v tor-0.2.9.10.tar.gz.asc
gpg: assuming signed data in 'tor-0.2.9.10.tar.gz'
gpg: Signature made Wed 01 Mar 2017 13:09:27 GMT
gpg: using RSA key 6AFEE6D49E92B601
gpg: using subkey 6AFEE6D49E92B601 instead of primary key FE43009C4607B1FB
gpg: using pgp trust model
gpg: Good signature from "Nick Mathewson <nickm@alum.mit.edu>" [unknown]
gpg: aka "Nick Mathewson <nickm@wangafu.net>" [unknown]
gpg: aka "Nick Mathewson <nickm@freehaven.net>" [unknown]
gpg: aka "Nick Mathewson <nickm@torproject.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 2133 BC60 0AB1 33E1 D826 D173 FE43 009C 4607 B1FB
Subkey fingerprint: 7A02 B352 1DC7 5C54 2BA0 1545 6AFE E6D4 9E92 B601
gpg: binary signature, digest algorithm SHA1, key algorithm rsa4096Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21703Warn on getinfo network-status2020-06-13T15:09:55ZNick MathewsonWarn on getinfo network-statusAccordingto control-spec, 'getinfo network-status' is deprecated. We should warn whenever it's requested, so we can finally remove it in good conscience.Accordingto control-spec, 'getinfo network-status' is deprecated. We should warn whenever it's requested, so we can finally remove it in good conscience.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21715Possible error in the Tor manual (section "NumEntryGuards NUM")2020-06-13T15:07:15ZTracPossible error in the Tor manual (section "NumEntryGuards NUM")In both, the Tor -stable Manual and the Tor -alpha Manual, there is a possible error in the section "NumEntryGuards NUM".
Literally, this is the description of the "NumEntryGuards NUM" option: "If UseEntryGuards is set to 1, we will tr...In both, the Tor -stable Manual and the Tor -alpha Manual, there is a possible error in the section "NumEntryGuards NUM".
Literally, this is the description of the "NumEntryGuards NUM" option: "If UseEntryGuards is set to 1, we will try to pick a total of NUM routers as long-term entries for our circuits. If NUM is 0, we try to learn the number from the NumEntryGuards consensus parameter, and default to 3 if the consensus parameter isn’t set. (Default: 0)".
But I think the correct description would be: "If UseEntryGuards is set to 1, we will try to pick a total of NUM routers as long-term entries for our circuits. If NUM is 0, we try to learn the number from the NumEntryGuards consensus parameter, and default to 1 if the consensus parameter isn’t set. (Default: 0)". Because Tor currently chooses a single entry guard, does not choose three.
**Trac**:
**Username**: moe-szyslak-0Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21729make dedicated log file perms less verbose2020-06-13T15:07:17Ztoralfmake dedicated log file perms less verboseI think, that the log file permissions are too weak in moment, this helps:
```
tfoerste@t44 ~/devel/tor $ cat /tmp/log640.patch
diff --git a/src/common/log.c b/src/common/log.c
index 5f7151b..f679336 100644
--- a/src/common/log.c
+++ b/...I think, that the log file permissions are too weak in moment, this helps:
```
tfoerste@t44 ~/devel/tor $ cat /tmp/log640.patch
diff --git a/src/common/log.c b/src/common/log.c
index 5f7151b..f679336 100644
--- a/src/common/log.c
+++ b/src/common/log.c
@@ -1086,7 +1086,7 @@ add_file_log(const log_severity_list_t *severity, const char *filename,
int open_flags = O_WRONLY|O_CREAT;
open_flags |= truncate_log ? O_TRUNC : O_APPEND;
- fd = tor_open_cloexec(filename, open_flags, 0644);
+ fd = tor_open_cloexec(filename, open_flags, 0640);
if (fd<0)
return -1;
if (tor_fd_seekend(fd)<0) {
```Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21737Speed up keccak-tiny: Use a real load64 function2020-06-13T15:07:18ZNick MathewsonSpeed up keccak-tiny: Use a real load64 functionThe current load-le64 function shows up in keccak profiles. Of course, that's silly. We can do better -- and we do, in other crypto primitives.The current load-le64 function shows up in keccak profiles. Of course, that's silly. We can do better -- and we do, in other crypto primitives.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21744Build out glossary in torspec2020-06-13T15:07:19ZChelsea KomloBuild out glossary in torspecThere are a lot of terms defined throughout torspec, but defining common terms in the glossary will hopefully be useful.
Ideas of subsections, how to organize, terms to include, etc are welcome!There are a lot of terms defined throughout torspec, but defining common terms in the glossary will hopefully be useful.
Ideas of subsections, how to organize, terms to include, etc are welcome!Tor: 0.3.1.x-finalChelsea KomloChelsea Komlohttps://gitlab.torproject.org/legacy/trac/-/issues/21750prop224: ntor handshake implementation2020-06-13T15:07:19ZDavid Gouletdgoulet@torproject.orgprop224: ntor handshake implementationTicket created after https://trac.torproject.org/projects/tor/ticket/20657#comment:12
Initial reviews are here: https://gitlab.com/asn/tor/merge_requests/13
OK after a review from David and some comments from Nick I present the `prop22...Ticket created after https://trac.torproject.org/projects/tor/ticket/20657#comment:12
Initial reviews are here: https://gitlab.com/asn/tor/merge_requests/13
OK after a review from David and some comments from Nick I present the `prop224-ntor-v2` branch which comes with all the code review fixes, and with a full on integration test suite similar to the `./src/test/test_ntor.sh` tests for simple ntor.
It also implements the key expansion functionality as requested by David.Tor: 0.3.1.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/21757Using Pluggable Transports on tor master is broken2020-06-13T15:07:20ZGeorg KoppenUsing Pluggable Transports on tor master is brokenWhile testing a patch for #21753 I realized that PTs in general are currently broken with tor master resulting into output like
```
CMETHOD obfs2 socks5 127.0.0.1:41925
CMETHOD obfs3 socks5 127.0.0.1:41299
CMETHOD obfs4 socks5 127.0.0.1:...While testing a patch for #21753 I realized that PTs in general are currently broken with tor master resulting into output like
```
CMETHOD obfs2 socks5 127.0.0.1:41925
CMETHOD obfs3 socks5 127.0.0.1:41299
CMETHOD obfs4 socks5 127.0.0.1:34025
CMETHOD scramblesuit socks5 127.0.0.1:35225
CMETHODS DONE'. We only support version '1'
Mar 16 13:03:05.000 [warn] Managed proxy at './TorBrowser/Tor/PluggableTransports/obfs4proxy' failed the configuration protocol and will be destroyed.
```
if started from Tor Browser.
Bisecting reveals that this got introduced with 6e78ede73f190f3aaf91623a131a20cf031aad7e which fixed #21654.Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21771Cannot change bridge (with Tor 0.3.0.4-rc)2020-06-13T15:07:22ZTracCannot change bridge (with Tor 0.3.0.4-rc)Trying to replace a bridge in torrc (that had been successfully used for a long time) with another one results in many warnings "[warn] Failed to find node for hop 0 of our path. Discarding this circuit.", and failure to connect.
Only w...Trying to replace a bridge in torrc (that had been successfully used for a long time) with another one results in many warnings "[warn] Failed to find node for hop 0 of our path. Discarding this circuit.", and failure to connect.
Only way out found is to edit "state" file and remove the "Guard" line for the previous bridge (with "listed=0"), or come back to previous bridge option in torrc.
I found this while testing further after reporting what I initially thought was a bug in TorBrowser (https://trac.torproject.org/projects/tor/ticket/21768)
**Trac**:
**Username**: torvlnt33rTor: 0.3.1.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/21788Very small memory leak with --verify-config2020-06-13T15:45:05ZJigsaw52Very small memory leak with --verify-configWhen tor is run with the flag --verify-config, there is a memory leak of 45 bytes. Although the leak is insignificant, not leaking any memory helps testing the configuration related code against memory leaks.
This leak is due to clean_u...When tor is run with the flag --verify-config, there is a memory leak of 45 bytes. Although the leak is insignificant, not leaking any memory helps testing the configuration related code against memory leaks.
This leak is due to clean_up_backtrace_handler not being called during tor shutdown process. I believe the fix is calling it inside tor_free_all. I will post a link to a branch with my proposed fix.
Valgrind log:
```
user@lubuntu:~/Desktop/tor$ valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all /usr/local/bin/tor --verify-config
==19135== Memcheck, a memory error detector
==19135== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==19135== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==19135== Command: /usr/local/bin/tor --verify-config
==19135==
Mar 20 00:59:33.916 [notice] Tor 0.3.1.0-alpha-dev (git-411736a13250586c) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g and Zlib 1.2.8.
Mar 20 00:59:34.005 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 20 00:59:34.008 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Mar 20 00:59:34.036 [notice] Read configuration file "/usr/local/etc/tor/torrc".
Configuration was valid
==19135==
==19135== HEAP SUMMARY:
==19135== in use at exit: 45 bytes in 1 blocks
==19135== total heap usage: 8,709 allocs, 8,708 frees, 460,735 bytes allocated
==19135==
==19135== 45 bytes in 1 blocks are still reachable in loss record 1 of 1
==19135== at 0x4C2CB3F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19135== by 0x61CBB4F: __vasprintf_chk (vasprintf_chk.c:80)
==19135== by 0x2669F3: vasprintf (stdio2.h:210)
==19135== by 0x2669F3: tor_vasprintf (compat.c:539)
==19135== by 0x2669F3: tor_asprintf (compat.c:516)
==19135== by 0x2657E1: configure_backtrace_handler (backtrace.c:232)
==19135== by 0x1556AF: tor_main (main.c:3609)
==19135== by 0x14F238: main (tor_main.c:34)
==19135==
==19135== LEAK SUMMARY:
==19135== definitely lost: 0 bytes in 0 blocks
==19135== indirectly lost: 0 bytes in 0 blocks
==19135== possibly lost: 0 bytes in 0 blocks
==19135== still reachable: 45 bytes in 1 blocks
==19135== suppressed: 0 bytes in 0 blocks
==19135==
==19135== For counts of detected and suppressed errors, rerun with: -v
==19135== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
```Tor: 0.3.1.x-finalJigsaw52Jigsaw52https://gitlab.torproject.org/legacy/trac/-/issues/21796missing evutil_secure_rng_add_bytes()2020-06-13T15:07:24Zcypherpunksmissing evutil_secure_rng_add_bytes() CC src/common/compat_libevent.o
src/common/compat_libevent.c:234:3: error: implicit declaration of function
'evutil_secure_rng_add_bytes' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
evutil_secure_rng... CC src/common/compat_libevent.o
src/common/compat_libevent.c:234:3: error: implicit declaration of function
'evutil_secure_rng_add_bytes' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
evutil_secure_rng_add_bytes(buf, 32);
^
src/common/compat_libevent.c:234:3: note: did you mean
'evutil_secure_rng_get_bytes'?
/tmp/include/event2/util.h:808:6: note: 'evutil_secure_rng_get_bytes' declared
here
void evutil_secure_rng_get_bytes(void *buf, size_t n);
^
src/common/compat_libevent.c:234:3: error: this function declaration is not a
prototype [-Werror,-Wstrict-prototypes]
evutil_secure_rng_add_bytes(buf, 32);
^
2 errors generated.
Makefile:4834: recipe for target 'src/common/compat_libevent.o' failed
as of libevent git commit 6541168d7037457b8e5c51cc354f11bd94e618b6, the function evutil_secure_rng_add_bytes() is only exposed for platforms with arc4random_addrandom().Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21823tor FTBFS on clang/i3862020-06-13T15:07:30Zweasel (Peter Palfrader)tor FTBFS on clang/i386https://jenkins.torproject.org/job/tor-ci-linux-master-clang/ARCHITECTURE=i386,SUITE=sid/1905/consoleFull
```
21:22:55 mv -f $depbase.Tpo $depbase.Po
21:22:55 src/common/storagedir.c:209:18: error: implicit conversion loses integer preci...https://jenkins.torproject.org/job/tor-ci-linux-master-clang/ARCHITECTURE=i386,SUITE=sid/1905/consoleFull
```
21:22:55 mv -f $depbase.Tpo $depbase.Po
21:22:55 src/common/storagedir.c:209:18: error: implicit conversion loses integer precision: '__off64_t' (aka 'long long') to 'size_t' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
21:22:55 *sz_out = st.st_size;
21:22:55 ~ ~~~^~~~~~~
21:22:55 1 error generated.
21:22:55 Makefile:4834: recipe for target 'src/common/storagedir.o' failed
21:22:55 make[1]: *** [src/common/storagedir.o] Error 1
```Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21841Refactor: include openssl headers from fewer modules2020-06-13T15:15:07ZNick MathewsonRefactor: include openssl headers from fewer modulesWhen possible, we should make it so that no part of our code other than crypto*.c and tortls*.c actually depend on openssl APIs.When possible, we should make it so that no part of our code other than crypto*.c and tortls*.c actually depend on openssl APIs.Tor: 0.3.1.x-finalNick MathewsonNick Mathewson