Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:00:57Zhttps://gitlab.torproject.org/legacy/trac/-/issues/20042Always log BUG messages from the unit tests2020-06-13T15:00:57ZNick MathewsonAlways log BUG messages from the unit testsOur log_test_helpers.c code is great, but it suppresses log messages that we would like to see!
Also, we should always see BUG messages unless we're specifically suppressing them.
This could be sponsorS (testing) or sponsorU (since I n...Our log_test_helpers.c code is great, but it suppresses log messages that we would like to see!
Also, we should always see BUG messages unless we're specifically suppressing them.
This could be sponsorS (testing) or sponsorU (since I need it to test the link handshake improvements of #15555)Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20041Test failure when running with --debug2020-06-13T15:00:57ZNick MathewsonTest failure when running with --debugOne of the tortls unit tests fails if you run the tests at debug.One of the tortls unit tests fails if you run the tests at debug.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20027Ed25519 certificate parsing does badly with expirations after 20382020-06-13T15:00:53ZNick MathewsonEd25519 certificate parsing does badly with expirations after 2038We deliberately chose an hour-based expiration counter for ed certs, because of 32-bit issues. But when we parse them, we just multiply the 32-bit field by 3600. That results in an overflow if the time is greater than UINT32_MAX.
The ...We deliberately chose an hour-based expiration counter for ed certs, because of 32-bit issues. But when we parse them, we just multiply the 32-bit field by 3600. That results in an overflow if the time is greater than UINT32_MAX.
The impact here isn't too bad. First, it only affects certs that expire after 32-bit signed time overflows in Y2038. Second, it can only make it seem that a non-expired cert is expired: it can never make it seem that an expired cert is still live.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20012Stop upgrading client to intro connections to ntor2020-06-13T15:00:49ZteorStop upgrading client to intro connections to ntorSplit off from #19163, placed in the same milestone.
Clients inadvertently upgrade to ntor when the hidden service descriptor does not have a TAP onion key. This is a client discriminator that can be used by hidden services to discover ...Split off from #19163, placed in the same milestone.
Clients inadvertently upgrade to ntor when the hidden service descriptor does not have a TAP onion key. This is a client discriminator that can be used by hidden services to discover which consensus a client has.
This bug was inadvertently introduced along with ntor in 0.2.4.8-alpha.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/20002Never include non-Valid nodes in consensus.2020-06-13T15:00:45ZNick MathewsonNever include non-Valid nodes in consensus.Right now, we don't include non-Running nodes. Let's make it so we never include non-Valid nodes either.Right now, we don't include non-Running nodes. Let's make it so we never include non-Valid nodes either.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/20001Infer running and valid from presence in consensus2020-06-13T15:00:45ZNick MathewsonInfer running and valid from presence in consensusWe no longer include in the consensus any non-running nodes.
We are no longer _supposed_ to include in the consensus any non-Valid nodes.
Let us update Tor to infer these flags as true from their presence in the consensus. This could ...We no longer include in the consensus any non-running nodes.
We are no longer _supposed_ to include in the consensus any non-Valid nodes.
Let us update Tor to infer these flags as true from their presence in the consensus. This could work with prop#266 as another means to kill off obsolete clients.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19977testsuite fails on mips, powerpc, s390x2020-06-13T15:00:34Zweasel (Peter Palfrader)testsuite fails on mips, powerpc, s390xAccording to https://buildd.debian.org/status/package.php?p=tor&suite=experimental, tor fails on several architectures.
It might be a big-endian issue.
```
shared-random/encoding: [forking]
FAIL ../src/test/test_shared_random.c:409:...According to https://buildd.debian.org/status/package.php?p=tor&suite=experimental, tor fails on several architectures.
It might be a big-endian issue.
```
shared-random/encoding: [forking]
FAIL ../src/test/test_shared_random.c:409: assert(hashed_rand OP_EQ parsed_commit.random_number): 30920FF41C187DFCBE96E453A0885E3B956B9EEB18C3A15D2EE1D0858ECC3CDB vs 24F71F644E3890594AA31F048010E74F01F09ABAB5E08CFCB5EF74B3623782DA
[encoding FAILED]
```Tor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/19973ReachableAddresses applied too broadly2020-06-13T15:00:33ZNick MathewsonReachableAddresses applied too broadlyThe ReachableAddresses filter should only apply when picking a first node. But in 268608c in #17840 , it began to apply to the whole path.
This is bad for path selection, in proportion to the restrictiveness of your ReachableAddresses f...The ReachableAddresses filter should only apply when picking a first node. But in 268608c in #17840 , it began to apply to the whole path.
This is bad for path selection, in proportion to the restrictiveness of your ReachableAddresses filter. It's probably not a hard break, but it's important to fix.
Teor found this issue and wrote a patch for it. It should go into an 028 release.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19958Implement proposal 264 (protocol versioning)2020-06-13T15:03:40ZNick MathewsonImplement proposal 264 (protocol versioning)This is not 100% strictly necessary for #15055 to work, but every time we change a protocol, we will wish that we had included this feature.
Mostly implemented in a fit of C while I was on vacation.This is not 100% strictly necessary for #15055 to work, but every time we change a protocol, we will wish that we had included this feature.
Mostly implemented in a fit of C while I was on vacation.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19947NULL %s in fmt string (dir_server_new() - routerlist.c)2020-06-13T15:00:23ZTracNULL %s in fmt string (dir_server_new() - routerlist.c)in src/or/routerlist.c:4545-4550 `hostname` passed to tor_asprintf() can be NULL such as when dir_server_new() is called from fallback_dir_server_new()
Found this because recent OpenBSD -current whinges about it in syslog:
tor: vfp...in src/or/routerlist.c:4545-4550 `hostname` passed to tor_asprintf() can be NULL such as when dir_server_new() is called from fallback_dir_server_new()
Found this because recent OpenBSD -current whinges about it in syslog:
tor: vfprintf %s NULL in "directory server at %s:%d"
last message repeated 88 times
**Trac**:
**Username**: rubiateTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19923Upgrade Hidden Service circuits to ntor using keys from the consensus2020-06-13T15:00:17ZteorUpgrade Hidden Service circuits to ntor using keys from the consensusSplit off #17178 and #19163, depends on both.
Single Onion Services build a one-hop path to the client-provided rendezvous point. This circuit is only secured using SSL and TAP, as the INTRODUCE cell only contains TAP onion keys.
But i...Split off #17178 and #19163, depends on both.
Single Onion Services build a one-hop path to the client-provided rendezvous point. This circuit is only secured using SSL and TAP, as the INTRODUCE cell only contains TAP onion keys.
But in most cases, the Single Onion Service can look up the ntor onion key for the rendezvous point in the consensus, and therefore it can upgrade to ntor. (If it doesn't find the rendezvous point in the consensus, it simply continues with TAP.)
My suggested solution is to replace the entire rendezvous point extend_info with the extend_info from the consensus (if found). We should do this for both clients and services, whether using Single Onion Services or Tor2web or not (to avoid introducing new fingerprinting mechanisms).https://gitlab.torproject.org/legacy/trac/-/issues/19905make-test-network-all has never detected IPv6 on linux2020-06-13T15:00:14Zteormake-test-network-all has never detected IPv6 on linuxWhen I wrote make-test-network-all, I tested IPv6 on OS X and BSD.
But it's never worked on Linux.
On BSD and OS X systems, we use:
`ping6 -q -c 1 -o ::1`
On Linux systems, we should use:
`ping6 -q -c 1 -W 1 ::1`
You'd think we could ...When I wrote make-test-network-all, I tested IPv6 on OS X and BSD.
But it's never worked on Linux.
On BSD and OS X systems, we use:
`ping6 -q -c 1 -o ::1`
On Linux systems, we should use:
`ping6 -q -c 1 -W 1 ::1`
You'd think we could get away with:
`ping6 -q -c 1 ::1`
but BSD / OS X would hang forever on systems where IPv6 packets are dropped, and Linux is somewhat ambiguous about what happens in that case.
Over the long term, implementing checks like this in chutney might be a better idea.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/19904evutil_secure_rng_add_bytes() not present in openbsd libevent 22020-06-13T15:00:14ZNick Mathewsonevutil_secure_rng_add_bytes() not present in openbsd libevent 2For decent reasons, OpenBSD removes evutil_secure_rng_add_bytes(). But now that Tor requires Libevent 2, Tor should detect this absence and not call evutil_secure_rng_add_bytes() if it isn't there.For decent reasons, OpenBSD removes evutil_secure_rng_add_bytes(). But now that Tor requires Libevent 2, Tor should detect this absence and not call evutil_secure_rng_add_bytes() if it isn't there.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19903tor_tls_get_by_ssl is declared non-inline, then inline.2020-06-13T15:00:13ZNick Mathewsontor_tls_get_by_ssl is declared non-inline, then inline.In tortls.h, we declare tor_tls_by_ssl as non-inline. But in tortls.c, we declare it inline. This bugs the version of GCC that OpenBSD uses, and wasn't our intention.In tortls.h, we declare tor_tls_by_ssl as non-inline. But in tortls.c, we declare it inline. This bugs the version of GCC that OpenBSD uses, and wasn't our intention.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19901ENABLE_GCC_WARNING is broken on GCC < 4.62020-06-13T15:00:12ZNick MathewsonENABLE_GCC_WARNING is broken on GCC < 4.6I'm doing a fix. Creating a placeholder.I'm doing a fix. Creating a placeholder.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19896Write a quick how-to for ht.h2020-06-13T15:00:10ZNick MathewsonWrite a quick how-to for ht.hGeorge wanted some tips about using ht.h. But he's not around IRC. I'll braindump here instead.George wanted some tips about using ht.h. But he's not around IRC. I'll braindump here instead.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19872Introduce prefixed sign/verify functions2020-06-13T14:59:59ZGeorge KadianakisIntroduce prefixed sign/verify functionsprop224 wants us to sign messages prefixed with a constant string. For example:
```
SIG is a signature, using AUTH_KEY, of all contents of the cell, up
to but not including SIG. These contents are prefixed with the string
"Tor ...prop224 wants us to sign messages prefixed with a constant string. For example:
```
SIG is a signature, using AUTH_KEY, of all contents of the cell, up
to but not including SIG. These contents are prefixed with the string
"Tor establish-intro cell v1".
```
dgoulet also has plans for adding a prefix to the signature of the HS descriptor.
So, it would be ideal if we had some crypto util functions that will do that for us. We are talking about two functions called `ed25519_sign_prefixed()` and `ed25519_checksig_prefixed()` that are basically wrappers over `ed25519_sign()` and `ed25519_checksig()` that also accept a `const char *prefix_str`.
If we have these functions in upstream tor, it will be easier for us to write code for the various prop224 subsystems that need to be implemented.Tor: 0.2.9.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/19820Add deprecation facility, and deprecate some old options2020-06-13T14:59:53ZNick MathewsonAdd deprecation facility, and deprecate some old optionsTor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19728Pick, and deploy, a new bridge authority2020-06-13T14:59:40ZRoger DingledinePick, and deploy, a new bridge authorityWe are losing Tonga at the end of August (#19690). That means we should spin up a new bridge authority.
What are the criteria we should be considering, for the operator, location, etc of this bridge authority? To answer that, I think we...We are losing Tonga at the end of August (#19690). That means we should spin up a new bridge authority.
What are the criteria we should be considering, for the operator, location, etc of this bridge authority? To answer that, I think we should start by brainstorming all of the risks that we should consider.
So: what are we trusting the bridge authority for? Related, what does the bridge authority see? And what does an adversary watching the bridge authority see?
First, it sees the unscrubbed bridge data, i.e. the IP addresses, usage stats, fingerprints, etc of bridges. I think this is the same as what bridgedb sees, but more detailed than what onionoo serves. We rely on the bridge authority to have high security so bad people can't break in and steal the bridge addresses (that's number 7 on https://blog.torproject.org/blog/research-problems-ten-ways-discover-tor-bridges).
Second, the bridge authority does bridge reachability tests. So somebody who watches its network connection gets to learn bridge addresses too. (Bridges use Tor, and encrypted begindir connections, to *publish* their descriptors to the bridge authority, so you can't learn about them that way.) This part is probably a design flaw, in that it's a shame we have centralized the reachability testing; but we don't have a better design for that currently, so it remains an issue here. (This is number eight on the blog post above.)
Third, it *used* to be the case, in the original design, that the bridge authority needs to have really high reliability and bandwidth. That requirement was because users were expected to go back to the bridge authority quite frequently, to see if their bridges have changed location. The original idea was that users would get n bridges, and over time k of them would move locations or something, and so long as at least 1 of the n remained working, the Tor client could automatically discover the new bridge locations by fetching updated bridge descriptors from Tonga. But we basically stopped building the bridge design before we got that part working, so it isn't really an issue here.
Fourth (added based on Sebastian's comment below), we are relying on the bridge authority to have a consistent IP address for a very long time, since bridges upload their descriptors using this address. That is, I think it is the case that changing its IP address is effectively the same as picking a new bridge authority?
What other constraints/risks/goals did I miss?Tor: 0.2.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/19690Tonga (Bridge Authority) Permanent Shutdown Notice2021-03-27T04:55:11ZshamrockTonga (Bridge Authority) Permanent Shutdown NoticeDear friends,
Given recent events, it is no longer appropriate for me to materially contribute to the Tor Project either financially, as I have so generously throughout the years, nor by providing computing resources. This decision does...Dear friends,
Given recent events, it is no longer appropriate for me to materially contribute to the Tor Project either financially, as I have so generously throughout the years, nor by providing computing resources. This decision does not come lightly; I probably ran one of the first five nodes in the system and my involvement with Tor predates it being called "Tor" by many years.
Nonetheless, I feel that I have no reasonable choice left within the bounds of ethics, but to announce the discontinuation of all Tor-related services hosted on every system under my control.
Most notably, this includes the Tor node "Tonga", the "Bridge Authority", which I recognize is rather pivotal to the network
Tonga will be permanently shut down and all associated crytographic keys destroyed on 2016-08-31. This should give the Tor developers ample time to stand up a substitute. I will terminate the chron job we set up so many years ago at that time that copies over the descriptors.
In addition to Tonga, I will shut down a number of fast Tor relays, but the directory authorities should detect that shutdown quickly and no separate notice is needed here.
I wish the Tor Project nothing but the best moving forward through those difficult times,
--LuckyTor: 0.2.8.x-finalIsis LovecruftIsis Lovecruft