The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-07-20T21:15:30Zhttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/87Publish a snapshot of what PTs are needed for successful Tor use in each country2022-07-20T21:15:30ZRoger DingledinePublish a snapshot of what PTs are needed for successful Tor use in each countrySeveral countries have deployed censorship that includes trying to block Tor in various ways. And places change their censorship over time. What does the big picture look like today?
We have a scattering of resources on this topic curre...Several countries have deployed censorship that includes trying to block Tor in various ways. And places change their censorship over time. What does the big picture look like today?
We have a scattering of resources on this topic currently, e.g.:
* OONI has "vanilla Tor" measurements in some countries.
* We have anecdotal stories from talking to users in various places.
* There's the censorship wiki: https://trac.torproject.org/projects/tor/wiki/doc/OONI/censorshipwiki (legacy/trac#6149)
* metrics-timeline has something similar: https://trac.torproject.org/projects/tor/wiki/doc/MetricsTimeline
* And the Berkeley folks wrote up their own Tor censorship timeline: https://www.icsi.berkeley.edu/~sadia/tor_timeline.pdf
But what is the situation, this month, in every country? Which ones block the Tor directory authorities, which ones block the public relays, which ones block the default (i.e. included in tor browser) bridges, which ones enumerate bridges from bridges.torproject.org and block them by IP address, which ones use DPI to detect and cut various pluggable transport connections, which ones throttle protocols they don't want, etc?
When Venezuela's CANTV ISP did their IP address based blocking, they also blocked the default obfs4 bridges, which led to confusion and then unfortunate headlines like the one from Access: "Venezuela blocks Tor". (Tor worked fine if you got a fresh bridge, even a vanilla bridge.)
In Taipei I talked to some central asia experts who told me about how Tor only works in a degraded way in Belarus in the default configuration "because a few years ago they blocked all the relay IP addresses, but they haven't updated their block since then".
We need up-to-date information about Tor blocking to provide advice to our users when they ask for support, and also we want it for preemptively including good advice in Tor Launcher's UI. Knowing historical trends will help us prioritize the development of new pluggable transports vs new distribution methods of existing transports.
So, how do we get this information?
One option is that in the glorious future, the standard OONI decks will have all of these tools built-in. But that future is a long way off, and maybe it should never even arrive, since some Tor transports are huge and have no business being bundled into a little mobile testing app.
I think we instead want some combination of the following two plans:
* We have on-the-ground contacts in many countries, and it's often not just individuals but whole NGOs full of Tor enthusiasts. We should pull together our knowledge of who we know in each place, and ask them what they think the current situation is in their country, and talk to them regularly. We can prioritize the various countries that we think were, are, or might be trying to block Tor. Having these on-the-ground experts is going to be necessary no matter what else we add to the plan, and it's why I picked 'community outreach' as the ticket component.
* We should build automated tools to assist people in assessing Tor censorship on their network -- to increase the accuracy of reports that we get, and to make the reports come with actual data that we can compare over time. This idea is legacy/trac#23839.
This ticket is for pulling together one big-picture report. But once we have one, we will want to find ways of keeping ourselves up to date over time.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/community/outreach/-/issues/28531Publish a snapshot of what PTs are needed for successful Tor use in each country2022-07-20T21:10:55ZRoger DingledinePublish a snapshot of what PTs are needed for successful Tor use in each countrySeveral countries have deployed censorship that includes trying to block Tor in various ways. And places change their censorship over time. What does the big picture look like today?
We have a scattering of resources on this topic curre...Several countries have deployed censorship that includes trying to block Tor in various ways. And places change their censorship over time. What does the big picture look like today?
We have a scattering of resources on this topic currently, e.g.:
* OONI has "vanilla Tor" measurements in some countries.
* We have anecdotal stories from talking to users in various places.
* There's the censorship wiki: https://trac.torproject.org/projects/tor/wiki/doc/OONI/censorshipwiki (legacy/trac#6149)
* metrics-timeline has something similar: https://trac.torproject.org/projects/tor/wiki/doc/MetricsTimeline
* And the Berkeley folks wrote up their own Tor censorship timeline: https://www.icsi.berkeley.edu/~sadia/tor_timeline.pdf
But what is the situation, this month, in every country? Which ones block the Tor directory authorities, which ones block the public relays, which ones block the default (i.e. included in tor browser) bridges, which ones enumerate bridges from bridges.torproject.org and block them by IP address, which ones use DPI to detect and cut various pluggable transport connections, which ones throttle protocols they don't want, etc?
When Venezuela's CANTV ISP did their IP address based blocking, they also blocked the default obfs4 bridges, which led to confusion and then unfortunate headlines like the one from Access: "Venezuela blocks Tor". (Tor worked fine if you got a fresh bridge, even a vanilla bridge.)
In Taipei I talked to some central asia experts who told me about how Tor only works in a degraded way in Belarus in the default configuration "because a few years ago they blocked all the relay IP addresses, but they haven't updated their block since then".
We need up-to-date information about Tor blocking to provide advice to our users when they ask for support, and also we want it for preemptively including good advice in Tor Launcher's UI. Knowing historical trends will help us prioritize the development of new pluggable transports vs new distribution methods of existing transports.
So, how do we get this information?
One option is that in the glorious future, the standard OONI decks will have all of these tools built-in. But that future is a long way off, and maybe it should never even arrive, since some Tor transports are huge and have no business being bundled into a little mobile testing app.
I think we instead want some combination of the following two plans:
* We have on-the-ground contacts in many countries, and it's often not just individuals but whole NGOs full of Tor enthusiasts. We should pull together our knowledge of who we know in each place, and ask them what they think the current situation is in their country, and talk to them regularly. We can prioritize the various countries that we think were, are, or might be trying to block Tor. Having these on-the-ground experts is going to be necessary no matter what else we add to the plan, and it's why I picked 'community outreach' as the ticket component.
* We should build automated tools to assist people in assessing Tor censorship on their network -- to increase the accuracy of reports that we get, and to make the reports come with actual data that we can compare over time. This idea is legacy/trac#23839.
This ticket is for pulling together one big-picture report. But once we have one, we will want to find ways of keeping ourselves up to date over time.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/web/tpo/-/issues/125Map link changes from current tpo to lektor projects2021-09-15T19:44:11ZtraumschuleMap link changes from current tpo to lektor projectsTo port tpo and wiki content to lektor it helps to document where content of current pages reappears and to concentrate scattered info a bit. This eventually can be useful for rewrite rules.
The goal is to create a list of pages with a ...To port tpo and wiki content to lektor it helps to document where content of current pages reappears and to concentrate scattered info a bit. This eventually can be useful for rewrite rules.
The goal is to create a list of pages with a link to the old and new locations.
* Overview: legacy/trac#21222, [[Website/MainSiteRedesign]]
* Sitemap: legacy/trac#10591, legacy/trac#25637, legacy/trac#25638
- legacy/trac#24131: https://torproject.org - outline: legacy/trac#22198, sitemap: legacy/trac#25637, legacy/trac#25638
- legacy/trac#24129: https://support.torproject.org - sketches: legacy/trac#22200
- [/projects/tor/query?status=!closed&component=Community%2FTor+Browser+Manual tb-manual]: https://tb-manual.torproject.org
- legacy/trac#24133: https://community.torproject.org - sketches: comment:5:issue:24133
- legacy/trac#24132: https://dev.torproject.org - structure: legacy/trac#22199
Previews: https://lektor-staging.torproject.org/https://gitlab.torproject.org/tpo/web/tpo/-/issues/81Incomplete Content-Security-Policy blocks video on "Set up Relays" page2022-07-09T04:26:24ZTracIncomplete Content-Security-Policy blocks video on "Set up Relays" pageAffected page: https://www.torproject.org/getinvolved/relays.html.en
Problem: "No video with supported format and MIME type found"
The video's URL is https://media.torproject.org/video/2012-03-04-BuildingBridges.ogv and forbidden by CSP...Affected page: https://www.torproject.org/getinvolved/relays.html.en
Problem: "No video with supported format and MIME type found"
The video's URL is https://media.torproject.org/video/2012-03-04-BuildingBridges.ogv and forbidden by CSP.
Solution: Change
```
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'
```
(https://www.hardenize.com/report/torproject.org/1544035352#www_csp)
to
```
Content-Security-Policy: default-src 'self'; style-src 'self' 'unsafe-inline'; media-src 'self' https://media.torproject.org
```
or even to
```
Content-Security-Policy: default-src 'self'; style-src 'self' 'unsafe-inline'; media-src 'self' https://media.torproject.org; frame-ancestors 'self'; block-all-mixed-content; disown-opener; plugin-types application/pdf; base-uri 'self'
```
**Trac**:
**Username**: darkspirithttps://gitlab.torproject.org/tpo/web/tpo/-/issues/127Add reproducible builds verification notes for Android to our verifying signa...2021-09-15T19:45:14ZGeorg KoppenAdd reproducible builds verification notes for Android to our verifying signature pageOn https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerification we outline how to make a link between the bundles we actually ship (including update files) to the artifacts one gets by following our reproducible builds ...On https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerification we outline how to make a link between the bundles we actually ship (including update files) to the artifacts one gets by following our reproducible builds path.
So far, this contains instructions for Linux and Windows bundles. macOS is tricky and dealt with in legacy/trac#18925.
This ticket is to add respective instructions for our .apk file(s) we ship.https://gitlab.torproject.org/tpo/core/tor/-/issues/29084Ensure circuit padding RTT estimate handes var cells/wide creates2023-06-15T10:31:27ZGeorge KadianakisEnsure circuit padding RTT estimate handes var cells/wide createsThe use_rtt_estimate field in the circuit padding machines lets machines offset the inter-packet delays by a middle-node estimated RTT value of packets that go from the middle to the exit/website.
We abort this measurement if we get two...The use_rtt_estimate field in the circuit padding machines lets machines offset the inter-packet delays by a middle-node estimated RTT value of packets that go from the middle to the exit/website.
We abort this measurement if we get two or more cells back-to-back in either direction, as this indicates that the half-duplex request/response circuit setup and RELAY_BEGIN sequence has finished.
However, if we switch to a multi-cell circuit handshake, then we will need to take that into account when measuring RTT.
If RELAY_EARLY is used only for the first cell of a multi-cell EXTEND2 payload,
then we can just count time between RELAY_EARLIES. But the proposal currently says MAY, but not MUST for this behavior.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/29111Optional heartbeat message from PT's2021-07-29T15:02:04ZAlexander Færøyahf@torproject.orgOptional heartbeat message from PT'sWould it make sense to have a specified `STATUS` message for Tor-style heartbeat messages for PT's?
When running a Tor relay/bridge it's useful to have the Tor heartbeat message to see the activity of your relay/bridge - maybe the same ...Would it make sense to have a specified `STATUS` message for Tor-style heartbeat messages for PT's?
When running a Tor relay/bridge it's useful to have the Tor heartbeat message to see the activity of your relay/bridge - maybe the same would make sense for PT's too.
Lame anecdotal note: I ran a test bridge for my quic-pt code and just received an email from someone who was using it. I was turning it off because I had an idea that nobody used it.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)https://gitlab.torproject.org/tpo/core/tor/-/issues/29220Update review guidelines to list best practices2021-07-22T16:19:43ZNick MathewsonUpdate review guidelines to list best practicesWhen we come up with some target guidelines in legacy/trac#29219 , we should make sure that our coding standards document them.When we come up with some target guidelines in legacy/trac#29219 , we should make sure that our coding standards document them.https://gitlab.torproject.org/tpo/core/tor/-/issues/29245Tor 0.4 eventually hits "Delaying directory fetches: No running bridges" afte...2023-08-01T23:52:42ZTracTor 0.4 eventually hits "Delaying directory fetches: No running bridges" after some period of inactivity with bridges```
Tor NOTICE: Delaying directory fetches: No running bridges
Tor NOTICE: Application request when we haven't received a consensus with exits. Optimistically trying known bridges again.
Tor NOTICE: Delaying directory fetches: No runni...```
Tor NOTICE: Delaying directory fetches: No running bridges
Tor NOTICE: Application request when we haven't received a consensus with exits. Optimistically trying known bridges again.
Tor NOTICE: Delaying directory fetches: No running bridges
Tor NOTICE: Application request when we haven't received a consensus with exits. Optimistically trying known bridges again.
Tor NOTICE: Delaying directory fetches: No running bridges
Tor NOTICE: Application request when we haven't received a consensus with exits. Optimistically trying known bridges again.
```
Tested on latest Tor Browser alpha with snowflake bridge.
**Trac**:
**Username**: ArmalsLoveArmalsLifeTor: unspecifiedhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/29296Look into alternatives for distributing bridge info to clients2021-07-29T15:03:24ZCecylia BocovichLook into alternatives for distributing bridge info to clientsThe traditional way of distributing bridge information is to give bridge IP/connection information through BridgeDB and add that information to the Tor Browser configuration.
Snowflake and meek handle "bridge" information differently at...The traditional way of distributing bridge information is to give bridge IP/connection information through BridgeDB and add that information to the Tor Browser configuration.
Snowflake and meek handle "bridge" information differently at the client side, and we might like to consider a broader application of the Snowflake/broker style of distributing bridges. To do so, we should look into what changes we need to make at the client side to make this distribution easier.Sponsor 30 - Objective 2.3https://gitlab.torproject.org/tpo/tpa/team/-/issues/29390Ask owners of all torproject.<ccTLD> to stop serving the zone2020-09-28T18:27:25ZLinus Nordberglinus@torproject.orgAsk owners of all torproject.<ccTLD> to stop serving the zoneThere are three torproject.<ccTLD> zones that we're aware of which are not in TPI's control. They are all pointing at our name servers.,
Ask them to kindly stop doing that but if possible please keep the domain registered for "some time...There are three torproject.<ccTLD> zones that we're aware of which are not in TPI's control. They are all pointing at our name servers.,
Ask them to kindly stop doing that but if possible please keep the domain registered for "some time". Dropping the DNS requests on the floor is fine.
* [x] #30670
* [ ] #30671
* [ ] #30672
* [x] #30673https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/29728Deprecate torflow2022-03-11T12:38:23ZjugaDeprecate torflowWhen we are happy with `sbws` as the bandwidth scanner implementation, we should add a line to Torflow README saying something like "Deprecated by sbws (url)".
We should also add that line to https://github.com/TheTorProject/bwscanner (t...When we are happy with `sbws` as the bandwidth scanner implementation, we should add a line to Torflow README saying something like "Deprecated by sbws (url)".
We should also add that line to https://github.com/TheTorProject/bwscanner (this repo might still be useful if/when `sbws` get refactored to use concurrency instead of multi-threading.
Maybe the git.tpo repository should be moved to `attic`.
Assigning to sbws component since we're not tracking torflowsbws: 1.4.x-finaljugajugahttps://gitlab.torproject.org/tpo/tpa/team/-/issues/29770mails relayed from lists.tpo to gmail.com bounces2022-07-09T04:32:13Zanarcatmails relayed from lists.tpo to gmail.com bouncesIt seems we're having trouble relaying mails to gmail.com and possibly other providers.
A similar question was raised by a tor-announce@ participant in `Message-ID: <CAHQQdjtuVj68EVw_TsnDGiTRj1bY7iyxuehUDj6bya=KAqE0MQ@mail.gmail.com>`
...It seems we're having trouble relaying mails to gmail.com and possibly other providers.
A similar question was raised by a tor-announce@ participant in `Message-ID: <CAHQQdjtuVj68EVw_TsnDGiTRj1bY7iyxuehUDj6bya=KAqE0MQ@mail.gmail.com>`
I myself had trouble sending mail to a @tpo account that is forwarded to gmail (bounce is `Message-ID: <20190311210933.9AB57E1B16@eugeni.torproject.org>`):
```
<target@gmail.com>: host gmail-smtp-in.l.google.com[64.233.167.26] said:
550-5.7.1 This message does not have authentication information or fails to
pass 550-5.7.1 authentication checks. To best protect our users from spam,
the 550-5.7.1 message has been blocked. Please visit 550-5.7.1
https://support.google.com/mail/answer/81126#authentication for more 550
5.7.1 information. f2si4120705wrj.403 - gsmtp (in reply to end of DATA
command)
```
I suspect this might have to do with (lack of) SPF records and/or ARC headers.Jens KubiezielJens Kubiezielhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/29838Update trac wiki pages where sbws should be listed2021-06-15T14:22:14ZjugaUpdate trac wiki pages where sbws should be listedAll the pages where it's listed: https://trac.torproject.org/projects/tor/search?q=torflow&noquickjump=1&wiki=on
For instance, include sbws in https://trac.torproject.org/projects/tor/wiki/org/projects
Remove torflow when bandwidth auth...All the pages where it's listed: https://trac.torproject.org/projects/tor/search?q=torflow&noquickjump=1&wiki=on
For instance, include sbws in https://trac.torproject.org/projects/tor/wiki/org/projects
Remove torflow when bandwidth authorities are happy with sbws.
Adding this in sbws as there's no component for trac pages.sbws: 1.2.x-finalhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/29864TPA-RFC-33: consider replacing nagios with prometheus2023-05-17T18:06:54ZanarcatTPA-RFC-33: consider replacing nagios with prometheusAs a followup to the Prometheus/Grafana setup started in #29681, I am wondering if we should also consider replacing the Nagios/Icinga server with Prometheus. I have done a little research on the subject and figured it might be good to a...As a followup to the Prometheus/Grafana setup started in #29681, I am wondering if we should also consider replacing the Nagios/Icinga server with Prometheus. I have done a little research on the subject and figured it might be good to at least document the current state of affairs.
This would remove a complex piece of architecture we have at TPO that was designed before Puppet was properly deployed. Prometheus has an interesting federated design that allows it to scale to multiple machines easily, along with a high availability component for the alertmanager that allows it to be more reliable than a traditionnal Nagios configuration. It would also simplify our architecture as the Nagios server automation is a complex mix of Debian packages and git hooks that is serving us well, but hard to comprehend and debug for new administrators. (I managed to wipe the entire Nagios config myself on my first week on the job by messing up a configuration file.) Having the monitoring server fully deployed by Puppet would be a huge improvement, even if it would be done with Nagios instead of Prometheus, of course.
Right now the Nagios server is actually running Icinga 1.13, a Nagios fork, on a heztner machine (`hetzner-hel1-01`). It's doing its job generally well although it feels a *little* noisy, but that's to be expected form Nagios servers. Reducing the number of alerts seems to be an objective, explicitely documented in #29410, for example.
Both Grafana and Prometheus can do alerting, with various mechanisms and plugins. I haven't investigated those deeply, but in general that's not a problem in alerting: you fire some script or API and the rest happens. I suspect we could port the current Nagios alerting scripts to Prometheus fairly easily, although I haven't investigated our scripts in details.
The problem is reproducing the check scripts and their associated alert threshold. In the Nagios world, when a check is installed, it *comes* with its own health ("OK", "WARNING", "CRITICAL") threshold and TPO has developed a wide variety of such checks. According to the current Nagios dashboard, it monitors 4612 services on 88 hosts (which is interesting considering LDAP thinks there are 78). That looks terrifying, but it's actually a set of 9 commands running on the Nagios server, including the complex `check_nrpe` system, which is basically a client-side nagios that has its own set of checks. And that's where the "cardinal explosion" happens: on a typical host, there are 315 such checks implemented.
That's the hard part: convert those 324 checks into Prometheus alerts, one at a time. Unfortunately, there are no "built-in" or even "third-party" "prometheus alert sets" that I could find in my [original research](https://anarc.at/blog/2018-01-17-monitoring-prometheus/), although that might have changed in the last year.
Each check in Prometheus is basically a YAML file describing a Prometheus query that, when it evaluates to "true" (e.g. disk_space > 90%), sends an alert. It's not impossible to do that conversion, it's just a lot of work.
To do this progressively while allowing us to make new alerts on Prometheus instead of Nagios, I suggest to proceed the same way Cloudflare did, which is to establish a "Nagios to Prometheus" bridge, by which Nagios doesn't send the alerts on its own and instead forwards them to the Prometheus server, a plugin they called [Promsaint](https://github.com/cloudflare/promsaint).
With the bridge in place, Nagios checks can be migrated into Prometheus alerts progressively without disruption. Note that Cloudflare documented their experience with Prometheus in [this 2017 promcon talk](https://promcon.io/2017-munich/talks/monitoring-cloudflares-planet-scale-edge-network-with-prometheus/). Cloudflare also made an alert dashboard called [unsee](https://github.com/cloudflare/unsee) (see also the fork called [karma](https://github.com/prymitive/karma)) and [elasticsearch integration](https://github.com/cloudflare/alertmanager2es) which might be good to investigate further.
Another useful piece is this [NRPE to Prometheus exporter](https://www.robustperception.io/nagios-nrpe-prometheus-exporter), which allows Prometheus to directly scrape NRPE targets. It doesn't include Prometheus alerts and instead relies on a Grafana dashboard to show possible problems so, as such, I don't think it's that useful an alternative. There's a [similar approach using check_mk](https://github.com/m-lab/prometheus-nagios-exporter) instead.
Another possible approach is to send alerts from Nagios based on Prometheus checks, using the [Prometheus nagios plugins](https://github.com/prometheus/nagios_plugins). This might allow us to get rid of NRPE everywhere but it would probably be useful only if we do want to keep Nagios in the long term and remove NRPE in favor of the existing Prometheus exporters.
So, battle plan is basically this:
1. `apt install prometheus-alertmanager`
2. reimplement the Nagios alerting commands
3. send Nagios alerts through the alertmanager
4. rewrite (non-NRPE) commands (9) as Prometheus alerts
5. optionnally, scrape the NRPE metrics from Prometheus
6. optionnally, create a dashboard and/or alerts for the NRPE metrics
7. rewrite NRPE commands (300+) as Prometheus alerts
8. turn off the Nagios server
9. remove all traces of NRPE on all nodes
Update: this, obviously, will require more discussion than just implementing the above battle plan, as there isn't a consensus in the team towards Prometheus as a replacement for Icinga. I have assigned TPA-RFC-33 to this and started drafting requirements and personas in #40755Debian 11 bullseye upgradeanarcatanarcat2022-09-01https://gitlab.torproject.org/tpo/web/tpo/-/issues/149lektor portals: Titles should not be capitalized in the CSS2022-07-09T04:26:24Zemmapeellektor portals: Titles should not be capitalized in the CSSDifferent languages have different rules for capitalization. So we should not hardcode capitalize, lowercase or uppercase in the CSS.
We should propose the string in all caps to translate and let translators decide on how to write it on...Different languages have different rules for capitalization. So we should not hardcode capitalize, lowercase or uppercase in the CSS.
We should propose the string in all caps to translate and let translators decide on how to write it on their different languages.
For example, https://tb-manual.torproject.org/el/ should not capitalize the titles, as in Greek the accentuation rules are different if you write all in caps.
Also in French it does look weird, as for example the title `Comment les services oignon fonctionnent-ils ?' at https://lektor-staging.torproject.org/community/translations/fr/onion-services/overview/
thanks papassadrian for the report!Sponsor 9 - Phase 5 - Usability and Community Intervention on Support for Democracy and Human Rightshttps://gitlab.torproject.org/tpo/web/tpo/-/issues/5The navigation bar items are not getting translated2021-08-31T18:08:58ZHiroThe navigation bar items are not getting translatedI am not sure how or why, and i cannot reproduce the problem in my local setup, but the titles after 'About' in the navigation bar are not translated on tpo.
Documentation, Support, Blog, and Donate stay in English.
(It may be related ...I am not sure how or why, and i cannot reproduce the problem in my local setup, but the titles after 'About' in the navigation bar are not translated on tpo.
Documentation, Support, Blog, and Donate stay in English.
(It may be related to the fact that those words are not extracted automatically by lektor from the databags, and I generate them with a local file that is not commited to the repo)
From: https://trac.torproject.org/projects/tor/ticket/30158https://gitlab.torproject.org/tpo/web/tpo/-/issues/8fix broken URLs in tor-exit-notice.html2020-11-23T14:56:47ZHirofix broken URLs in tor-exit-notice.htmlThe recent website update causes 404 in the tor-exit-notice.html file
https://gitweb.torproject.org/tor.git/plain/contrib/operator-tools/tor-exit-notice.html
the fix is easy: just add 2019. at the beginning of the domain.
You might a...The recent website update causes 404 in the tor-exit-notice.html file
https://gitweb.torproject.org/tor.git/plain/contrib/operator-tools/tor-exit-notice.html
the fix is easy: just add 2019. at the beginning of the domain.
You might also want to enable some redirections on the current website since this html file is widely deployed by exit operators.
Comment by teor:
```
The correct way to fix this issue is to fix the tor website.
We need website redirects for all the resources in:
https://gitweb.torproject.org/tor.git/plain/contrib/operator-tools/tor-exit-notice.html
Let us know if there are any resources that you can't redirect on the website, and we'll fix them in Tor.
```
From: https://trac.torproject.org/projects/tor/ticket/30052https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/4630152: Monitor GetTor statistics2022-07-07T11:58:26ZHiro30152: Monitor GetTor statisticsWe should make sure logs are logrotated before being deleted and we should collect aggregated stats about services and languages requested.
- [ ] make sure that the exported csv is not getting deleted
- [ ] sanitize csv to be sure that ...We should make sure logs are logrotated before being deleted and we should collect aggregated stats about services and languages requested.
- [ ] make sure that the exported csv is not getting deleted
- [ ] sanitize csv to be sure that is safe for collectormeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/web/tpo/-/issues/17Add new locales to Languages Download Page2020-11-23T14:56:47ZPili GuerraAdd new locales to Languages Download Page[09:17:32] <emmapeel> there are new locales on the stable release, maybe we can publicize them: Czeck, Greek, Es-Ar, Magyar (hu), Georgian,
[09:18:36] <emmapeel> they need to be aded to https://www.torproject.org/download/languages/[09:17:32] <emmapeel> there are new locales on the stable release, maybe we can publicize them: Czeck, Greek, Es-Ar, Magyar (hu), Georgian,
[09:18:36] <emmapeel> they need to be aded to https://www.torproject.org/download/languages/