The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-11-07T11:48:56Zhttps://gitlab.torproject.org/tpo/onion-services/sauteed-onions/web/-/issues/3Link WPES slides2022-11-07T11:48:56ZRasmus Dahlbergrasmus@rgdd.seLink WPES slidesLink WPES pdf slides from Paul somewhere.Link WPES pdf slides from Paul somewhere.https://gitlab.torproject.org/tpo/core/torsocks/-/issues/40013torsocks doesn't work on Mac OS Monterey and higher2023-12-12T18:35:34ZXnDY1torsocks doesn't work on Mac OS Monterey and higherI installed Torsocks 2.3.0 via homebrew, while it could not work properly.
I also compiled torsocks myself with gnu gcc (with 0001-Fix-macros-for-accept4-2.patch). The binary looked good but still didn't working.
By contrast, I can con...I installed Torsocks 2.3.0 via homebrew, while it could not work properly.
I also compiled torsocks myself with gnu gcc (with 0001-Fix-macros-for-accept4-2.patch). The binary looked good but still didn't working.
By contrast, I can confirm the latest `proxychains-ng` works, looks like new DYLD hooking method for OSX Monterey is required for recent Mac OS (https://github.com/rofl0r/proxychains-ng/commit/4a013fe6a59ed30e045301dc636d07a6ed999081)
There's some relative discuss: https://tor.stackexchange.com/questions/23135/torsocks-doesn-t-torify-on-macos
Can someone take a look?https://gitlab.torproject.org/tpo/core/arti/-/issues/618BridgeDescManager should use SharedMutArc internally2023-01-24T17:28:59ZIan Jacksoniwj@torproject.orgBridgeDescManager should use SharedMutArc internallyBut SharedMutArc needs to be changed first to not contain `Option`.
See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/820#note_2850187But SharedMutArc needs to be changed first to not contain `Option`.
See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/820#note_2850187Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.org2022-12-31https://gitlab.torproject.org/tpo/core/arti/-/issues/617BridgeDescManager should use sleep_wallclock2023-10-10T16:14:55ZIan Jacksoniwj@torproject.orgBridgeDescManager should use sleep_wallclockSee https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/820#note_2850268 et prec.See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/820#note_2850268 et prec.Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.org2022-12-31https://gitlab.torproject.org/tpo/core/arti/-/issues/615SignatureGated API does not enforce semantically-correct use2022-11-01T17:27:00ZIan Jacksoniwj@torproject.orgSignatureGated API does not enforce semantically-correct useWhen cryptographic signatures are in use, it is necessary for the verifier to know what key they expect a document to be signed by. Usually, this is some other key than one contained within the document (ie, for most security purposes, ...When cryptographic signatures are in use, it is necessary for the verifier to know what key they expect a document to be signed by. Usually, this is some other key than one contained within the document (ie, for most security purposes, a self-signature is not very interesting).
Crypto APIs should be designed so that they encourage correct use and so that incorrect (insecure) use is difficult to do by accident.
`SignatureGated` has an innocently-named `check_signature` method which takes no indication of the public key(s) to use. It performs a self-signature check. This invites a mistake where a programmer who has a `SignatureGated` calls `check_signature` expecting it to check it against some ambient idea of what we ought to be trusting (eg, the directory authorities maybe).
Given the nontrivial trust relationships in the Tor network, fixing this is going to involve inspecting call sites etc. This is definitely a task for a rainy day.Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/tpa/prometheus-alerts/-/issues/8fix pint warnings on prod server2023-06-28T18:41:34Zanarcatfix pint warnings on prod serverI have enabled new checks in CI here, and it seems a bunch of rules are failing some checks. This job has an example:
https://gitlab.torproject.org/tpo/tpa/prometheus-alerts/-/jobs/191508
... which is copied below:
```
rules.d/metrics...I have enabled new checks in CI here, and it seems a bunch of rules are failing some checks. This job has an example:
https://gitlab.torproject.org/tpo/tpa/prometheus-alerts/-/jobs/191508
... which is copied below:
```
rules.d/metrics.rules:5: metric "metrics_log_warnings" with label {alias="CollecTor"} is only sometimes present on prometheus "prod" at https://ci:[MASKED]@prometheus2.torproject.org with average life span of 14h47m (promql/series)
5 | expr: metrics_log_warnings{alias="CollecTor", level="ERROR"} > 1
rules.d/metrics.rules:5: prometheus "prod" at https://ci:[MASKED]@prometheus2.torproject.org has "metrics_log_warnings" metric with "level" label but there are no series matching {level="ERROR"} in the last 1w (promql/series)
5 | expr: metrics_log_warnings{alias="CollecTor", level="ERROR"} > 1
rules.d/metrics.rules:16: metric "metrics_log_warnings" with label {alias="OnionooService"} is only sometimes present on prometheus "prod" at https://ci:[MASKED]@prometheus2.torproject.org with average life span of 1d13h12m30s (promql/series)
16 | expr: metrics_log_warnings{alias="OnionooService", level="ERROR"} > 1
rules.d/metrics.rules:16: prometheus "prod" at https://ci:[MASKED]@prometheus2.torproject.org has "metrics_log_warnings" metric with "level" label but there are no series matching {level="ERROR"} in the last 1w (promql/series)
16 | expr: metrics_log_warnings{alias="OnionooService", level="ERROR"} > 1
rules.d/metrics.rules:27: prometheus "prod" at https://ci:[MASKED]@prometheus2.torproject.org has "exits_list_last_updated_in_minutes" metric with "status" label but there are no series matching {status="UNSTABLE"} in the last 1w (promql/series)
27 | expr: exits_list_last_updated_in_minutes{status="UNSTABLE"} > 0
rules.d/metrics.rules:60: prometheus "prod" at https://ci:[MASKED]@prometheus2.torproject.org has "onionperf_analysis_logs_staleness" metric with "status" label but there are no series matching {status="UNSTABLE"} in the last 1w (promql/series)
60 | expr: onionperf_analysis_logs_staleness{status="UNSTABLE"} > 0
rules.d/rdsys.rules:5: metric "gettor_request_total" is only sometimes present on prometheus "prod" at https://ci:[MASKED]@prometheus2.torproject.org with average life span of 1d3h37m30s in the last 1w (promql/series)
5 | expr: sum(increase(gettor_request_total[1h])) == 0
```
basically, it looks like metrics like (say) `metrics_log_warnings` don't explicitly emit the requested label (presumably when it's zero. i haven't checked, but i bet that, for example, that metrics looks like this in the exporter output:
```
metrics_log_warnings{alias="CollecTor", level="WARNING"} 10
metrics_log_warnings{alias="CollecTor", level="INFO"} 100
```
and that, since there's no `ERROR`, no line is emitted. for some reason, this makes pint unhappy... i'm not exactly sure why, but i suspect it's to catch problems with incorrect labels in rules or metrics names. for example, if you'd write an alerting rule with `metrics_log_warnings{alias="CollecTor", level="ERREUR"}` because, I don't know, you're french or something, pint would catch that and tell you that label doesn't exist. (it won't tell you the right one is `ERROR` of course, can't have nice things.)
so i think it makes sense to have that check, and i'd encourage you (i think both @hiro and @meskio have things to fix here) should look into this and improve the exporters so that those labels are correctly emitted even if zero.
for now, the job is marked as `allow_failure`, but i'd like to enforce that one eventually, so we'd need to have that check go green first.
assigning to @hiro first, since there's more metrics than anti-censorship stuff in there.HiroHirohttps://gitlab.torproject.org/tpo/core/arti/-/issues/609Implement octal escapes in PT parsing (or change the spec)2023-11-15T19:04:25ZetaImplement octal escapes in PT parsing (or change the spec)The pluggable transport spec states that some strings passed from PT to host can be Tor CStrings:
```
The MESSAGE value is a human readable string formatted by the PT. The
<Message> contains the log message which can be a String o...The pluggable transport spec states that some strings passed from PT to host can be Tor CStrings:
```
The MESSAGE value is a human readable string formatted by the PT. The
<Message> contains the log message which can be a String or CString (see
section 2 in control-spec.txt).
```
According to control-spec.txt, a CString can include octal escapes:
```
in a CString, the escapes "\n", "\t", "\r", and the octal escapes
"\0" ... "\377" represent newline, tab, carriage return, and the
256 possible octet values respectively.
```
We currently don't implement this, but maybe we should? (Or, we should change the spec to clarify that you can't use these and simplify that way.)
---
The following discussion from !779 should be addressed:
- [ ] @nickm started a [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/779#note_2845450):
> Let's open a ticket for this, and additionally add some kind of a "not implemented" error.
>
> That way if anybody actually uses these escapes, we'll learn about it instead of getting silent miscomputations.Arti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/community/l10n/-/issues/40098Clear licenses for translations in weblate2023-08-25T18:40:24ZemmapeelClear licenses for translations in weblateOur free account in weblate depends on the translations made for Free and Libre software.
We do not have a clear policy about licenses for translations, and if possible decide on a default license for them.
The licenses offered in Webl...Our free account in weblate depends on the translations made for Free and Libre software.
We do not have a clear policy about licenses for translations, and if possible decide on a default license for them.
The licenses offered in Weblate are explained here: https://spdx.org/licenses/.
We need to find out which licenses the translations should have, fix the licenses on weblate, and document the reasoning.emmapeelemmapeelhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40702Single Onion Service Rends become 7 hop after retry2023-02-09T16:22:00ZMike PerrySingle Onion Service Rends become 7 hop after retryIn `retry_service_rendezvous_point()`, if a rend connect fails for a non-anonymous rend, we promote it to a 7-hop slow rend for some reason.
This will impact non-anonymous onions who want performance, especially during the DoS.
David n...In `retry_service_rendezvous_point()`, if a rend connect fails for a non-anonymous rend, we promote it to a 7-hop slow rend for some reason.
This will impact non-anonymous onions who want performance, especially during the DoS.
David notes that this decision to fall back to full anonymous mode in the event of timeout or failure was explicitly written just in case a non-anonymous onion service was also behind a restrictive firewall, and that firewall was the thing that happened to cause a timeout. There is also a comment that explains this, believe it or not. Back then, decision making in C-Tor was a bit more...special.
I bet if we get funders who actually care about single onion performance, they would prefer that their single onions not randomly double in latency on a timeout or failure, just to support the case where some single onion out there might be behind a firewall that they don't know about. Such a funder might suggest that we provide some other option for people behind firewalls to use, instead of this madness.
But I look forward to more research.https://gitlab.torproject.org/tpo/onion-services/sauteed-onions/onion-csr/-/issues/3Parse metadata of hs_ed25519_secret_key2022-11-12T16:49:47ZRasmus Dahlbergrasmus@rgdd.seParse metadata of hs_ed25519_secret_keyWe currently skip the first 32 bytes of the `hs_ed25519_secret_key` when parsing in `pkg/okey`. It would be nice to check that this initial metadata is not malformed.
Maybe a good place to start looking for inspiration: https://gitlab....We currently skip the first 32 bytes of the `hs_ed25519_secret_key` when parsing in `pkg/okey`. It would be nice to check that this initial metadata is not malformed.
Maybe a good place to start looking for inspiration: https://gitlab.torproject.org/tpo/core/tor/-/blob/main/src/feature/keymgt/loadkey.c#L379https://gitlab.torproject.org/tpo/onion-services/sauteed-onions/onion-csr/-/issues/2Clean-up dependency for parsing of hs_ed25519_secret_key2022-11-12T16:49:40ZRasmus Dahlbergrasmus@rgdd.seClean-up dependency for parsing of hs_ed25519_secret_keyRemove "bed25519" dependency in `pkg/okey` and instead implement the crypto.Signer interface in this repo, maybe using:
- https://pkg.go.dev/filippo.io/edwards25519
Note that it is not possible to use `crypto/ed25519` because the pri...Remove "bed25519" dependency in `pkg/okey` and instead implement the crypto.Signer interface in this repo, maybe using:
- https://pkg.go.dev/filippo.io/edwards25519
Note that it is not possible to use `crypto/ed25519` because the private key requires the seed, and what's stored in `hs_ed25519_secret_key` is the expanded seed after hashing and setting a few bits.https://gitlab.torproject.org/tpo/onion-services/sauteed-onions/onion-csr/-/issues/1Add CI with basic Go tests2022-11-12T16:49:32ZRasmus Dahlbergrasmus@rgdd.seAdd CI with basic Go testsShould run go build / test / vet / fmt or similar.Should run go build / test / vet / fmt or similar.https://gitlab.torproject.org/tpo/community/support/-/issues/40093Provide a recommended set of iptables/nftables rules to help in case of DoS a...2023-07-14T15:15:42ZGeorg KoppenProvide a recommended set of iptables/nftables rules to help in case of DoS attacksA bunch of DoS attacks are essentially ongoing since June 2022 and we discussed a bunch of potential solution to improve things for our users. One thing folks started to experiment with is trying to come up with good iptables rules to he...A bunch of DoS attacks are essentially ongoing since June 2022 and we discussed a bunch of potential solution to improve things for our users. One thing folks started to experiment with is trying to come up with good iptables rules to help fighting ongoing attacks.
This ticket is for collecting all the information we gathered so far and coming up with some rules we can recommend to our relay operators (and updating our support guidelines accordingly).https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/129GetTor is not replying to emails2023-07-24T16:18:41ZGusGetTor is not replying to emailsUsers from Iran reported that GetTor is not replying to them. I have tried myself and I didn't get a reply too.Users from Iran reported that GetTor is not replying to them. I have tried myself and I didn't get a reply too.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/network-health/team/-/issues/270Conduct a privacy impact assessment of monitoring tools with an external party.2024-03-07T14:43:14ZGabagaba@torproject.orgConduct a privacy impact assessment of monitoring tools with an external party.In this issue, we will engage a third party to conduct a privacy impact assessment of the tools developed in the Objective 1 of the [project 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues).
The goal of this as...In this issue, we will engage a third party to conduct a privacy impact assessment of the tools developed in the Objective 1 of the [project 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues).
The goal of this assessment is to investigate whether or not these tools impact the privacy of relay operators and to ensure that these tools are working in the most rights-preserving ways possible. Should issues be discovered in this assessment, we will take recommended action to remedy them. This assessment will include both public- and internal-facing components of these tools. We will make a redacted, summarized, and/or plain language version of this report public.
- [ ] Create RFP To find consultants
- [ ] Send to consultantsGabagaba@torproject.orgGabagaba@torproject.org2024-05-06https://gitlab.torproject.org/tpo/community/relays/-/issues/58Develop and implement solutions for operator codes of conduct, policies, agre...2024-03-27T09:44:55ZGabagaba@torproject.orgDevelop and implement solutions for operator codes of conduct, policies, agreements, and methods for enforcementThis is activity O2.3 for [sponsor 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues):
Develop and implement solutions for operator codes of conduct, policies, agreements, and methods for enforcement. The code of ...This is activity O2.3 for [sponsor 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues):
Develop and implement solutions for operator codes of conduct, policies, agreements, and methods for enforcement. The code of conduct will codify what we expect of relay operators rather than leaving it implicit, as it is now. These guidelines mirror our criteria for rejecting bad relays.
In this Activity we will:
- Publish clear guidelines for
1. Tor to consistently identify and reject malicious relays, and
2. Relay operators to understand what kind of behavior will not be tolerated and what steps are taken when certain activity is detected.
- Use criteria developed in [activity O2.1](https://gitlab.torproject.org/tpo/network-health/team/-/issues/265) to evaluate whether these behavior expectations and consequence solutions are appropriate per relay operator feedback.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/community/relays/-/issues/56Evaluate proposals for relay operator code of conduct, policies, agreements a...2024-03-27T09:44:22ZGabagaba@torproject.orgEvaluate proposals for relay operator code of conduct, policies, agreements and methods for enforcementThis is activity O2.2 for [sponsor 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues):
Evaluate promising solutions for relay operator code of conduct, policies, agreements, and methods for enforcement. In this Ac...This is activity O2.2 for [sponsor 112](https://gitlab.torproject.org/groups/tpo/-/milestones/44#tab-issues):
Evaluate promising solutions for relay operator code of conduct, policies, agreements, and methods for enforcement. In this Activity, our goal is to engage relay operators and gather feedback about potential solutions around establishing behavior expectations and clear consequences.
- Gather input from the community on any concepts developed in this project. This involves online events and discussions where we engage with relay operators in different phases of the relay operator life cycle.
- Develop recommendations for activities [2.3](https://gitlab.torproject.org/tpo/network-health/team/-/issues/267) and [2.4](https://gitlab.torproject.org/tpo/network-health/team/-/issues/268) based on the research findings and the relay operator personas definition developed as part of the OTF fellowship alongside input collected in this Activity.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41335Establish a common onboarding template for both browsers2024-02-15T14:50:07ZdonutsEstablish a common onboarding template for both browsersTor Browser's current onboarding template is a port of an older version from Firefox. We should explore alternatives here before deciding on a template, e.g. the practicality of modifying Firefox's current built-in format.Tor Browser's current onboarding template is a port of an older version from Firefox. We should explore alternatives here before deciding on a template, e.g. the practicality of modifying Firefox's current built-in format.Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/core/arti/-/issues/590shadow ci: dynamically generate configurations2022-10-31T20:39:31ZJim Newsomeshadow ci: dynamically generate configurationsIn the initial version of the Shadow CI, pending merge from https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/634, the shadow configuration file, network graph, and tor configuration files and keys are pre-generated and checke...In the initial version of the Shadow CI, pending merge from https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/634, the shadow configuration file, network graph, and tor configuration files and keys are pre-generated and checked in. These are lightly modified output of [tornettools](https://github.com/shadow/tornettools).
We should use tornettools to generate these dynamically instead. This may require extending tornettools and/or scripting some post-processing of its output.Jim NewsomeJim Newsomehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41541Update builtin bridges from Circumvention Settings API2024-03-27T15:25:34Zmeskiomeskio@torproject.orgUpdate builtin bridges from Circumvention Settings APIRight now to update the builtin bridges we need to make a Tor Browser release, it would be nice if TB automatically updates them using [Circumvention Settings API](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/m...Right now to update the builtin bridges we need to make a Tor Browser release, it would be nice if TB automatically updates them using [Circumvention Settings API](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/moat.md#circumventionbuiltin).
There are two concerns I have about it:
* Users will not be happy with TB making a call to an external API without giving some consent about it.
* We don't want to make easier for censors to notice you are using Tor because of that.
I think it makes sense to update when we do other connections to moat (Connect Assist, captcha bridges, ...), I assume user has already consent to do a request to the API on those cases and having an extra connection over the domain fronting should not make it more noticeable than it already is. We could store when was the last time we had updated them, and don't update them is they are fresh (maybe 24h is a good freshness).
An extra that would be nice is to ask the user if they want to refresh the builtin bridges when they click on Settings to *Select a Built-In Bridge*. I think we should only ask if bridges hasn't being refreshed for a while (maybe 7days). The confirmation popup could have a check box with 'remember that option' or something like that, so the following times they enable builtin bridges we refresh or not without asking (if the bridges hasn't being refreshed in 7days).Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetma1ma1