The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:00:29Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17262Experimental simulation prototype for guard selection algorithm2020-06-27T14:00:29ZNick MathewsonExperimental simulation prototype for guard selection algorithmThis is an end-of-october deliverable. Let's take the results of legacy/trac#17261 and make them into a python prototype that we can run experiments on. Forcing us to be concrete in this way will help us get a better plan.This is an end-of-october deliverable. Let's take the results of legacy/trac#17261 and make them into a python prototype that we can run experiments on. Forcing us to be concrete in this way will help us get a better plan.Tor: unspecifiedNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17261Formalize our best-guess guard algorithm2020-06-27T14:00:29ZNick MathewsonFormalize our best-guess guard algorithmWe've made lots of progress in this area but final conclusions seem to elude us. Goal: Figure out what our very best idea is now, and write it down in a single document. Due: end of october.We've made lots of progress in this area but final conclusions seem to elude us. Goal: Figure out what our very best idea is now, and write it down in a single document. Due: end of october.Tor: 0.2.8.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/17260Triage all items for 0.2.82020-06-27T14:00:29ZNick MathewsonTriage all items for 0.2.8Target date: 15 October 2015.
Remaining steps are:
* Make sure that every item on the roadmaps has a corresponding ticket.
* Prioritize items, under the assumption we can't possibly do them all so we'll probably need to aim for the ...Target date: 15 October 2015.
Remaining steps are:
* Make sure that every item on the roadmaps has a corresponding ticket.
* Prioritize items, under the assumption we can't possibly do them all so we'll probably need to aim for the really critical ones first.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17259Release 0.2.7.5-stable if possible2020-06-27T14:00:29ZNick MathewsonRelease 0.2.7.5-stable if possibleI'm planning to do this around the start of november, give or take.I'm planning to do this around the start of november, give or take.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17258Release 0.2.7.4-rc2020-06-27T14:00:29ZNick MathewsonRelease 0.2.7.4-rcWe should do another RC this month.We should do another RC this month.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17255get_ifaddrs_* unti tests assume an IPv4 address is configured2020-06-27T14:00:29Zteorget_ifaddrs_* unti tests assume an IPv4 address is configuredget_ifaddrs_* unti tests assume an IPv4 address is configured, but when my Wifi is off, that isn't true.
It's best not to assume much, so the tor unit tests can run on networkless boxes.
This needs a backport to 0.2.7.get_ifaddrs_* unti tests assume an IPv4 address is configured, but when my Wifi is off, that isn't true.
It's best not to assume much, so the tor unit tests can run on networkless boxes.
This needs a backport to 0.2.7.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17254Scalable HSes by splitting intro/rendezvous2022-10-11T23:40:45ZTvdWScalable HSes by splitting intro/rendezvousasn suggested creating a ticket before the proposal is committed, so here I go.
Most relevant mail from the thread (contains the proposal): https://lists.torproject.org/pipermail/tor-dev/2015-October/009625.htmlasn suggested creating a ticket before the proposal is committed, so here I go.
Most relevant mail from the thread (contains the proposal): https://lists.torproject.org/pipermail/tor-dev/2015-October/009625.htmlTor: unspecifiedTvdWTvdWhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17253Revise tests in test_tortls.c to not act intrusively on openssl internals2021-09-16T14:34:34ZNick MathewsonRevise tests in test_tortls.c to not act intrusively on openssl internalsWith openssl 1.1, most openssl structures will become opaque. But the new unit tests in test_tortls.c assume that they have full access to openssl internals.
I've wrapped the tests that make this assumption inside `#ifndef OPENSSL_OPAQ...With openssl 1.1, most openssl structures will become opaque. But the new unit tests in test_tortls.c assume that they have full access to openssl internals.
I've wrapped the tests that make this assumption inside `#ifndef OPENSSL_OPAQUE`, so that Tor will build with openssl 1.1 again. But it would be great to see if we can port some of these tests to work with openssl 1.1, or at least disable the problematic parts on a more fine-grained basis.https://gitlab.torproject.org/tpo/core/tor/-/issues/17251warning in test_crypto_slow.c2020-06-27T14:00:30ZNick Mathewsonwarning in test_crypto_slow.c```
src/test/test_crypto_slow.c: In function ‘test_libscrypt_eq_openssl’:
src/test/test_crypto_slow.c:220:28: error: integer overflow in expression [-Werror=overflow]
maxmem = 2 * 1024 * 1024 * 1024; // 2 GB
``````
src/test/test_crypto_slow.c: In function ‘test_libscrypt_eq_openssl’:
src/test/test_crypto_slow.c:220:28: error: integer overflow in expression [-Werror=overflow]
maxmem = 2 * 1024 * 1024 * 1024; // 2 GB
```Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17242prop224: Implement client support2020-06-27T14:00:30ZDavid Gouletdgoulet@torproject.orgprop224: Implement client supportThis ticket is the parent one for anything related to client implementation for proposal 224.
As we break down functionalities and needed features, we'll add more child tickets.This ticket is the parent one for anything related to client implementation for proposal 224.
As we break down functionalities and needed features, we'll add more child tickets.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17241prop224: Implement relay side support2020-06-27T14:00:30ZDavid Gouletdgoulet@torproject.orgprop224: Implement relay side supportImplement the support for RP and IP that is new cell format and ntor handshake. This would be support of 224 only on the relay side for communication between nodes.Implement the support for RP and IP that is new cell format and ntor handshake. This would be support of 224 only on the relay side for communication between nodes.Tor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/17240Refactor the HS code to support both current and proposal 224 design2021-09-16T14:35:00ZDavid Gouletdgoulet@torproject.orgRefactor the HS code to support both current and proposal 224 designThis is an important task since we need both system to live in parallel for multiple years and before we start the heart of the work on proposal 224, we need to accomodate the code so we avoid huge amount of code duplication.
Would be a...This is an important task since we need both system to live in parallel for multiple years and before we start the heart of the work on proposal 224, we need to accomodate the code so we avoid huge amount of code duplication.
Would be also a good opportunity to add unit tests while doing so!
Here are some notes on a possible start up point to refactor: https://people.torproject.org/~dgoulet/hs224-refactor.txthttps://gitlab.torproject.org/tpo/core/tor/-/issues/17239Implement new key blinding scheme for proposal 2242020-06-27T14:00:30ZDavid Gouletdgoulet@torproject.orgImplement new key blinding scheme for proposal 224For next generation hidden service, we need to implement the key blinding scheme and the use of ed25519 keys by the service.
In other word, implement the new keying scheme for hidden service.For next generation hidden service, we need to implement the key blinding scheme and the use of ed25519 keys by the service.
In other word, implement the new keying scheme for hidden service.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17238prop224: Implement HSDir support2020-06-27T14:00:30ZDavid Gouletdgoulet@torproject.orgprop224: Implement HSDir supportThis is part of the grand proposal 224. The task here is to implement the new descriptor format, HSDir caching for store/lookup and make sure relay can serve them. Note that this ticket does NOT require the client and service to support ...This is part of the grand proposal 224. The task here is to implement the new descriptor format, HSDir caching for store/lookup and make sure relay can serve them. Note that this ticket does NOT require the client and service to support the new descriptor format. This is only on the relay side.Tor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/17237TLS compilation warnings and unit test failures2020-06-27T14:00:31ZteorTLS compilation warnings and unit test failuresHave these been fixed?
```
CC src/test/src_test_test-test_tortls.o
src/test/test_tortls.c:1394:32: warning: unused variable 'wbuf_c'
[-Wunused-variable]
size_t rbuf_c=-1, rbuf_b=-1, wbuf_c=-1, wbuf_b=-1;
...Have these been fixed?
```
CC src/test/src_test_test-test_tortls.o
src/test/test_tortls.c:1394:32: warning: unused variable 'wbuf_c'
[-Wunused-variable]
size_t rbuf_c=-1, rbuf_b=-1, wbuf_c=-1, wbuf_b=-1;
^
src/test/test_tortls.c:1394:21: warning: unused variable 'rbuf_b'
[-Wunused-variable]
size_t rbuf_c=-1, rbuf_b=-1, wbuf_c=-1, wbuf_b=-1;
^
src/test/test_tortls.c:1394:43: warning: unused variable 'wbuf_b'
[-Wunused-variable]
size_t rbuf_c=-1, rbuf_b=-1, wbuf_c=-1, wbuf_b=-1;
^
src/test/test_tortls.c:1394:10: warning: unused variable 'rbuf_c'
[-Wunused-variable]
size_t rbuf_c=-1, rbuf_b=-1, wbuf_c=-1, wbuf_b=-1;
```
```
tortls/shutdown:
FAIL src/test/test_tortls.c:1988: assert(ret OP_EQ TOR_TLS_DONE): -8 vs 0
[shutdown FAILED]
tortls/renegotiate: OK
tortls/finish_handshake: OK
tortls/handshake: OK
tortls/write: OK
tortls/read:
FAIL src/test/test_tortls.c:2106: assert(ret OP_EQ TOR_TLS_CLOSE): -8 vs -3
[read FAILED]
tortls/server_info_callback: OK
tortls/is_server: OK
tortls/assert_renegotiation_unblocked: Oct 06 04:19:17.673 [err] void tor_assertion_failed_(const char *, unsigned int, const char *, const char *): Bug: src/common/tortls.c:1761: tor_tls_assert_renegotiation_unblocked: Assertion 0 != (options & SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION) failed; aborting. (on Tor 0.2.8.0-alpha-dev 2ac5e5f61742738a)
Oct 06 04:19:17.673 [err] Bug: Assertion 0 != (options & SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION) failed in tor_tls_assert_renegotiation_unblocked at src/common/tortls.c:1761. Stack trace: (on Tor 0.2.8.0-alpha-dev 2ac5e5f61742738a)
Oct 06 04:19:17.673 [err] Bug: 0 test 0x002b0e84 log_backtrace + 68 (on Tor 0.2.8.0-alpha-dev 2ac5e5f61742738a)
Oct 06 04:19:17.673 [err] Bug: 1 test 0x002bf077 tor_assertion_failed_ + 183 (on Tor 0.2.8.0-alpha-dev 2ac5e5f61742738a)
Oct 06 04:19:17.673 [err] Bug: 2 test 0x002db2ad tor_tls_assert_renegotiation_unblocked + 93 (on Tor 0.2.8.0-alpha-dev 2ac5e5f61742738a)
Oct 06 04:19:17.673 [err] Bug: 3 test 0x00156076 test_tortls_assert_renegotiation_unblocked + 70 (on Tor 0.2.8.0-alpha-dev 2ac5e5f61742738a)
Oct 06 04:19:17.673 [err] Bug: 4 test 0x0019f44a testcase_run_one + 442 (on Tor 0.2.8.0-alpha-dev 2ac5e5f61742738a)
Oct 06 04:19:17.673 [err] Bug: 5 test 0x0019fb88 tinytest_main + 584 (on Tor 0.2.8.0-alpha-dev 2ac5e5f61742738a)
Oct 06 04:19:17.673 [err] Bug: 6 test 0x0019ef23 main + 675 (on Tor 0.2.8.0-alpha-dev 2ac5e5f61742738a)
Oct 06 04:19:17.673 [err] Bug: 7 libdyld.dylib 0x922416d9 start + 1 (on Tor 0.2.8.0-alpha-dev 2ac5e5f61742738a)
FAIL src/test/test (exit status: 134)
```Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17235Merge prop 210 changes for #4483 and #157752020-06-27T14:00:31ZteorMerge prop 210 changes for #4483 and #15775I significantly modified prop 210 while implementing legacy/trac#4483 and legacy/trac#15775.
This ticket exists to remind us to edit and merge the latest branch for the proposal along with the code changes.
It's at https://github.com/t...I significantly modified prop 210 while implementing legacy/trac#4483 and legacy/trac#15775.
This ticket exists to remind us to edit and merge the latest branch for the proposal along with the code changes.
It's at https://github.com/teor2345/torspec.git and the name is something like bootstrap-exponential-backoff-vN.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17233MinMeasuredBWsForAuthToIgnoreAdvertised should be lower for Testing networks?2021-06-18T18:15:52ZRoger DingledineMinMeasuredBWsForAuthToIgnoreAdvertised should be lower for Testing networks?```
config.c: V(MinMeasuredBWsForAuthToIgnoreAdvertised, INT, "500"),
```
weasel points out that maybe this should be 0 for testing tor networks?```
config.c: V(MinMeasuredBWsForAuthToIgnoreAdvertised, INT, "500"),
```
weasel points out that maybe this should be 0 for testing tor networks?https://gitlab.torproject.org/tpo/core/tor/-/issues/17230Local DNS resolver will not resolve AAAA records with fc00::/8 prefixes.2022-06-17T18:57:41ZTracLocal DNS resolver will not resolve AAAA records with fc00::/8 prefixes.When using the DNS resolver configured using the DNSPort directive, AAAA records using fc00::/8 prefixes are not returned. This interferes with the proper resolution of hosts using [cjdns](https://github.com/cjdelisle/cjdns) addresses, w...When using the DNS resolver configured using the DNSPort directive, AAAA records using fc00::/8 prefixes are not returned. This interferes with the proper resolution of hosts using [cjdns](https://github.com/cjdelisle/cjdns) addresses, which are typically specified using h.domain.tld addresses.
[Example](http://pastie.org/private/3ote0ky6lfzmkp4tcnwfbg)
**Trac**:
**Username**: JacobHennerhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17226Vague description for HS_DESC's new CREATED2020-06-27T14:00:31ZDamian JohnsonVague description for HS_DESC's new CREATEDOur recent torspec merge expands HS_DESC events with a CREATED action and Replica field. This is well and good, but the only description of it is...
```
If Action is "CREATED", Tor SHOULD send Replica field as well. The Replica
field co...Our recent torspec merge expands HS_DESC events with a CREATED action and Replica field. This is well and good, but the only description of it is...
```
If Action is "CREATED", Tor SHOULD send Replica field as well. The Replica
field contains the replica number of the generated descriptor.
```
This isn't enough for me to know either what the action means or what the Replica count is. At a guess maybe it means "I've created a new unpublished hidden service descriptor about myself, and am about to upload it to <replica> HSDirs"? Just a guess.
We should update this event to better describe the new additions.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17225Merge NS_EXPIRY_SLOP and REASONABLY_LIVE_TIME2021-09-16T14:35:00ZteorMerge NS_EXPIRY_SLOP and REASONABLY_LIVE_TIMEThese are now the same value (24 hours) so they can be merged into a common header, and the relevant comments removed.These are now the same value (24 hours) so they can be merged into a common header, and the relevant comments removed.