The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-09-16T14:23:38Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31176Teach practracker about .may_include files2021-09-16T14:23:38ZNick MathewsonTeach practracker about .may_include filesWe would like to introduce a second category of .may_include rules: those that should only apply on an advisory basis. We would treat violations of these rules as a best practices violation rather than an error. It would allow us to st...We would like to introduce a second category of .may_include rules: those that should only apply on an advisory basis. We would treat violations of these rules as a best practices violation rather than an error. It would allow us to start ratcheting down the number of layering violations.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30780Return a distinct was_router_added_t when formatting annotations fails2021-09-16T14:23:38ZteorReturn a distinct was_router_added_t when formatting annotations failsThere's a note in dirserv_add_multiple_descriptors() that this is bad.
But no-one ever fixed it.There's a note in dirserv_add_multiple_descriptors() that this is bad.
But no-one ever fixed it.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31698Reconsider HAVE_XXX_H usage in the Tor code2021-09-16T14:22:37ZAlexander Færøyahf@torproject.orgReconsider HAVE_XXX_H usage in the Tor codeWe currently sometimes have code like:
```
#ifdef HAVE_STRING_H
# include <string.h>
#endif
```
But we don't expect to work on systems that do not have, for example, string.h available. We should not do these check in every .c and .h ...We currently sometimes have code like:
```
#ifdef HAVE_STRING_H
# include <string.h>
#endif
```
But we don't expect to work on systems that do not have, for example, string.h available. We should not do these check in every .c and .h file, but instead just have our configure script fail if these headers are not available.https://gitlab.torproject.org/tpo/core/tor/-/issues/31589hs-v3: Simplify decrypt_desc_layer interface2021-09-16T14:22:37ZGeorge Kadianakishs-v3: Simplify decrypt_desc_layer interfaceHere is how `decrypt_desc_layer` is called:
```
superencrypted_len = decrypt_desc_layer(desc,
desc->plaintext_data.superencrypted_blob,
desc->plaintext_data.superencrypt...Here is how `decrypt_desc_layer` is called:
```
superencrypted_len = decrypt_desc_layer(desc,
desc->plaintext_data.superencrypted_blob,
desc->plaintext_data.superencrypted_blob_size,
NULL, 1, &superencrypted_plaintext);
```
```
encrypted_len = decrypt_desc_layer(desc,
desc->superencrypted_data.encrypted_blob,
desc->superencrypted_data.encrypted_blob_size,
descriptor_cookie, 0, &encrypted_plaintext);
```
There is no point in passing `desc->superencrypted_data.encrypted_blob` and `desc->superencrypted_data.encrypted_blob_size` since we are already passing the whole `desc` and `is_superencrypted_layer` which should be enough to figure out which fields to use.
We could either of the following two things:
- Ditch `desc` as an argument and pass `desc->plaintext_data.blinded_pubkey` explicitly.
- Ditch `encrypted_blob` and `encrypted_blob_size` as arguments and get them off desc.
I prefer the first, but I'm fine with either, since it will make the interface cleaner.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31477Practracker integration tests for headers and includes2021-09-16T14:22:37ZNick MathewsonPractracker integration tests for headers and includesWe added new practracker features in legacy/trac#31175 and legacy/trac#31176, but those were written before practracker had integration tests (legacy/trac#31263). We should add them to the practracker tests.We added new practracker features in legacy/trac#31175 and legacy/trac#31176, but those were written before practracker had integration tests (legacy/trac#31263). We should add them to the practracker tests.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31476Practracker: document new features2021-09-16T14:22:37ZNick MathewsonPractracker: document new featuresOn 31176, asn notes:
>We should update the file-level comment of practracker.py to mention that we are now checking for include dependecies too. Same goes for the header of exceptions.txt .
>
>And maybe it's time to make a small README ...On 31176, asn notes:
>We should update the file-level comment of practracker.py to mention that we are now checking for include dependecies too. Same goes for the header of exceptions.txt .
>
>And maybe it's time to make a small README file to specify all the metrics that practracker is currently looking for, before they become too many?
This is a good ideaTor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32994Get all flag defaults from port_cfg_new()2021-09-16T14:22:17ZteorGet all flag defaults from port_cfg_new()The Tor port flags code is needlessly complex. To change a default, you need to change:
* port_cfg_new()
* port_parse_config()
* connection_listener_new()
We should call port_cfg_new() for the defaults in all these cases.The Tor port flags code is needlessly complex. To change a default, you need to change:
* port_cfg_new()
* port_parse_config()
* connection_listener_new()
We should call port_cfg_new() for the defaults in all these cases.Tor: 0.4.4.x-finalMrSquancheeMrSquancheehttps://gitlab.torproject.org/tpo/core/tor/-/issues/32814Move V3AuthUseLegacyKey into dirauth module2021-09-16T14:22:17ZNick MathewsonMove V3AuthUseLegacyKey into dirauth moduleThis option is also used in router.c, where maybe it should not be.This option is also used in router.c, where maybe it should not be.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30309Rename tor_mem_is_zero to fast_mem_is_zero; use it consistently2021-09-16T14:19:58ZNick MathewsonRename tor_mem_is_zero to fast_mem_is_zero; use it consistentlyBy convention, tor_memeq() means "constant time" and fast_memeq() means "variable-time." But tor_mem_is_zero is variable-time, whereas its constant-time variant is safe_mem_is_zero.
I'm fine with the "safe_" name, but we should rename ...By convention, tor_memeq() means "constant time" and fast_memeq() means "variable-time." But tor_mem_is_zero is variable-time, whereas its constant-time variant is safe_mem_is_zero.
I'm fine with the "safe_" name, but we should rename tor_mem_is_zero() to indicate that it is the fast one, not the safe one. We should also audit its users, particularly tor_digest{256,}_is_zero()Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30267Simplify the code logic of launching HS circuits2021-09-16T14:19:58ZGeorge KadianakisSimplify the code logic of launching HS circuitsThe intro/rendezvous parts of `circuit_get_open_circ_or_launch()` are very complicated, and then they call `circuit_get_open_circ_or_launch()` which is also extremely complicated.
A minimal action item for improving the situation here w...The intro/rendezvous parts of `circuit_get_open_circ_or_launch()` are very complicated, and then they call `circuit_get_open_circ_or_launch()` which is also extremely complicated.
A minimal action item for improving the situation here would be to split the HS-parts of `connection_ap_handshake_attach_circuit()` which are already pretty disentangled into their own function. That's pretty easy to do.
The harder part of this would be to see if we can also split the HS parts of `circuit_get_open_circ_or_launch()` in some way.https://gitlab.torproject.org/tpo/core/tor/-/issues/22449Remove timestamp_dirty kludge from mark_circuit_unusable_for_new_conns()2021-09-16T14:18:43ZNick MathewsonRemove timestamp_dirty kludge from mark_circuit_unusable_for_new_conns()In mark_circuit_unsusable_for_new_conns(), we set the unusable_for_new_conns flag... but we also carry around some old code that messes around with timestamp_dirty.
The root problem here is that the old code makes timestamp_dirty into...In mark_circuit_unsusable_for_new_conns(), we set the unusable_for_new_conns flag... but we also carry around some old code that messes around with timestamp_dirty.
The root problem here is that the old code makes timestamp_dirty into a lie; "unusable" and "dirty" are not the same concept.
We should carefully audit timestamp_dirty and its users to make sure that it's safe to remove this old kludge, and then remove it or replace it with something more accurate.https://gitlab.torproject.org/tpo/web/tpo/-/issues/40UI bugs /press2021-09-15T19:03:16ZAntonelaantonela@torproject.orgUI bugs /press* [ ] release panels don't stack very neatly on medium-size screens (and could use some padding between rows on small screens too): https://www.dropbox.com/s/gnrxlckjibjbcdb/Screenshot%202019-02-12%2015.54.36.png?dl=0
* [ ] Preamble te...* [ ] release panels don't stack very neatly on medium-size screens (and could use some padding between rows on small screens too): https://www.dropbox.com/s/gnrxlckjibjbcdb/Screenshot%202019-02-12%2015.54.36.png?dl=0
* [ ] Preamble text on all subpages is a little big on mobile, and could be reduced at a suitable breakpoint: https://www.dropbox.com/s/6t6s4kcoj5n8sxz/Screenshot%202019-02-12%2015.53.21.png?dl=0donutsdonutshttps://gitlab.torproject.org/tpo/core/arti/-/issues/52Add a test framework for the path selection algorithm2021-09-08T15:15:27ZLunarAdd a test framework for the path selection algorithm`DirPathBuilder.pick_path` and `ExitPathBuilder.pick_path` currently lack tests. Ideally, we would want to add some way to test these methods against various network topology and check the selected paths.
What I thought of, so far:
- mo...`DirPathBuilder.pick_path` and `ExitPathBuilder.pick_path` currently lack tests. Ideally, we would want to add some way to test these methods against various network topology and check the selected paths.
What I thought of, so far:
- mock DirInfo and most of the objects it references,
- create a consensus document from a human readable description of the network and then parse it into a DirInfo,
- instantiate a full DirInfo using code to help us do that.
The [testing category on crates.io](https://crates.io/categories/development-tools::testing) is worth investigating.
Anyway, this issue is mostly for collecting ideas for now, so if you have any, or even a suggestion of what should be done exactly, let's hear it. :)Arti 0.0.1 release: basic anonymityhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16803Unit tests for sandbox failures2021-09-04T16:25:49ZNick MathewsonUnit tests for sandbox failuresWe should check that our sandboxing code blocks what it's supposed to block. This seems like something to do in a program to be invoked from a shell script.We should check that our sandboxing code blocks what it's supposed to block. This seems like something to do in a program to be invoked from a shell script.https://gitlab.torproject.org/tpo/web/tpo/-/issues/227Update wiki link in the contributing.md2021-09-01T01:48:15Zchampionquizzerchampionquizzer@torproject.orgUpdate wiki link in the contributing.mdSimilar to https://gitlab.torproject.org/tpo/web/tpo/-/issues/226, we need to update the wiki link on the [contributing.md](https://gitlab.torproject.org/tpo/web/tpo/-/blob/master/CONTRIBUTING.md)
'Check our wiki pages for more informat...Similar to https://gitlab.torproject.org/tpo/web/tpo/-/issues/226, we need to update the wiki link on the [contributing.md](https://gitlab.torproject.org/tpo/web/tpo/-/blob/master/CONTRIBUTING.md)
'Check our wiki pages for more information.' (positioned right above '[Translations](https://gitlab.torproject.org/tpo/web/tpo/-/blob/master/CONTRIBUTING.md#translations)') should redirect to https://gitlab.torproject.org/tpo/web/wiki/-/wikis/How-to-develop-on-the-websitehttps://gitlab.torproject.org/tpo/web/tpo/-/issues/172[UX] Edge alignment in the website2021-08-31T18:14:30Zriyajawandhiya[UX] Edge alignment in the website**What is the user problem?**
alignment is vitally important in design as:
1. allows you to arrange elements in a way that matches how people naturally scan the page
2. helps balance your image so that it’s visually appealing
3. create...**What is the user problem?**
alignment is vitally important in design as:
1. allows you to arrange elements in a way that matches how people naturally scan the page
2. helps balance your image so that it’s visually appealing
3. creates a visual connection between related elements
![image](/uploads/67c28bd465e629e8fd70b6169e1b555d/image.png)
The screenshot is taken from [downloads website](https://www.torproject.org/download/)
**What needs to be done?**
naturally positions elements against a margin that matches up with their outer edges. I have drawn the differences.
- Red - Vertical alignment of the text - justified text to be used
- Yellow - Center-line acting as the pivot - every gap must be equidistant
- Blue - Horizontal alignment of the image - place image at equidistant locationhttps://gitlab.torproject.org/tpo/web/lego/-/issues/21Add Privchat to footer?2021-08-31T13:25:14ZdonutsAdd Privchat to footer?There doesn't seem to be a way to navigate to the [Privchat landing page](https://www.torproject.org/privchat/) via the site menus. Adding a link to the footer seems like a sensible solution.There doesn't seem to be a way to navigate to the [Privchat landing page](https://www.torproject.org/privchat/) via the site menus. Adding a link to the footer seems like a sensible solution.https://gitlab.torproject.org/tpo/web/tpo/-/issues/210The onion address mentioned in the footer is still v22021-08-30T12:05:31ZsmoutwortelThe onion address mentioned in the footer is still v2The reference to the onion version of FAQ is the v2 version instead of the v3.The reference to the onion version of FAQ is the v2 version instead of the v3.https://gitlab.torproject.org/tpo/web/tpo/-/issues/57add mastodon link to https://www.torproject.org/contact/2021-08-23T16:33:41Zemmapeeladd mastodon link to https://www.torproject.org/contact/reported by kushal:
we should update our contact page with the very active mastodon accountreported by kushal:
we should update our contact page with the very active mastodon accounthttps://gitlab.torproject.org/tpo/web/tpo/-/issues/36In contact section add #tor-ux channel2021-08-23T16:33:41ZGusIn contact section add #tor-ux channel