Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:07:19Zhttps://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/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/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/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/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/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/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/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/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/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/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/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/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/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/21663prop278: Refactor the torgzip module to support additional compression schemes2020-06-13T15:07:06ZAlexander Færøyahf@torproject.orgprop278: Refactor the torgzip module to support additional compression schemesThe current torgzip module should be refactored such that the new compression schemes needed for prop#278 can fit nicely into the code.
This is the tracking bug for this task.The current torgzip module should be refactored such that the new compression schemes needed for prop#278 can fit nicely into the code.
This is the tracking bug for this task.Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21662prop278: Add support for LZMA2 and/or Zstandard2020-06-13T15:07:06ZAlexander Færøyahf@torproject.orgprop278: Add support for LZMA2 and/or ZstandardAdd support for the compression schemes needed to implement prop#278.
See: http://facebook.github.io/zstd/ and http://7-zip.org/sdk.html for the respective libraries.Add support for the compression schemes needed to implement prop#278.
See: http://facebook.github.io/zstd/ and http://7-zip.org/sdk.html for the respective libraries.Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21654Don't use fgets() when we might get EAGAIN2020-06-13T15:09:26ZNick MathewsonDon't use fgets() when we might get EAGAINOur tor_fgets() code, added in #20988, tries to make fgets() behave as we expect with nonblocking sockets. But really, fgets() is not such a great choice for nonblocking sockets in the first place! Let's use direct fd-level IO for thos...Our tor_fgets() code, added in #20988, tries to make fgets() behave as we expect with nonblocking sockets. But really, fgets() is not such a great choice for nonblocking sockets in the first place! Let's use direct fd-level IO for those instead.Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21651prop140/compression: Refactor directory cache spooling code2020-06-13T15:07:03ZNick Mathewsonprop140/compression: Refactor directory cache spooling codeOur current logic for spooling things from a directory server is a bit loopy. Instead we should refactor it so that "things to be spooled" is a first-class object, with implementations depending on what we're spooling. This will make l...Our current logic for spooling things from a directory server is a bit loopy. Instead we should refactor it so that "things to be spooled" is a first-class object, with implementations depending on what we're spooling. This will make lots of our directory improvement stuff easier to implement.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21650prop140: Clients request diffs and handle diffs in replies2020-06-13T15:07:02ZNick Mathewsonprop140: Clients request diffs and handle diffs in repliesFor the final piece of prop140, clients should ask for consensus diffs as appropriate, and handle them if they're received.
We may need proposal extensions here:
* Should clients begin doing this immediately, or should there be a tris...For the final piece of prop140, clients should ask for consensus diffs as appropriate, and handle them if they're received.
We may need proposal extensions here:
* Should clients begin doing this immediately, or should there be a tristate where "default" means "look at the consensus"?
* Should there be an option -- maybe for testing, maybe not -- that forces clients to look for directory guards that support consensus diffs?Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21649prop140: Caches serve diffs on request2020-06-13T15:07:02ZNick Mathewsonprop140: Caches serve diffs on requestWhen a client asks for it, caches should serve consensus diffs.
We'll want to integrate this with the new compression logic that ahf is proposing.When a client asks for it, caches should serve consensus diffs.
We'll want to integrate this with the new compression logic that ahf is proposing.Tor: 0.3.1.x-finalNick MathewsonNick Mathewson