The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-09-16T14:33:04Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20853rend_config_services should use service_is_ephemeral rather than old/new->dir...2021-09-16T14:33:04Zteorrend_config_services should use service_is_ephemeral rather than old/new->directoryWe missed this in the earlier refactor.
(Does that make it a bug? I think so.)We missed this in the earlier refactor.
(Does that make it a bug? I think so.)Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20827Record guards' ed25519 identities2022-06-17T17:46:16ZNick MathewsonRecord guards' ed25519 identitieshttps://gitlab.torproject.org/tpo/core/tor/-/issues/20719prop271 -- make parameters configurable2020-06-27T13:57:45ZNick Mathewsonprop271 -- make parameters configurableTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20692risky duplicate code in rend_config_services()2020-06-27T13:57:47ZRoger Dingledinerisky duplicate code in rend_config_services()In rend_config_services(), we have a loop over options->RendConfigLines, and one of the things it does is:
```
if (service) { /* register the one we just finished parsing */
if (rend_service_check_private_dir(options, servi...In rend_config_services(), we have a loop over options->RendConfigLines, and one of the things it does is:
```
if (service) { /* register the one we just finished parsing */
if (rend_service_check_private_dir(options, service, 0) < 0) {
rend_service_free(service);
return -1;
}
if (validate_only)
rend_service_free(service);
else
rend_add_service(service);
}
```
Then once the loop is finished, it proceeds to call
```
if (service) {
if (rend_service_check_private_dir(options, service, 0) < 0) {
rend_service_free(service);
return -1;
}
if (validate_only) {
rend_service_free(service);
} else {
rend_add_service(service);
}
}
```
Look familiar? This duplication is going to bite us when somebody changes one part but not the other.
Found while looking at legacy/trac#20638.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20684DIRCACHE_MIN_MB_BANDWIDTH is actually used for RAM2020-06-27T13:57:47ZteorDIRCACHE_MIN_MB_BANDWIDTH is actually used for RAMWe should change DIRCACHE_MIN_BANDWIDTH and DIRCACHE_MIN_MB_BANDWIDTH to end in *_MEM, as they are only ever used for memory, not bandwidth.
Introduced in commit 997f779 in tor-0.2.8.1-alpha.We should change DIRCACHE_MIN_BANDWIDTH and DIRCACHE_MIN_MB_BANDWIDTH to end in *_MEM, as they are only ever used for memory, not bandwidth.
Introduced in commit 997f779 in tor-0.2.8.1-alpha.Tor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/20667Make FetchUselessDescriptors fetch all consensus flavours2020-06-27T13:57:47ZteorMake FetchUselessDescriptors fetch all consensus flavours`FetchUselessDescriptors 1` used to imply `UseMicrodescriptors 0`, but due to legacy/trac#6769, it doesn't in 0.3.0 and later.
Therefore, clients that want to download a full consensus have to explictly set `UseMicrodescriptors 0`.
~~W...`FetchUselessDescriptors 1` used to imply `UseMicrodescriptors 0`, but due to legacy/trac#6769, it doesn't in 0.3.0 and later.
Therefore, clients that want to download a full consensus have to explictly set `UseMicrodescriptors 0`.
~~We should document this in the man page and probably the changelog summary, as~~ it is a breaking change for many configs that used to obtain a full consensus.
~~(Alternately,~~ we could fix this bug by FetchUselessDescriptors download a full consensus, even on clients, and document that behaviour.)
Discovered when running a test bandwidth authority - see legacy/trac#20621.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20653Test targets should gracefully handle missing dependencies2021-06-18T18:09:39ZChelsea KomloTest targets should gracefully handle missing dependenciesTest targets should be able to gracefully handle situations where Stem, Chutney or Perl (in the case of check-spaces and check-docs) are not available.
Currently none of these targets do this and just fail by either exiting with exit co...Test targets should be able to gracefully handle situations where Stem, Chutney or Perl (in the case of check-spaces and check-docs) are not available.
Currently none of these targets do this and just fail by either exiting with exit code 1 or simply running non-existing commands (which leads to the same result).https://gitlab.torproject.org/tpo/core/tor/-/issues/20634Unit test address/get_if_addrs6_list_no_internal should succeed if there are ...2020-06-27T13:57:49ZteorUnit test address/get_if_addrs6_list_no_internal should succeed if there are only internal addressesSplit off legacy/trac#19960:
It is ok for the log message generated by address/get_if_addrs6_list_no_internal to be either:
* "connect() failed", or
* "unable to create socket", or
* "Address that we determined via UDP socket magic is u...Split off legacy/trac#19960:
It is ok for the log message generated by address/get_if_addrs6_list_no_internal to be either:
* "connect() failed", or
* "unable to create socket", or
* "Address that we determined via UDP socket magic is unsuitable for public comms."
But we don't currently allow the third option.
```
address/get_if_addrs6_list_no_internal: [forking]
FAIL src/test/test_address.c:850: expected log to contain "connect() failed" o
r "unable to create socket" Captured logs:
1. err: "Address that we determined via UDP socket magic is unsuitable for p
ublic comms.\n"
[get_if_addrs6_list_no_internal FAILED]
```Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20625When a consensus doesn't have enough signatures, write it (and sigs) to a file2021-06-18T18:09:39ZteorWhen a consensus doesn't have enough signatures, write it (and sigs) to a fileJust like we write 'unparseable-desc' and 'v3-status-votes' to a file, it would be great to write 'unpublished[-flavour]-consensus' to a file, when we log this message:
```
Nov 10 21:00:01.000 [warn] A consensus needs 5 good signatures ...Just like we write 'unparseable-desc' and 'v3-status-votes' to a file, it would be great to write 'unpublished[-flavour]-consensus' to a file, when we log this message:
```
Nov 10 21:00:01.000 [warn] A consensus needs 5 good signatures from recognized authorities for us to accept it. This one has 4 (...). 4 (...) of the authorities we know didn't sign it.
Nov 10 21:00:01.000 [warn] Not enough info to publish pending ns consensus
```
Similarly, when we disagree about signatures, we should write 'unpublished-[-flavour]-signatures', when we log this message:
```
Nov 10 21:27:32.000 [warn] Problem adding detached signatures from <redacted-address-and-port>: Mismatched digest.
```
(Or, even better, write both matching and mismatching signatures to the file.)
One catch:
These new filenames need to be added to the sandbox.https://gitlab.torproject.org/tpo/core/tor/-/issues/20611Relays should log a message when they return a 503 error to a client2020-06-27T13:57:50ZteorRelays should log a message when they return a 503 error to a clientA relay operator is concerned that their relay is returning 503 errors, but there are no corresponding errors in the logs.A relay operator is concerned that their relay is returning 503 errors, but there are no corresponding errors in the logs.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20581warning: 'enc_b64_blob' may be used uninitialized in this function2020-06-27T13:57:52ZTracwarning: 'enc_b64_blob' may be used uninitialized in this functionI'm seeing:
src/or/hs_descriptor.c: In function 'desc_encode_v3':
src/or/hs_descriptor.c:787: warning: 'enc_b64_blob' may be used uninitialized in this function
It looks like any situation where enc_b64_blob doesn't get initial...I'm seeing:
src/or/hs_descriptor.c: In function 'desc_encode_v3':
src/or/hs_descriptor.c:787: warning: 'enc_b64_blob' may be used uninitialized in this function
It looks like any situation where enc_b64_blob doesn't get initialised it also doesn't get used, and clang doesn't complain, so I think this is just OpenBSD's old gcc being silly but could it be initialised to make it happy?
```
diff --git a/src/or/hs_descriptor.c b/src/or/hs_descriptor.c
index 7c5d204..bc72034 100644
--- a/src/or/hs_descriptor.c
+++ b/src/or/hs_descriptor.c
@@ -784,7 +784,7 @@ desc_encode_v3(const hs_descriptor_t *desc, char **encoded_out)
/* Build the encrypted data section. */
{
- char *enc_b64_blob;
+ char *enc_b64_blob = NULL;
if (encode_encrypted_data(desc, &enc_b64_blob) < 0) {
goto err;
}
```
(I didn't want to make a new ticket for this but trac wouldn't let me post it on legacy/trac#18571, sorry)
**Trac**:
**Username**: rubiateTor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20568Move encode_cert() from hs_descriptor.c into torcert.c2021-09-16T14:33:04ZDavid Gouletdgoulet@torproject.orgMove encode_cert() from hs_descriptor.c into torcert.cGive it a better name, maybe improve the code to be a bit more generic and start using it in router.c at minimum.Give it a better name, maybe improve the code to be a bit more generic and start using it in router.c at minimum.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20567hs: Document arguments of rend_data_service_create() and rend_data_client_cre...2020-06-27T13:57:54ZDavid Gouletdgoulet@torproject.orghs: Document arguments of rend_data_service_create() and rend_data_client_create()Title says it all. We need much more details on those important functions. Let's make it happen for 030.Title says it all. We need much more details on those important functions. Let's make it happen for 030.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20509Directory authorities should reject relays with #20499 bug2020-06-27T13:57:57ZRoger DingledineDirectory authorities should reject relays with #20499 bugOnce we resolve legacy/trac#20499, or more precisely, once we figure out which versions it affects, we should teach the directory authorities to withhold the Guard flag from relays that are running those versions.
Right now you can't bo...Once we resolve legacy/trac#20499, or more precisely, once we figure out which versions it affects, we should teach the directory authorities to withhold the Guard flag from relays that are running those versions.
Right now you can't bootstrap from e.g. sofia, which is a huge guard running 0.2.9.3-alpha.
Then later -- or maybe this will turn out to be the easiest solution for everything -- we can teach the directory authorities to simply reject descriptors from relays running these buggy versions.
[I'm not sure which milestone to put this in, since it will need to get into a majority of directory authorities for it to matter. :/ ]Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20492Tor git version is not generated in git worktrees2020-06-27T13:57:58ZteorTor git version is not generated in git worktreesWhen I compile tor on macOS, it doesn't log the git version on startup:
```
Oct 29 01:27:48.261 [notice] Tor 0.3.0.0-alpha-dev running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
```
This happens regardless of ...When I compile tor on macOS, it doesn't log the git version on startup:
```
Oct 29 01:27:48.261 [notice] Tor 0.3.0.0-alpha-dev running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
```
This happens regardless of compiler and architecture:
gcc (MacPorts gcc49 4.9.4_0+universal) 4.9.4 (i386/x86_64)
clang version 3.9.0 (tags/RELEASE_390/final) (x86_64)
$ git --version
git version 2.10.1
But when I compile it on Linux, I see a git commit hash:
```
Oct 28 14:28:15.669 [notice] Tor 0.3.0.0-alpha-dev (git-f3e158edf7d8128d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g and Zlib 1.2.8.
```
Compiler:
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
$ git --version
git version 2.6.3.36.g9a8c740
I'm putting this in 0.3.0 because it makes diagnosing issues much easier if we have the full commit. But feel free to disagree.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20488Nickname registration message is confusing2020-06-27T13:57:58ZteorNickname registration message is confusingtoralf says:
```
wrt to this syslog massage : "You specified a server "zwiebeltoralf" by name, but the directory authorities do not have any key registered for this nickname" - how can I register my nickname ?
```
We should change th...toralf says:
```
wrt to this syslog massage : "You specified a server "zwiebeltoralf" by name, but the directory authorities do not have any key registered for this nickname" - how can I register my nickname ?
```
We should change this message to be clearer, particularly because we don't use the Named/Unnamed flags any more.
We could just say "don't have any relay for this nickname".Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20486HiddenServiceDirectory is created if it doesn't exist2021-07-22T16:22:54ZteorHiddenServiceDirectory is created if it doesn't existSplit off legacy/trac#20484
* Update the man page, which incorrectly says that HiddenServiceDirectory must exist - tor creates the HiddenServiceDirectory if it doesn't existSplit off legacy/trac#20484
* Update the man page, which incorrectly says that HiddenServiceDirectory must exist - tor creates the HiddenServiceDirectory if it doesn't existTor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20474Tor should try harder to choose nodes in small networks2020-06-27T13:57:59ZteorTor should try harder to choose nodes in small networksIn https://trac.torproject.org/projects/tor/ticket/14881#comment:58 , pastly reports that in networks without bandwidth weights, tor says:
> Oct 26 19:56:00.000 [warn] Failed to find node for hop 1 of our path. Discarding this circuit.
...In https://trac.torproject.org/projects/tor/ticket/14881#comment:58 , pastly reports that in networks without bandwidth weights, tor says:
> Oct 26 19:56:00.000 [warn] Failed to find node for hop 1 of our path. Discarding this circuit.
We should fix this at some point by falling back to choosing a random node.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20469Expose predicted-ports state over the control port2023-09-13T17:23:57ZRoger DingledineExpose predicted-ports state over the control portWhile debugging legacy/trac#19969 I wanted to ask my Tor whether it had any predicted ports in its internal state. But I think there is no way to ask it? I would like a 'getinfo predicted-ports' or the like.While debugging legacy/trac#19969 I wanted to ask my Tor whether it had any predicted ports in its internal state. But I think there is no way to ask it? I would like a 'getinfo predicted-ports' or the like.https://gitlab.torproject.org/tpo/core/tor/-/issues/20435Update tor man page with AuthDirGuardBWGuarantee of 2 MBytes2021-07-22T16:23:16ZteorUpdate tor man page with AuthDirGuardBWGuarantee of 2 MBytesBugfix on ticket legacy/trac#12690, commit a57c07b in tor-0.2.5.6-alpha.
~~There is no tor-0.2.5.6-alpha in the versions list, see legacy/trac#20434.~~Bugfix on ticket legacy/trac#12690, commit a57c07b in tor-0.2.5.6-alpha.
~~There is no tor-0.2.5.6-alpha in the versions list, see legacy/trac#20434.~~Tor: 0.3.0.x-final