The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-06-17T18:34:15Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19074Mark fallback directories down when their key is wrong2022-06-17T18:34:15ZteorMark fallback directories down when their key is wrongarma says that we will happily retry fallback directories with the wrong key fingerprint. We can do two things to fix this:
* mark fallback directories as down when their key fingerprint is wrong
* cancel all pending connections to a fal...arma says that we will happily retry fallback directories with the wrong key fingerprint. We can do two things to fix this:
* mark fallback directories as down when their key fingerprint is wrong
* cancel all pending connections to a fallback with the wrong key (perhaps in legacy/trac#18809) - this should be unlikely with 100 fallbackshttps://gitlab.torproject.org/tpo/core/tor/-/issues/19073Remove duplicate signing_cert field from extrainfo and routerinfo.2020-06-27T13:59:02ZNick MathewsonRemove duplicate signing_cert field from extrainfo and routerinfo.Related to my fix for legacy/trac#17150. This makes sense to do in 0.2.8 and forward only.Related to my fix for legacy/trac#17150. This makes sense to do in 0.2.8 and forward only.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19072Remove duplicate signing_cert field from extrainfo and routerinfo.2020-06-27T13:59:03ZNick MathewsonRemove duplicate signing_cert field from extrainfo and routerinfo.Related to my fix for legacy/trac#17150. This makes sense to do in 0.2.8 and forward only.Related to my fix for legacy/trac#17150. This makes sense to do in 0.2.8 and forward only.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19071Check existing fallback fingerprints, IPs, and ports before 0.2.8-rc2020-06-27T13:59:03ZteorCheck existing fallback fingerprints, IPs, and ports before 0.2.8-rcI want to run the standard checks on the 100 fallback directories from April 2016 before we put them in a June? 2016 release candidate.
I bet at least one has changed its fingerprint, IP, or ports, and will need to be removed.
I wonder...I want to run the standard checks on the 100 fallback directories from April 2016 before we put them in a June? 2016 release candidate.
I bet at least one has changed its fingerprint, IP, or ports, and will need to be removed.
I wonder if we should regenerate the list at that point, or just remove (or update) the broken fallbacks?
I'll decide at the time based on how many are broken.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/19070Batch-modify notifications don't seem very useful2020-06-27T14:19:25ZNick MathewsonBatch-modify notifications don't seem very usefulIt would be great if the batch modification emails to tor-bugs had a little more information in them, so you could guess which tickets were being changed.
For example, instead of saying:
```
Subject: [Tor Bug Tracker & Wiki] Batch modif...It would be great if the batch modification emails to tor-bugs had a little more information in them, so you could guess which tickets were being changed.
For example, instead of saying:
```
Subject: [Tor Bug Tracker & Wiki] Batch modify: #18240, #17158, #18808
Batch modification to #18240, #17158, #18808 by isabela:
points to 0.4
```
How about if it said something like this?
```
Subject: [Tor Bug Tracker & Wiki] Batch modify: #18240, #17158, #18808
Batch modification by isabela to these tickets:
#18240 'make test-stem' yields No rule to make target '"./src/or/tor"'
https://trac.torproject.org/projects/tor/ticket/18240
#17158 Run an opt-in process for fallback directories
https://trac.torproject.org/projects/tor/ticket/17158
#18808 Check if connection is excess in connection_dir_finished_flushing
https://trac.torproject.org/projects/tor/ticket/18808
Modification:
points to 0.4
```Jens KubiezielJens Kubiezielhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19069When DisableNetwork is 1 but !circuit_enough_testing_circs(), we can still la...2022-06-24T16:12:14ZRoger DingledineWhen DisableNetwork is 1 but !circuit_enough_testing_circs(), we can still launch circuitsIn consider_testing_reachability(), we check
```
if (test_or && (!orport_reachable || !circuit_enough_testing_circs())) {
```
Once legacy/trac#18616 is merged, the first function will return 1 for orport_reachable when DisableNetwork ...In consider_testing_reachability(), we check
```
if (test_or && (!orport_reachable || !circuit_enough_testing_circs())) {
```
Once legacy/trac#18616 is merged, the first function will return 1 for orport_reachable when DisableNetwork is 1, so that bug will go away.
But it will remain the case that if !circuit_enough_testing_circs(), we will proceed to call circuit_launch_by_extend_info(), even when DisableNetwork is 1.
There are four places that call consider_testing_reachability():
* circuitbuild.c:circuit_send_next_onion_skin()
* circuituse.c:circuit_testing_opened()
* main.c:directory_info_has_arrived()
* main.c:check_for_reachability_bw_callback()
I think the middle two are safe, since they shouldn't happen while DisableNetwork is set.
I think the first one is iffy, since it's called from a bunch of places so I'm not sure, but given the name I hope it doesn't get called during DisableNetwork.
And I think the fourth one is bad news, since it gets called periodically and doesn't check DisableNetwork.https://gitlab.torproject.org/tpo/core/tor/-/issues/19068Write and run a clique reachability test.2020-11-04T14:18:56ZYawning AngelWrite and run a clique reachability test.It would be useful to know what the full inter-relay connectivity graph looks like, and how far it differs from the "every relay can always reach every other relay" ideal.
https://www.sba-research.org/wp-content/uploads/publications/Nav...It would be useful to know what the full inter-relay connectivity graph looks like, and how far it differs from the "every relay can always reach every other relay" ideal.
https://www.sba-research.org/wp-content/uploads/publications/NavigaTor_preprint.pdf
This should be something doable with stem, and ideally we can run it periodically/automatically, and use it to do things like reject relays that have extremely poor connectivity.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/applications/tor-browser-bundle-testsuite/-/issues/19067Create a testsuite bundle to provide an easy way for users to run the test suite2020-06-27T13:41:58ZboklmCreate a testsuite bundle to provide an easy way for users to run the test suiteWe should create a bundle containing the Tor Browser testsuite and all its dependencies, to allow users to easily run it to test Tor Browser, on all supported platforms.We should create a bundle containing the Tor Browser testsuite and all its dependencies, to allow users to easily run it to test Tor Browser, on all supported platforms.boklmboklmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19066Wrong length used in networkstatus_parse_detached_signatures2020-06-27T13:59:03ZDavid Gouletdgoulet@torproject.orgWrong length used in networkstatus_parse_detached_signaturesWhile fixing legacy/trac#14013, nikkolasg realized thatif we did in fact use `!= DIGEST256_LEN` it caused a failure in the test:
```
// XXX Should it not be always DIGEST256_LEN ? Running the tests with
// the condition ` != DIG...While fixing legacy/trac#14013, nikkolasg realized thatif we did in fact use `!= DIGEST256_LEN` it caused a failure in the test:
```
// XXX Should it not be always DIGEST256_LEN ? Running the tests with
// the condition ` != DIGEST256_LEN` fails.
if (base16_decode(digests->d[alg], DIGEST256_LEN,
hexdigest, strlen(hexdigest)) < 0) {
```
Turns out that `alg` here is actually `sha1` thus of size `DIGEST_LEN`. The base16 decode is safe with a larger length but this check (just above in the code) could resolved in unwanted behavior:
```
if (!tor_mem_is_zero(digests->d[alg], DIGEST256_LEN)) {
```
`tor_mem_is_zero` does make sure that the full length is zeroes thus here looking for 12 extra bytes out of bound to be 0... (DIGEST_LEN vs DIGEST256_LEN). The length we used should be set according to the algorithm in `alg`
Patch coming soon.Tor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19065Tor Browser icon not visible anymore in upper left corner on Linux since 05/132020-06-27T14:39:11ZGeorg KoppenTor Browser icon not visible anymore in upper left corner on Linux since 05/13The nightly build from May 09 is the last one still showing the Tor Browser icon in the upper left corner of browser windows/dialogs. The nightly from May 13 is the first one that just shows a placeholder icon on Linux.The nightly build from May 09 is the last one still showing the Tor Browser icon in the upper left corner of browser windows/dialogs. The nightly from May 13 is the first one that just shows a placeholder icon on Linux.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19063The tor_parse_* functions should check and warn on max < min2020-06-27T13:59:03ZteorThe tor_parse_* functions should check and warn on max < minIf a developer mistakenly calls:
```
tor_parse_long(value, 10, 1, UINT32_MAX, NULL, NULL);
```
It effectively becomes:
```
tor_parse_long(value, 10, 1, -1, NULL, NULL);
```
We can detect this by making sure `min <= max`, and warning if...If a developer mistakenly calls:
```
tor_parse_long(value, 10, 1, UINT32_MAX, NULL, NULL);
```
It effectively becomes:
```
tor_parse_long(value, 10, 1, -1, NULL, NULL);
```
We can detect this by making sure `min <= max`, and warning if that's not the case. (I really don't think we should assert.)
We should do this for all similar tor_parse_* functions.
But are there any circumstances where we should allow min to be greater than max? (it will always fail)
Existing callers pass constants to this function, so it's not going to trigger for them.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19060Should SafeLogging hide bridge IP addresses in logs?2020-06-27T13:59:03ZteorShould SafeLogging hide bridge IP addresses in logs?Bridge relay operators sometimes post logs containing their bridge's IP address.
We could make this less likely by making `SafeLogging 1` (the default) filter bridge IP addresses in messages like:
* "Your server (%s:%d) has not managed ...Bridge relay operators sometimes post logs containing their bridge's IP address.
We could make this less likely by making `SafeLogging 1` (the default) filter bridge IP addresses in messages like:
* "Your server (%s:%d) has not managed to confirm that its ORPort is reachable" ...
* "Your server (%s:%d) has not managed to confirm that its DirPort is reachable" ...
* "Now checking whether ORPort %s:%d"...
* "and DirPort %s:%d"
* anything else that lists a bridge's IP or fingerprint
This could be implemented by creating safe_str_bridge and escaped_safe_str_bridge similar to safe_str and escaped_safe_str, but with a check if BridgeRelay is 1 as well. It would also need a tor manual page update that says that we escape bridge information when SafeLogging is anything besides "0".
Or, we could add "bridge" to the options for SafeLogging, but that seems over-complicated, because we'd have to define 1 vs relay vs bridge semantics in a way that makes sense.Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/tpa/team/-/issues/19059Request for gsoc-admin@ list2020-06-27T14:19:26ZDamian JohnsonRequest for gsoc-admin@ listHi there, just a quick request for a new list. We presently have a gsoc2016@ alias that points to tor-team@. It would be nice if we had a proper gsoc-admin@ list, and updated that alias to point there.
list name: gsoc-admin
list admins:...Hi there, just a quick request for a new list. We presently have a gsoc2016@ alias that points to tor-team@. It would be nice if we had a proper gsoc-admin@ list, and updated that alias to point there.
list name: gsoc-admin
list admins: atagar
This should be a closed list. I'll add Roger and Sebastian (the other admins) to the list once it's created.
Thanks!Jens KubiezielJens Kubiezielhttps://gitlab.torproject.org/tpo/community/support/-/issues/19057Prohibit modifications of doc/EmailProvider2022-03-01T18:19:45ZcypherpunksProhibit modifications of doc/EmailProviderSomeone have created doc/EmailProvider and constantly removes my notes from there. Creating such a list, especially on torproject official website, can be harmful, because it reduces the cost of discovering such services to law enforceme...Someone have created doc/EmailProvider and constantly removes my notes from there. Creating such a list, especially on torproject official website, can be harmful, because it reduces the cost of discovering such services to law enforcement.
The fact users are not identified are flaws in a state, and states will fix them. Those unfixed services are really rare. Creating such a public list will allow law enforcement to fix them all. All the law enforcement will have to do is to monitor such lists and enforce services` owners.
So I propose to lock the page to prevent addition of services and make an official statement about it.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/19056Write, review, deploy the basket2 pluggable transport.2020-06-27T13:43:53ZYawning AngelWrite, review, deploy the basket2 pluggable transport.I've been working on a successor to `obfs4` called `basket2`, which combines a bunch of ideas from `obfs4` and `basket` into one unholy abomination.
This ticket is the meta ticket to track development and initial deployment of the trans...I've been working on a successor to `obfs4` called `basket2`, which combines a bunch of ideas from `obfs4` and `basket` into one unholy abomination.
This ticket is the meta ticket to track development and initial deployment of the transport.
Code: https://git.schwanenlied.me/yawning/basket2
Deployment requires: legacy/trac#18333 along with updating some of the dependencies pulled in for obfs4.Yawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19055TBB Upstreaming of Yawning's Firejail Script2020-06-27T14:39:11ZcypherpunksTBB Upstreaming of Yawning's Firejail ScriptThis ticket is to track the eventual inclusion for a Firejail aware start-tor-browser script in TBB releases - it attempts to run TBB in Firejail if detected on the system. Firejail is a popular and well maintained software containment s...This ticket is to track the eventual inclusion for a Firejail aware start-tor-browser script in TBB releases - it attempts to run TBB in Firejail if detected on the system. Firejail is a popular and well maintained software containment system available in Debian.
(Yawning is very busy these days and won't be able to work on it. Thanks Yawning for writing it in the first place!)
Since a Tor Browser planned changes is to release versions that can take advantage of system containment features - this work complements it IMHO.
https://git.schwanenlied.me/yawning/tor-firejail
https://lists.torproject.org/pipermail/tor-dev/2016-May/010948.htmlhttps://gitlab.torproject.org/tpo/network-health/metrics/collector/-/issues/19052collector jenkins integration2020-06-27T14:22:46Ziwakehcollector jenkins integrationProvide jenkins builds for tests, code metrics, etc.
This should be extended to other Metrics Team projects.Provide jenkins builds for tests, code metrics, etc.
This should be extended to other Metrics Team projects.https://gitlab.torproject.org/tpo/network-health/metrics/library/-/issues/19051add benchmark code to metrics-lib test sources2020-06-27T14:23:43Ziwakehadd benchmark code to metrics-lib test sourcescf. discussion in legacy/trac#18861; summary:
Considering the plans about the new file structure (cf. legacy/trac#18964) I'd suggest `test/java` in package `org.torproject.descriptor.benchmark`.
It will be excluded from javadoc and uni...cf. discussion in legacy/trac#18861; summary:
Considering the plans about the new file structure (cf. legacy/trac#18964) I'd suggest `test/java` in package `org.torproject.descriptor.benchmark`.
It will be excluded from javadoc and unit tests.
Maybe, add a new ant task `benchmark`?Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/19050Do not use a single static mirror for setting up build environments2020-06-27T14:19:26ZcypherpunksDo not use a single static mirror for setting up build environmentsBuilds are sometimes failing on Jenkins because it is unable to connect to the Debian and Ubuntu mirrors at http://ftp.osuosl.org/pub/. For example: https://jenkins.torproject.org/job/tor-ci-linux-0.2.8/ARCHITECTURE=amd64,SUITE=wheezy/23...Builds are sometimes failing on Jenkins because it is unable to connect to the Debian and Ubuntu mirrors at http://ftp.osuosl.org/pub/. For example: https://jenkins.torproject.org/job/tor-ci-linux-0.2.8/ARCHITECTURE=amd64,SUITE=wheezy/23/console
Debian has the [HTTP mirror redirector](http://httpredir.debian.org/) which could solve the problem by automatically picking different mirrors. Ubuntu has a similar solution by using the [global archive](https://help.ubuntu.com/community/Repositories/CommandLine#Explanation_of_the_Repository_Format).weasel (Peter Palfrader)weasel (Peter Palfrader)https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19048Review Firefox Developer Docs and Undocumented bugs since FF45esr2020-06-27T14:39:11ZGeorg KoppenReview Firefox Developer Docs and Undocumented bugs since FF45esrThis ticket is for the review of new features and (undocumented) bugs between Firefox 46 and 52 inclusive.This ticket is for the review of new features and (undocumented) bugs between Firefox 46 and 52 inclusive.