The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:02:36Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13061Explore for ways to split dirauths from regular relays2020-06-27T14:02:36ZSebastian HahnExplore for ways to split dirauths from regular relaysThis is an old plan, but it requires significant effort. It would be good if we could split the dirauth-relevant parts from Tor such that it isn't required to run a relay and Tor client for the dirauth functioniality.
High-level ticket ...This is an old plan, but it requires significant effort. It would be good if we could split the dirauth-relevant parts from Tor such that it isn't required to run a relay and Tor client for the dirauth functioniality.
High-level ticket for SponsorZhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13060Remove the ability to mark relays as Bad directories2020-06-27T14:02:36ZSebastian HahnRemove the ability to mark relays as Bad directoriesWe've never used the feature according to arma, and while it doesn't add much complexity, it wouldn't hurt to get rid of it.We've never used the feature according to arma, and while it doesn't add much complexity, it wouldn't hurt to get rid of it.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13059Create bad-relays file2022-06-17T13:43:15ZSebastian HahnCreate bad-relays fileIn the wake of legacy/trac#12899, it became apparent that redoing the approved-routers file is a good idea. It'll be replaced by a torrc-style file called bad-relays.In the wake of legacy/trac#12899, it became apparent that redoing the approved-routers file is a good idea. It'll be replaced by a torrc-style file called bad-relays.https://gitlab.torproject.org/tpo/core/tor/-/issues/13054[warn] Invalid result from curve25519 handshake: 42020-06-27T14:02:36ZRoger Dingledine[warn] Invalid result from curve25519 handshake: 4I get this on the moriatoo relay, which is running git master and is also hooked up to a bwauth.
The messages around it are:
```
Sep 04 03:21:11.000 [warn] Invalid result from curve25519 handshake: 4
Sep 04 03:21:11.000 [warn] onion_ski...I get this on the moriatoo relay, which is running git master and is also hooked up to a bwauth.
The messages around it are:
```
Sep 04 03:21:11.000 [warn] Invalid result from curve25519 handshake: 4
Sep 04 03:21:11.000 [warn] onion_skin_client_handshake failed.
Sep 04 03:21:11.000 [warn] circuit_finish_handshake failed.
```
It actually happens not infrequently, so it's not just a one-off thing.
The code is
```
if (bad) {
log_warn(LD_PROTOCOL, "Invalid result from curve25519 handshake: %d", bad);
}
```
and I think 4 shows up when
```
bad |= (tor_memneq(s.auth, auth_candidate, DIGEST256_LEN) << 2);
```
So I guess the first issue is that "4" is really not a helpful error message for me.
The second issue is to wonder what's gone wrong and whether there's a deeper bug.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13043torspec lies about accepting both IPv4 and IPv6 for ORAddress lines2020-06-27T14:02:36ZIsis Lovecrufttorspec lies about accepting both IPv4 and IPv6 for ORAddress lines(From [this comment on #9380](https://trac.torproject.org/projects/tor/ticket/9380#comment:27))
**tl;dr**: The `"a"`/`"or-address"` lines, _in implementation_, only happen once each per router, and only ever contain IPv6 addresses, desp...(From [this comment on #9380](https://trac.torproject.org/projects/tor/ticket/9380#comment:27))
**tl;dr**: The `"a"`/`"or-address"` lines, _in implementation_, only happen once each per router, and only ever contain IPv6 addresses, despite what `dir-spec.txt` says.
The spec [says](https://gitweb.torproject.org/torspec.git/blob/d4cb76a81f26dcc41a2c2041b12977dfdf62c3f8:/dir-spec.txt#l1166):
```
"a" SP address ":" port NL
[Any number]
The "or-address" element as specified in section 2.1.1.
```
[and](https://gitweb.torproject.org/torspec.git/blob/d4cb76a81f26dcc41a2c2041b12977dfdf62c3f8:/dir-spec.txt#l587):
```
"or-address" SP ADDRESS ":" PORT NL
[Any number]
ADDRESS = IP6ADDR | IP4ADDR
IPV6ADDR = an ipv6 address, surrounded by square brackets.
IPV4ADDR = an ipv4 address, represented as a dotted quad.
PORT = a number between 1 and 65535 inclusive.
An alternative for the address and ORPort of the "router" line, but with
two added capabilities:
* or-address can be either an IPv4 or IPv6 address
* or-address allows for multiple ORPorts and addresses
A descriptor SHOULD NOT include an or-address line that does nothing but
duplicate the address:port pair from its "router" line.
The ordering of or-address lines and their PORT entries matter because
Tor MAY accept a limited number of addresses or ports. As of Tor 0.2.3.x
only the first address and the first port are used.
```
- In terms of how many `"a"`/`"or-address"` lines there may be, the spec is only correct if you pay _super close attention to the last sentence_ (this is actually the first time I've noticed it :) ).
- In terms of whether IPv4 and/or IPv6 addresses are acceptable, _the spec is currently wrong_, according to the functions `router_rebuild_descriptor()` [https://gitweb.torproject.org/tor.git/blob/9f9b19ed7b06d8313a9bcbd6647fa097ec0a059d:/src/or/router.c#l1811 [source]] and `router_dump_router_to_string()` [https://gitweb.torproject.org/tor.git/blob/9f9b19ed7b06d8313a9bcbd6647fa097ec0a059d:/src/or/router.c#l2330 [source]] in `src/or/router.c` in tor's source code.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13042torspec isn't very clear about the encodings used for `onion-key` and `signin...2020-06-27T14:02:36ZIsis Lovecrufttorspec isn't very clear about the encodings used for `onion-key` and `signing-key`Currently, in `dir-spec.txt`, it is specified that:
```
"signing-key" NL a public key in PEM format
[Exactly once]
The OR's long-term identity key. It MUST be 1024 bits.
```
and
```
"onion-key" NL a public key...Currently, in `dir-spec.txt`, it is specified that:
```
"signing-key" NL a public key in PEM format
[Exactly once]
The OR's long-term identity key. It MUST be 1024 bits.
```
and
```
"onion-key" NL a public key in PEM format
[Exactly once]
This key is used to encrypt CREATE cells for this OR. The key MUST be
accepted for at least 1 week after any new key is published in a
subsequent descriptor. It MUST be 1024 bits.
```
However, according to [this commit](https://gitweb.torproject.org/stem.git/commitdiff/e0095fbe54759c45cbf6d1b120d2b17b47a0ec21) added to Stem in legacy/trac#5810, verifying signatures created with the `signing-key` isn't so easy. With that code, Stem is able to verify descriptor signatures created by Tor, yet not [those created by Leekspin](https://gitweb.torproject.org/user/isis/leekspin.git/blob/HEAD:/leekspin/generator.py#l89), which clearly means the spec is unclear on this matter (and Leekspin is Doing It Wrong).
My current understanding after looking at `crypto_pk_public_checksig()` in Tor, the OpenSSL source, and Stem's signature verification code above is that the `signing-key` and `onion-key` are formatted as follows:
1. OpenSSL PEM-encoded export of public halves of keys.
2. The PEM-encoded keys are stripped of their `----BEGIN...` and `-----END...` headers.
3. The keys are then PKCS!#1 padded.
4. Next, the PKCS!#1-padded, PEM-encoded raw keys are encoded as an ASN.1 DER sequence.
5. That ASN.1 DER sequence is then base64 encoded.
6. Finally, the `-----BEGIN...` and `-----END...` headers are stuck back on the keys, and they are shoved into the descriptor.
Questions:
* Is the above understanding of the order of encodings correct?
* Which version of PCKS!#1? Any version? Anything newer than v1.5? Only v2.0?
* I understand the use of PKCS!#1 to protect against padding attacks, but doesn't [Bleichenbacher's attack](https://en.wikipedia.org/wiki/Adaptive_chosen-ciphertext_attack#Practical_attacks) still work against PKCS!#1 v1.0?
* Why aren't we using the PKCS!#1 probabilistic signature schemes (RSASSA-PSS/EMSA-PSS) used in PKCS!#1 v2.0?
* For the signatures, the descriptor document "through the newline on the `router-signature` line" is PKCS!#1-padded, then digested. Does this include the newline character?
* Also, the spec is unclear as to whether
1. the ''descriptor document'' is PKCS!#1-padded, then digested, then signed,
or
2. the descriptor document is digested, then signed, and the ''signature'' is PKCS!#1-padded.
{{{
"router-signature" NL Signature NL
[At end, exactly once]
The "SIGNATURE" object contains a signature of the PKCS1-padded
hash of the entire router descriptor, taken from the beginning of the
"router" line, through the newline after the "router-signature" line.
The router descriptor is invalid unless the signature is performed
with the router's identity key.
}}}
* Is it any specific type of ASN.1 DER sequence?
* Why are we using ASN.1? Does it protect against something? It just seems to send parsers to early graves. Why can't we just do the base64 encoding after PKCS!#1?
* _Why? Oh why? Cthulhu fhtagn... Why? The insanity..._Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13037compile time option to not read config from sysconfdir2020-06-27T14:02:37Zweasel (Peter Palfrader)compile time option to not read config from sysconfdirAIUI, right now tor will read /etc/tor/torrc and /etc/tor/torrc-defaults (or /usr/local/etc/tor/...) when started as any user, if they exist and aren't overridden on the command line. (Other conditionals may apply.)
I'd like a compile ...AIUI, right now tor will read /etc/tor/torrc and /etc/tor/torrc-defaults (or /usr/local/etc/tor/...) when started as any user, if they exist and aren't overridden on the command line. (Other conditionals may apply.)
I'd like a compile time option that would stop tor reading any global configuration/defaults files. If no ~/.torrc exists and no configuration file is passed on the command line it should instead just use its built-in defaults.
That way, users running tor under their own user won't get interfered with /etc/tor/torrc settings. The init script can continue to pass /etc/tor/torrc to the tor binary on the command line.
Cheers,Tor: 0.2.6.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/13036Uninitialised Variable & NULL Pointer Dereference Warnings in Clang2020-06-27T14:02:37ZteorUninitialised Variable & NULL Pointer Dereference Warnings in Clangclang and clang --analyze produces around 10 uninitialised variable and NULL pointer dereference warnings when compiling tor from git source on OS X.
Some of these warnings may be incorrect, but I've checked the context of the warnings,...clang and clang --analyze produces around 10 uninitialised variable and NULL pointer dereference warnings when compiling tor from git source on OS X.
Some of these warnings may be incorrect, but I've checked the context of the warnings, and the logic that ensures each variable is valid isn't obvious to me (or clang). But I might be missing something.
The attached patches resolve these warnings by initialising the variables, and / or asserting valid values before variables are read.
These warnings occur in the git source of tor 0.2.6.0?-alpha around 1 September 2014
e.g. commit 67c0ad54263be7fb742a8d499f97f5908f9ec970Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13000Should relays wait with publishing a descriptor until they've run a bw self-t...2024-03-12T12:51:19ZSebastian HahnShould relays wait with publishing a descriptor until they've run a bw self-test?Otherwise the first descriptor will be published using an observed bw of 0. This at least throws the bwauths off, but maybe more weird stuff happens? Is it useful at all to ever publish a descriptor with observed bw 0?Otherwise the first descriptor will be published using an observed bw of 0. This at least throws the bwauths off, but maybe more weird stuff happens? Is it useful at all to ever publish a descriptor with observed bw 0?Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12997More specific warning than "Tried to establish rendezvous on non-OR or non-ed...2020-06-27T14:02:37ZNick MathewsonMore specific warning than "Tried to establish rendezvous on non-OR or non-edge circuit."```
15:57 < nickm> might be fun to split that clause into the non-or and n_chan
case, and log the circuit purpose in the former?
15:59 < armadev> yes
``````
15:57 < nickm> might be fun to split that clause into the non-or and n_chan
case, and log the circuit purpose in the former?
15:59 < armadev> yes
```Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12996Relay operators see "Unexpected onionskin length after decryption: 58"2020-06-27T14:02:37ZRoger DingledineRelay operators see "Unexpected onionskin length after decryption: 58"We've had one or two reports lately of people seeing
```
[warn] Unexpected onionskin length after decryption: 58
```
in their logs.
It basically means that some client sent the relay a malformed (too short) create cell.
It's possible ...We've had one or two reports lately of people seeing
```
[warn] Unexpected onionskin length after decryption: 58
```
in their logs.
It basically means that some client sent the relay a malformed (too short) create cell.
It's possible that this is a bug in our Tor client code, but I think it's more likely that somebody else is working on a Tor client, and has a bug in their code.
Since there isn't really much the relay operator can do about it, we should probably downgrade the warning to a protocol-warn.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12990route certificate errors2020-06-27T14:02:37ZGriffin Boyceroute certificate errorsSo on August 17th, I experienced a weird error and haven't noticed it since, but thought I'd try to determine the cause. I was using the latest TBB (3.6.4) on Ubuntu 14.04 x64. Figure this was just an uber glitch, but wanted to report ...So on August 17th, I experienced a weird error and haven't noticed it since, but thought I'd try to determine the cause. I was using the latest TBB (3.6.4) on Ubuntu 14.04 x64. Figure this was just an uber glitch, but wanted to report it just in case it happens for someone else also:
```
Aug 17 00:45:22.000 [warn] Tried connecting to router at 185.13.39.135:443, but identity key was not as expected: wanted 2F7C841C58F475EDE7C5D69393D07617BF387E99 but got 4279541B61CD552B3E63D53C4857F59FFB45CE4A.
```
Full session below:
```
griffin@mercurius:~/Downloads/tor-browser_en-US$ ./start-tor-browser
Launching Tor Browser Bundle for Linux in /home/griffin/Downloads/tor-browser_en-US
(process:29067): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
(firefox:29067): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
(firefox:29067): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised
(firefox:29067): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised
(firefox:29067): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised
(firefox:29067): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised
Aug 17 00:43:30.909 [notice] Tor v0.2.4.23 (git-a9ea51dc0bd48126) running on Linux with Libevent 2.0.21-stable and OpenSSL 1.0.1i.
Aug 17 00:43:30.910 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Aug 17 00:43:30.910 [notice] Read configuration file "/home/griffin/Downloads/tor-browser_en-US/Data/Tor/torrc-defaults".
Aug 17 00:43:30.910 [notice] Read configuration file "/home/griffin/Downloads/tor-browser_en-US/Data/Tor/torrc".
Aug 17 00:43:30.916 [notice] Opening Socks listener on 127.0.0.1:9150
Aug 17 00:43:30.916 [notice] Opening Control listener on 127.0.0.1:9151
Aug 17 00:43:30.000 [notice] Pluggable transport proxy (fte exec ./Tor/PluggableTransports/fteproxy.bin --managed) does not provide any needed transports and will not be launched.
Aug 17 00:43:30.000 [notice] Pluggable transport proxy (obfs2,obfs3 exec ./Tor/PluggableTransports/obfsproxy.bin managed) does not provide any needed transports and will not be launched.
Aug 17 00:43:30.000 [notice] Pluggable transport proxy (flashproxy exec ./Tor/PluggableTransports/flashproxy-client --register :0 :9000) does not provide any needed transports and will not be launched.
Aug 17 00:43:30.000 [notice] Parsing GEOIP IPv4 file /home/griffin/Downloads/tor-browser_en-US/Data/Tor/geoip.
Aug 17 00:43:30.000 [notice] Parsing GEOIP IPv6 file /home/griffin/Downloads/tor-browser_en-US/Data/Tor/geoip6.
Aug 17 00:43:31.000 [notice] We now have enough directory information to build circuits.
Aug 17 00:43:31.000 [notice] Bootstrapped 80%: Connecting to the Tor network.
Aug 17 00:43:31.000 [notice] New control connection opened.
Aug 17 00:43:31.000 [notice] Pluggable transport proxy (fte exec ./Tor/PluggableTransports/fteproxy.bin --managed) does not provide any needed transports and will not be launched.
Aug 17 00:43:31.000 [notice] Pluggable transport proxy (obfs2,obfs3 exec ./Tor/PluggableTransports/obfsproxy.bin managed) does not provide any needed transports and will not be launched.
Aug 17 00:43:31.000 [notice] Pluggable transport proxy (flashproxy exec ./Tor/PluggableTransports/flashproxy-client --register :0 :9000) does not provide any needed transports and will not be launched.
Aug 17 00:43:31.000 [notice] New control connection opened.
Aug 17 00:43:31.000 [notice] Bootstrapped 85%: Finishing handshake with first hop.
Aug 17 00:43:32.000 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Aug 17 00:43:33.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Aug 17 00:43:33.000 [notice] Bootstrapped 100%: Done.
Aug 17 00:43:34.000 [notice] New control connection opened.
Aug 17 00:45:22.000 [warn] Tried connecting to router at 185.13.39.135:443, but identity key was not as expected: wanted 2F7C841C58F475EDE7C5D69393D07617BF387E99 but got 4279541B61CD552B3E63D53C4857F59FFB45CE4A.
Aug 17 00:45:27.000 [warn] Tried connecting to router at 77.109.141.139:443, but identity key was not as expected: wanted 527ED954F9E7800AB00BCE366542CB074B42DD2A but got 4279541B61CD552B3E63D53C4857F59FFB45CE4A.
Aug 17 00:45:29.000 [warn] Tried connecting to router at 5.34.183.205:443, but identity key was not as expected: wanted DDD7871C1B7FA32CB55061E08869A236E61BDDF8 but got 4279541B61CD552B3E63D53C4857F59FFB45CE4A.
Aug 17 00:45:30.000 [warn] Tried connecting to router at 88.198.100.230:443, but identity key was not as expected: wanted 093E76DE8EF51256E0FDC51B41237989ADA4AC2E but got 4279541B61CD552B3E63D53C4857F59FFB45CE4A.
Aug 17 00:45:31.000 [warn] Tried connecting to router at 5.39.80.135:443, but identity key was not as expected: wanted AB73816E5D7BC52664CBB9D005FF579BAFEAFE87 but got 4279541B61CD552B3E63D53C4857F59FFB45CE4A.
Aug 17 00:45:34.000 [warn] Tried connecting to router at 86.59.119.83:443, but identity key was not as expected: wanted FC9AC8EA0160D88BCCFDE066940D7DD9FA45495B but got 4279541B61CD552B3E63D53C4857F59FFB45CE4A.
Aug 17 00:45:35.000 [warn] Tried connecting to router at 62.210.84.20:443, but identity key was not as expected: wanted 5A16F7E31B26F286889F20027F57A5E253AF3F23 but got 4279541B61CD552B3E63D53C4857F59FFB45CE4A.
Aug 17 00:45:38.000 [warn] Tried connecting to router at 96.44.189.102:443, but identity key was not as expected: wanted 3B486DEC5A22694C0960B4A97A3665C617C89B1C but got 4279541B61CD552B3E63D53C4857F59FFB45CE4A.
Aug 17 00:45:38.000 [warn] Tried connecting to router at 188.165.138.55:443, but identity key was not as expected: wanted 95A3BC167A575964F40F251B850ABB47960A530D but got 4279541B61CD552B3E63D53C4857F59FFB45CE4A.
Aug 17 00:47:02.000 [warn] Tried connecting to router at 62.210.82.177:443, but identity key was not as expected: wanted 7663AD93B561AA11F40982BBDB3D3063AD28E3C7 but got 4279541B61CD552B3E63D53C4857F59FFB45CE4A.
Aug 17 00:47:04.000 [notice] Owning controller connection has closed -- exiting now.
Tor Browser exited cleanly.
griffin@mercurius:~/Downloads/tor-browser_en-US$ cd
```Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12985call tor_event_free, not tor_free, on events in connection_free().2020-06-27T14:02:38ZNick Mathewsoncall tor_event_free, not tor_free, on events in connection_free().In `connection_free_`, we do a probably-redundant call to tor_free on conn->read_event and conn->write_event.
This tor_free() is redundant (as we note in a comment) whenever we're calling `connection_free_` from `connection_free`. But ...In `connection_free_`, we do a probably-redundant call to tor_free on conn->read_event and conn->write_event.
This tor_free() is redundant (as we note in a comment) whenever we're calling `connection_free_` from `connection_free`. But in one case -- the case where we're running connection_free_all -- we might get into trouble. We could free the event without first running event_del() on it.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12981Add backends for encrypted storage, scrypt2020-06-27T14:02:38ZNick MathewsonAdd backends for encrypted storage, scryptWe need an encrypted storage format for private keys that is better than openssl's armor, once we start storing ed25519 private keys (optionally encrypted).
We should also use a better passphrase-based-key-derivation function than we ha...We need an encrypted storage format for private keys that is better than openssl's armor, once we start storing ed25519 private keys (optionally encrypted).
We should also use a better passphrase-based-key-derivation function than we have now. scrypt isn't my favorite, but until the PHC is done, it's probably a good choice.
Once those are in, we can use scrypt in place of our current openpgp RFC2440 password-to-key function.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12980Implement ed25519 primitives for proposals 220, 224, 2282020-06-27T14:02:38ZNick MathewsonImplement ed25519 primitives for proposals 220, 224, 228For proposal 220, we need ed25519 with detached signatures. (legacy/trac#12498)
For proposal 224 (legacy/trac#12424), we need ed25519 with key blinding (legacy/trac#8106).
For proposal 228, we need the ability to convert curve25519 key...For proposal 220, we need ed25519 with detached signatures. (legacy/trac#12498)
For proposal 224 (legacy/trac#12424), we need ed25519 with key blinding (legacy/trac#8106).
For proposal 228, we need the ability to convert curve25519 keys to ed25519 keys. (legacy/trac#12499)Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12971Invalid SOCKS5 response to UDP associate request2020-06-27T14:02:38Zyurivict271Invalid SOCKS5 response to UDP associate requestThe attached script sends UDP ASSOCIATE request to tor socks5 server. It gets two bytes in response:
$ ./testcase.py
>> 05 03 00 01 08 08 08 08 00 35
<< 05 00
As per RFC 1928, this response is invalid. Only 2 bytes out of 10 expected by...The attached script sends UDP ASSOCIATE request to tor socks5 server. It gets two bytes in response:
$ ./testcase.py
>> 05 03 00 01 08 08 08 08 00 35
<< 05 00
As per RFC 1928, this response is invalid. Only 2 bytes out of 10 expected bytes are in response (see Section 6: Replies). Subsection "UDP ASSOCIATE" there says "In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR fields indicate the port number/address where the client MUST send UDP request messages to be relayed."
Tor sends back only two fields: 05 (version), 00 (Reply field=succeeded), and nothing else. It should either send ip/port in a full reply, or (maybe) 05 01 (error response).Tor: 0.2.6.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/12970dir-spec's a-line shouldn't mention portlists2020-06-27T14:02:38ZDamian Johnsondir-spec's a-line shouldn't mention portlistsReally quick thing [spotted by joelanders](https://trac.torproject.org/projects/tor/ticket/9380#comment:24). The dir-spec's [description of an a-line](https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1591) says...
```
...Really quick thing [spotted by joelanders](https://trac.torproject.org/projects/tor/ticket/9380#comment:24). The dir-spec's [description of an a-line](https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1591) says...
```
Address and portlist are as for "or-address" as specified in
section 2.1.1.
```
Unless I'm missing something this (and or-address) only accept a single address:port, not a list of ports.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12955New tests for routerset.c2020-06-27T14:02:38ZTracNew tests for routerset.cNew tests are attached for routerset.c that are in the same style as introduced in legacy/trac#11507. This provides a 100% coverage test suite for this module.
**Trac**:
**Username**: _x3j11New tests are attached for routerset.c that are in the same style as introduced in legacy/trac#11507. This provides a 100% coverage test suite for this module.
**Trac**:
**Username**: _x3j11Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12951BridgeAuth should add a `published` line to bridge networkstatus documents2020-06-27T14:02:38ZIsis LovecruftBridgeAuth should add a `published` line to bridge networkstatus documents[While hacking](https://trac.torproject.org/projects/tor/ticket/9380) on getting BridgeDB to use Stem's descriptor parsers, I noticed that `@type bridge-network-status 1.0` documents do not have a `published` line, like other networkstat...[While hacking](https://trac.torproject.org/projects/tor/ticket/9380) on getting BridgeDB to use Stem's descriptor parsers, I noticed that `@type bridge-network-status 1.0` documents do not have a `published` line, like other networkstatus documents. I proposed that a new `@type bridge-network-status 1.1` descriptor type is created, where Bridge Authorities add a `published` line to the head of the document.
Related: legacy/trac#12254Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12948TBB Linux 4.0-Alpha-1 HashedControlPassword not working2020-06-27T14:02:39ZTracTBB Linux 4.0-Alpha-1 HashedControlPassword not workingOn TBB 4.0-Alpha Linux 64-bit when trying to connect to the control port with the password of "secret" I get the following error: "515 Authentication failed: Password did not match HashedControlPassword *or* authentication cookie."
In s...On TBB 4.0-Alpha Linux 64-bit when trying to connect to the control port with the password of "secret" I get the following error: "515 Authentication failed: Password did not match HashedControlPassword *or* authentication cookie."
In start-tor-browser script file, line 225 "unset TOR_CONTROL_PASSWD" this leaves the control password blank. Every time I start TBB the HashedControlPassword is different.
When setting TOR_CONTROL_PASSWD in the terminal, TBB fails to start. Error message is: "[warn] Bad password or authentication cookie on controller."
When setting TOR_CONTROL_PASSWD in start-tor-browser script file the same error message is reported "[warn] Bad password or authentication cookie on controller."
When manually setting HashedControlPassword in torrc, tor ignored it and sometimes changed it.
All errors happened on a clean/brand new Linux Mint 64-bit Virtual Machine.
**Trac**:
**Username**: vis15Tor: 0.2.5.x-finalIsis LovecruftIsis Lovecruft