The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-11-13T14:54:16Zhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1068arti binary: Example config file should be referred to from help output2023-11-13T14:54:16ZIan Jacksoniwj@torproject.orgarti binary: Example config file should be referred to from help output```
-c, --config <FILE>
Specify which config file(s) to read. Defaults to
[File("/home/rustcargo/.config/arti/arti.toml"),
Dir("/home/rustcargo/.config/arti/arti.d/")]
```
This should mention the ...```
-c, --config <FILE>
Specify which config file(s) to read. Defaults to
[File("/home/rustcargo/.config/arti/arti.toml"),
Dir("/home/rustcargo/.config/arti/arti.d/")]
```
This should mention the example config file!Arti: Feature parity with the C implementationIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/1067Implement client part of prop340: packed and fragmented relay messages2024-03-14T19:43:15ZJim NewsomeImplement client part of prop340: packed and fragmented relay messages[prop340]
Draft implementation plan:
* [x] Finish [ntorv3 (prop332)](https://spec.torproject.org/proposals/332-ntor-v3-with-extra-data.html). #1084
* [ ] Implement negotiation for [prop340] itself. EDIT: spec for negotiation may be in...[prop340]
Draft implementation plan:
* [x] Finish [ntorv3 (prop332)](https://spec.torproject.org/proposals/332-ntor-v3-with-extra-data.html). #1084
* [ ] Implement negotiation for [prop340] itself. EDIT: spec for negotiation may be in flux, since current version in prop340 doesn't align with prop346; see https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/170. (Q: maybe also behind an "experimental" compile-time feature?)
* [ ] add new consensus and config parameter "UseRelayMessage", as specified in prop340
* [ ] add new subprotocol variant "RelayCell"
* [ ] add new ntorv3 extension types 3 and 4 "Relay Cell Protocol Request" and "Response"
* [ ] when enabled, and creating a circuit with a relay supporting ntorv3 (`Relay=4`) and the new cell format (`RelayCell=1`) (Q: or select only such relays?), request version 1 of in ntorv3 "Relay Cell Protocol Request"
* [ ] when enabled, and relay has advertised support, switch to prop340 cell format. (initially log an "unimplemented" error just to verify we get this far in integration testing and destroy the circuit)
* [ ] Implement the [prop340] new cell format. (e.g. omitting stream ID instead of setting it to 0 etc)
* [x] Refactor `StreamId` to always be nonzero, replacing usage with `Option<StreamId>`. https://gitlab.torproject.org/tpo/core/arti/-/issues/1080
* [ ] Refactor to decouple cells from messages (#763+ and #775+)
* [ ] Implement packing
* [ ] Implement fragmentation
[prop340]: <https://spec.torproject.org/proposals/340-packed-and-fragmented.html>Jim NewsomeJim Newsomehttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/70Add support for Snowflake2024-03-27T17:31:16ZetaAdd support for SnowflakeThe current PT support only does obfs4. We probably want snowflake too.The current PT support only does obfs4. We probably want snowflake too.VPN pre-alpha 06Micah Elizabeth ScottMicah Elizabeth Scott2024-03-07https://gitlab.torproject.org/tpo/network-health/metrics/networkstatusapi/-/issues/8Review details endpoint2024-01-19T16:37:15ZHiroReview details endpoint@mattrighetti asked me to give a second review of the details endpoint and on closer look I found a few issues:
on https://gitlab.torproject.org/tpo/network-health/metrics/networkstatusapi/-/blame/dev/src/metrics/details.rs#L102
I woul...@mattrighetti asked me to give a second review of the details endpoint and on closer look I found a few issues:
on https://gitlab.torproject.org/tpo/network-health/metrics/networkstatusapi/-/blame/dev/src/metrics/details.rs#L102
I would remove all the joins. I think maybe to provide the network weights we could either query the latest network_status_entry_weights at the time of the server status (https://gitlab.torproject.org/tpo/network-health/metrics/metrics-sql-tables/-/blob/main/network_status_tables.sql?ref_type=heads#L70) or make a query to VM proxied, up to the server status time (we have both the weight and the fraction calculated from consensuses https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/blob/main/METRICS.md?ref_type=heads#from-consensuses).
For both relay and bridge what do we need from the server descriptor? I could add that directly into the status so we don't have to make a join query.Mattia RighettiMattia Righettihttps://gitlab.torproject.org/tpo/network-health/metrics/tagtor/-/issues/21Add total bw and per relay bw and consensus weight to the routers display2024-03-28T17:08:05ZGeorg KoppenAdd total bw and per relay bw and consensus weight to the routers displayWe want to know how much weight relays have and their advertised bandwidth. Those could be additional columns. Additionally, I think it's worth having the advertised bw visible for all the relays under a particular filter, which could be...We want to know how much weight relays have and their advertised bandwidth. Those could be additional columns. Additionally, I think it's worth having the advertised bw visible for all the relays under a particular filter, which could be displayed below the router/bridges table.TagTor is completed for its scope in Sponsor 112HiroHirohttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/28Set daily max bucket distribution and adjust other settings for production2024-02-15T16:52:09ZonyinyangSet daily max bucket distribution and adjust other settings for productionWe likely need to decide on an upper bound of buckets that can be distributed each day so that we don't run out of open invitation buckets. We currently have buckets being distributed to k users before a new bucket is used but if buckets...We likely need to decide on an upper bound of buckets that can be distributed each day so that we don't run out of open invitation buckets. We currently have buckets being distributed to k users before a new bucket is used but if buckets are continuously requested, we will eventually run out of buckets each day. These variables should be part of a configuration file for Lox.Lox Ready for Open Testing Callonyinyangonyinyanghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40832Memory consumption of Tor client is becoming difficult under iOS 50 MB RAM li...2023-10-09T15:34:54ZtlaMemory consumption of Tor client is becoming difficult under iOS 50 MB RAM limitation esp. during startup and with cached info### Summary
Evidence is gathering, that Tor under iOS' network extension memory limitation has trouble building circuits.
See https://github.com/guardianproject/orbot-apple/issues/71#issuecomment-1666818716 and comments before.
I'm pl...### Summary
Evidence is gathering, that Tor under iOS' network extension memory limitation has trouble building circuits.
See https://github.com/guardianproject/orbot-apple/issues/71#issuecomment-1666818716 and comments before.
I'm playing around with `MaxMemInQueues`, but as soon as I uppen it just a little from the 5MB we currently use, Jetsam starts to kill the Network Extension during startup circuit building. (At least in my Austrian environment.)
Starting with cashed information seems to become more and more difficult, too. I already had to put a "clear cache" button at the main screen, because people started to complain so much.
I witness this too, now, more and more often.
Do you see any possibility to reduce non-file-backed memory consumption during the startup phase?
If this continues to worsen, it will render Orbot iOS unusable.
I'm not sure if this is happening due to changes in the network or due to changes in the client code.
If this doesn't get better I will need to consider downgrading Tor to older versions again.
Esp. since I currently released Onion Browser version 3, which now relies on Orbot iOS completely and which currently makes a lot of users unhappy.
There's certain loopholes to the memory accounting in iOS. In this older article I wrote, there's some background to the Jetsam memory accounting:
https://benjaminerhart.com/2018/03/state-of-the-onion-ios/
Esp. helpful might be these:
- Use file-backed memory / operate on/stream files directly instead of loading everything and juggling that data around a lot. (Maybe we can do that in callbacks we can implement with Objective-C to make use of `NSCache`/`NSPurgableData` objects.)
- Provide a method which makes Tor give up unused memory. We could call that from a hook iOS provides.
### Steps to reproduce:
1. Install Orbot iOS
2. Start Orbot
3. Witness Tor protocol using left top button.
4. If under censored environment, Tor might not be able to build usable circuits at all, because `MaxMemInQueues` is set to 5 MByte.
5. Override and increase `MaxMemInQueues` in advanced settings.
6. Witness Network Extension crash during start. (App will show stopped status after a while.)
7. In non-restraint environments, manage a complete start. Confirm by surfing to check.torproject.org.
8. Stop Orbot.
9. Restart Orbot.
10. Restart will fail most of the time until "Clear Cache" is pressed.
### What is the current bug behavior?
### What is the expected behavior?
- Tor limits memory usage during startup phase, so we can increase `MaxMemInQueues`, so constrained environments work, too.
- Tor limits memory usage during loading of cached information, so it doesn't reach the 50 MB memory limit.
### Environment
| | |
|:-------- | --------:|
| tor | 0.4.7.13 |
| libevent | 2.1.12 |
| OpenSSL | 1.1.1u |
| liblzma | 5.4.3 |
iOS 16.6. using [Tor.framework](https://github.com/iCepa/Tor.framework/)
### Relevant logs and/or screenshots
https://github.com/guardianproject/orbot-apple/issues/71#issuecomment-1657738391
https://github.com/guardianproject/orbot-apple/issues/71#issuecomment-1666818716
### Possible fixesTor: 0.4.9.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40830Non-fatal assertion now >= leg->link_sent_usec failed2023-11-06T14:50:08ZVortNon-fatal assertion now >= leg->link_sent_usec failed### Summary
Sometimes I see such lines in log:
```
Aug 03 03:40:28.000 [warn] tor_bug_occurred_: Bug: conflux_pool.c:828: record_rtt_client: Non-fatal assertion now >= leg->link_sent_usec failed. (on Tor 0.4.8.2-alpha 328f976245134501)
...### Summary
Sometimes I see such lines in log:
```
Aug 03 03:40:28.000 [warn] tor_bug_occurred_: Bug: conflux_pool.c:828: record_rtt_client: Non-fatal assertion now >= leg->link_sent_usec failed. (on Tor 0.4.8.2-alpha 328f976245134501)
Aug 03 03:40:28.000 [warn] Bug: Tor 0.4.8.2-alpha (git-328f976245134501): Non-fatal assertion now >= leg->link_sent_usec failed in record_rtt_client at conflux_pool.c:828. (Stack trace not available) (on Tor 0.4.8.2-alpha 328f976245134501)
```
### Steps to reproduce:
Looks like it appears randomly.
However I have ntpd installed, maybe it interferes with Tor somehow.
### What is the current bug behavior?
Error shows.
### What is the expected behavior?
No error.
### Environment
_- Which version of Tor are you using?_
Tor 0.4.8.2-alpha (git-328f976245134501) running on Windows 7 with Libevent 2.1.12-stable, OpenSSL 3.0.8, Zlib 1.2.13, Liblzma 5.4.1, Libzstd 1.5.4 and Unknown N/A as libc.
_- Which operating system are you using?_
Windows 7 SP1 x64
_- Which installation method did you use?_
I built Tor from sources.
### Relevant logs and/or screenshots
I saw such problem two more times:
```
Jul 24 03:15:14.000 [warn] tor_bug_occurred_: Bug: conflux_pool.c:828: record_rtt_client: Non-fatal assertion now >= leg->link_sent_usec failed. (on Tor 0.4.8.2-alpha 328f976245134501)
Jul 24 03:15:14.000 [warn] Bug: Tor 0.4.8.2-alpha (git-328f976245134501): Non-fatal assertion now >= leg->link_sent_usec failed in record_rtt_client at conflux_pool.c:828. (Stack trace not available) (on Tor 0.4.8.2-alpha 328f976245134501)
...
Jul 24 18:16:48.000 [warn] tor_bug_occurred_: Bug: conflux_pool.c:828: record_rtt_client: Non-fatal assertion now >= leg->link_sent_usec failed. (on Tor 0.4.8.2-alpha 328f976245134501)
Jul 24 18:16:48.000 [warn] Bug: Tor 0.4.8.2-alpha (git-328f976245134501): Non-fatal assertion now >= leg->link_sent_usec failed in record_rtt_client at conflux_pool.c:828. (Stack trace not available) (on Tor 0.4.8.2-alpha 328f976245134501)
```
### Possible fixeshttps://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/4Add new calendar that accommodate time before 8 PM UTC2023-08-04T00:17:51ZharletaAdd new calendar that accommodate time before 8 PM UTChttps://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/3#note_2928598https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/3#note_2928598harletaharleta2023-08-07https://gitlab.torproject.org/tpo/web/donate-static/-/issues/119Meta ticket: donate rewrite backend MVP2024-03-19T00:06:03ZKezMeta ticket: donate rewrite backend MVPSplitting off from #111
## MVP for backend
- [ ] Handle stripe donations
- [ ] pick new stripe checkout flow. our current stripe checkout system is deprecated, we'll need to decide on the correct flow to use for the new site
- [ ] ...Splitting off from #111
## MVP for backend
- [ ] Handle stripe donations
- [ ] pick new stripe checkout flow. our current stripe checkout system is deprecated, we'll need to decide on the correct flow to use for the new site
- [ ] implement the new flow in the backend (single and recurring donations), expose a very basic frontend for testing stripe checkout
- [ ] Handle paypal donations on the backend
- [ ] audit current paypal checkout flow, ensure that we don't have issues like our stripe checkout
- [ ] implement paypal checkout, single and recurring donations
- [x] List wallet addresses - django setup, yes (tpo/web/donate-neo!1)
- [x] A link to BTCPay (non-integrated) - django setup, yes (tpo/web/donate-neo!3)
- [x] Noscript error - django setup, yes (tpo/web/donate-neo!4)
- [ ] CRM integration (that meets Fundraising's specs)
- [ ] Newsletter signup
- [ ] report donations to civi
- [ ] query current perks from civi
- [x] Donation amount array
- [x] Swag display & logic (+ ability to decline swag)
- [x] CAPTCHA
- [x] Simple YEC Ticker (tpo/web/donate-neo!6)
- [x] Simple order summary (tpo/web/donate-neo!7)
- [x] Redirect to existing thank you page? maybe? or a simple version for the MVP
## Post-MVP
- Ability to track donations made directly through paypal (not through donate.tpo) and report them to civi ([tpo/anti-censorship/pluggable-transports/snowflake-webext#79](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/79#note_2898912)). this can be implemented in the backend with paypal webhooks.
- CMSable/lektorable content [e.g., ability to make new/standalone pages] (possibly with wagtail?)Redesign donate.torproject.orgstephenstephenhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41919Add a message, tooltip or icon to explain letterboxing2024-03-11T15:49:36Zma1Add a message, tooltip or icon to explain letterboxingWhile we're trying to make the letterboxing appearance look more intentional, we may want also to let user easily access an explanation of what it is.
Possible (alternative or combined) approaches variously surfaced in parent #32324:
1...While we're trying to make the letterboxing appearance look more intentional, we may want also to let user easily access an explanation of what it is.
Possible (alternative or combined) approaches variously surfaced in parent #32324:
1. Informative tooltip when user hovers the letterboxing area
2. "?" shaped cursor, making the letterboxing area clickable to open the relevant manual section (or the options page if/when
#41916 gets implemented)
3. "?" button appearing somewhere in the letterboxing area when there's enough space, instead of making the whole area clickable.
/cc @ruihildt, @thorinma1ma1https://gitlab.torproject.org/tpo/core/arti/-/issues/966hsclient descriptor download due to IPT nacks2023-11-14T16:43:40ZIan Jacksoniwj@torproject.orghsclient descriptor download due to IPT nacksAs per https://gitlab.torproject.org/tpo/core/arti/-/issues/913#note_2914467, Arti's current HS client behaviour wrt the service descriptor is:
> Ie if it's not expired we assume it's still good to use, even if we are making repeated at...As per https://gitlab.torproject.org/tpo/core/arti/-/issues/913#note_2914467, Arti's current HS client behaviour wrt the service descriptor is:
> Ie if it's not expired we assume it's still good to use, even if we are making repeated attempts to connect to the HS - with that descriptor - and they're all failing.
I am informed on IRC that the confirmation there, that this is correct behaviour, was due to a misunderstanding. This behaviour is in fact wrong.
If Arti gets NACKs from the IPTs, it needs to re-download the descriptor. (The service may have been restarted and our descriptor may therefore be out of date.)
In more detail:
* At some threshold of NACKs from IPTs, Arti should re-download the descriptor.
* If it manages to obtain a different descriptor it should try the IPTs in the new descriptor instead.
* "different" and "new" is according to the revision counter in the descriptor.
It's not clear precisely how hard Arti should try to obtain a different descriptor. After all, the service may not have managed to update all the hsdirs. So maybe Arti should try several.
Details of the correct retry algorithm aren't clear. Ideally the overall system would have the following properties:
* Restarting an HS service can be done without generating a persistent loss of availability on clients
* Faulty hsdirs don't cause loss of availability provided there are enough working hsdirs
* Trouble from faulty relays or "bad weather" isn't "magnified" by the hsdir/descriptor system
*This* ticket represents the required changes to Arti's client behaviour. There are also implications for the work-in-progress server-side work, eg !1429
CC @nickm @dgouletArti: Feature parity with the C implementationIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/lox/-/issues/24Implement Metrics Reporting for Lox2023-10-31T21:19:34ZonyinyangImplement Metrics Reporting for LoxFrom the [Lox Roadmap](https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/wikis/Lox-Roadmap) we want to include strategic reporting of metrics in our Lox deployment so that we are able to determine the effectiveness of Lox. The m...From the [Lox Roadmap](https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/wikis/Lox-Roadmap) we want to include strategic reporting of metrics in our Lox deployment so that we are able to determine the effectiveness of Lox. The minimum metrics to measure are the following:
- [x] Prometheus metrics for counts of how often each library function is called from distributor
- [ ] How many bridges are in each rank
- [ ] Blockages from deployed bridgestrap instance
- [x] Remaining capacity (or if/when we run out of bridges to hand out to open inv)
Discussion, development of these and additional metrics to include in the initial deployment will be tracked in this issue.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/community/training/-/issues/113Add training resources to portal2024-03-25T11:29:34ZrayaAdd training resources to portalList of updates/additions:
- [ ] Update [All About Tor](https://docs.google.com/presentation/d/1BKpeDXqHib4zOQeGRBeFYWVYUtFNSwd-FLCY63TMDG8/edit)
- [ ] Update [Introduction to Onion Services](https://docs.google.com/presentation/d/1avHPN...List of updates/additions:
- [ ] Update [All About Tor](https://docs.google.com/presentation/d/1BKpeDXqHib4zOQeGRBeFYWVYUtFNSwd-FLCY63TMDG8/edit)
- [ ] Update [Introduction to Onion Services](https://docs.google.com/presentation/d/1avHPNzMhC5KJShtxAxe2Sl_KbQSrgG6yltdzHCEOfV0/edit)
- [ ] Add [Bypassing Censorship with and of Tor](https://docs.google.com/presentation/d/1f7IWy6rBoXffmAJPGxGSqCZvChlYJ012-E3a8mldbcM/edit)
- [ ] Add [YouTube videos](https://www.youtube.com/watch?v=uroe-xe0tcM)
- [ ] Add [Digital Security Basics](https://docs.google.com/presentation/d/1-uhiYwU1QNCYRuyJuacxKj2GLHvUWQ_Hcjz730IZqiM/edit?usp=sharing)
- [ ] Add licensing information on all training resources, see: https://gitlab.torproject.org/tpo/community/training/-/issues/74rayaraya2023-11-14https://gitlab.torproject.org/tpo/web/snowflake/-/issues/3Basic front-end development for snowflake.torproject.org2024-03-06T13:40:23ZAshish SoniBasic front-end development for snowflake.torproject.orgConvert the design( #2) into code for a new landing page. Using HTML, CSS, BootStrap 5.3.0v integrated with lektor.
TO-DOs
* [x] Code Section - 1 (get-snowflake)
* [x] Code Section - 2 (use-snowflake)
* [x] Code Section - 3 (donate-ban...Convert the design( #2) into code for a new landing page. Using HTML, CSS, BootStrap 5.3.0v integrated with lektor.
TO-DOs
* [x] Code Section - 1 (get-snowflake)
* [x] Code Section - 2 (use-snowflake)
* [x] Code Section - 3 (donate-bandwidth)
* [x] Code Section - 4 (faqs)
* [x] Add Navbar
* [x] Make Website Responsive
* [ ] Multilingual SupportAshish SoniAshish Sonihttps://gitlab.torproject.org/tpo/network-health/team/-/issues/313Develop design sketch and prototype for bandwidth inflation detection tool2024-03-19T08:33:09ZGeorg KoppenDevelop design sketch and prototype for bandwidth inflation detection toolWe want to be able to detect bandwidth lying by operators on the network. This ticket is the parent ticket for related tasks (which might need to be done in different projects) and could be used for sketching and sorting out all the desi...We want to be able to detect bandwidth lying by operators on the network. This ticket is the parent ticket for related tasks (which might need to be done in different projects) and could be used for sketching and sorting out all the design details.jugajugahttps://gitlab.torproject.org/tpo/community/support/-/issues/40118Update privacy policy on the Tor Forum2024-03-26T02:49:50Zebanamebanam@torproject.orgUpdate privacy policy on the Tor ForumAs pointed out in the latest (24 June 2023) relay operators' meetup, as we are now self-hosting the [Tor Forum](https://forum.torproject.org), we should update the [privacy policy](https://forum.torproject.org/privacy).
/cc @gusAs pointed out in the latest (24 June 2023) relay operators' meetup, as we are now self-hosting the [Tor Forum](https://forum.torproject.org), we should update the [privacy policy](https://forum.torproject.org/privacy).
/cc @gusGusGushttps://gitlab.torproject.org/tpo/team/-/issues/186Code Audit for Sponsor 1012024-03-19T18:04:53ZGabagaba@torproject.orgCode Audit for Sponsor 101- [x] Create RFPT
- [ ] Send to DRL for approval
- [ ] Send to auditors
- [ ] Choose an auditor to start work- [x] Create RFPT
- [ ] Send to DRL for approval
- [ ] Send to auditors
- [ ] Choose an auditor to start workGabagaba@torproject.orgGabagaba@torproject.org2024-03-20https://gitlab.torproject.org/tpo/community/l10n/-/issues/40111Translate Tor Browser Manual to Albanian, Belarusian, Bulgarian, Chinese Sim...2024-03-28T14:03:17ZemmapeelTranslate Tor Browser Manual to Albanian, Belarusian, Bulgarian, Chinese Simplified, Chinese Traditional (TW),Georgian, Hungarian, Indonesian, Korean, Macedonian, Pashto, Romanian, Russian, Thai, and Wolof* Albanian <a href="https://hosted.weblate.org/projects/tor/tor-browser/tor-browser-user-manual/sq/"><img src="https://hosted.weblate.org/widget/tor/tor-browser/tor-browser-user-manual/sq/svg-badge.svg" alt="Translation status" /></a>
* ...* Albanian <a href="https://hosted.weblate.org/projects/tor/tor-browser/tor-browser-user-manual/sq/"><img src="https://hosted.weblate.org/widget/tor/tor-browser/tor-browser-user-manual/sq/svg-badge.svg" alt="Translation status" /></a>
* Belarusian <a href="https://hosted.weblate.org/projects/tor/tor-browser/tor-browser-user-manual/be/"><img src="https://hosted.weblate.org/widget/tor/tor-browser/tor-browser-user-manual/be/svg-badge.svg" alt="Translation status" /></a>
* Bulgarian <a href="https://hosted.weblate.org/projects/tor/tor-browser/tor-browser-user-manual/bg/"><img src="https://hosted.weblate.org/widget/tor/tor-browser/tor-browser-user-manual/bg/svg-badge.svg" alt="Translation status" /></a>
* Chinese Simplified <a href="https://hosted.weblate.org/projects/tor/tor-browser/tor-browser-user-manual/zh_Hans/"><img src="https://hosted.weblate.org/widget/tor/tor-browser/tor-browser-user-manual/zh_Hans/svg-badge.svg" alt="Translation status" /></a>
* Chinese Traditional (TW) <a href="https://hosted.weblate.org/projects/tor/tor-browser/tor-browser-user-manual/zh_Hant/"><img src="https://hosted.weblate.org/widget/tor/tor-browser/tor-browser-user-manual/zh_Hant/svg-badge.svg" alt="Translation status" /></a>
* Georgian <a href="https://hosted.weblate.org/projects/tor/tor-browser/tor-browser-user-manual/ka/"><img src="https://hosted.weblate.org/widget/tor/tor-browser/tor-browser-user-manual/ka/svg-badge.svg" alt="Translation status" /></a>
* Hungarian <a href="https://hosted.weblate.org/projects/tor/tor-browser/tor-browser-user-manual/hu/"><img src="https://hosted.weblate.org/widget/tor/tor-browser/tor-browser-user-manual/hu/svg-badge.svg" alt="Translation status" /></a>
* Indonesian <a href="https://hosted.weblate.org/projects/tor/tor-browser/tor-browser-user-manual/id/"><img src="https://hosted.weblate.org/widget/tor/tor-browser/tor-browser-user-manual/id/svg-badge.svg" alt="Translation status" /></a>
* Korean <a href="https://hosted.weblate.org/projects/tor/tor-browser/tor-browser-user-manual/ko/"><img src="https://hosted.weblate.org/widget/tor/tor-browser/tor-browser-user-manual/ko/svg-badge.svg" alt="Translation status" /></a>
* Macedonian <a href="https://hosted.weblate.org/projects/tor/tor-browser/tor-browser-user-manual/mk/"><img src="https://hosted.weblate.org/widget/tor/tor-browser/tor-browser-user-manual/mk/svg-badge.svg" alt="Translation status" /></a>
* Pashto <a href="https://hosted.weblate.org/projects/tor/tor-browser/tor-browser-user-manual/pa/"><img src="https://hosted.weblate.org/widget/tor/tor-browser/tor-browser-user-manual/pa/svg-badge.svg" alt="Translation status" /></a>
* Romanian <a href="https://hosted.weblate.org/projects/tor/tor-browser/tor-browser-user-manual/ro/"><img src="https://hosted.weblate.org/widget/tor/tor-browser/tor-browser-user-manual/ro/svg-badge.svg" alt="Translation status" /></a>
* Russian <a href="https://hosted.weblate.org/projects/tor/tor-browser/tor-browser-user-manual/ru/"><img src="https://hosted.weblate.org/widget/tor/tor-browser/tor-browser-user-manual/ru/svg-badge.svg" alt="Translation status" /></a>
* Thai <a href="https://hosted.weblate.org/projects/tor/tor-browser/tor-browser-user-manual/th/"><img src="https://hosted.weblate.org/widget/tor/tor-browser/tor-browser-user-manual/th/svg-badge.svg" alt="Translation status" /></a>
* Wolof <a href="https://hosted.weblate.org/projects/tor/tor-browser/tor-browser-user-manual/wo/"><img src="https://hosted.weblate.org/widget/tor/tor-browser/tor-browser-user-manual/wo/svg-badge.svg" alt="Translation status" /></a>
~emmapeelemmapeelhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41172Monitor the system event log on gnt-dal nodes2024-03-28T15:25:05ZJérôme Charaouilavamind@torproject.orgMonitor the system event log on gnt-dal nodesWe should be monitoring the system event logs (SEL) on our Supermicro gnt-dal nodes.
This will allow us to receive alerts related the chassis intrusion detection mechanism, power supply, cooling and environmental sensors.We should be monitoring the system event logs (SEL) on our Supermicro gnt-dal nodes.
This will allow us to receive alerts related the chassis intrusion detection mechanism, power supply, cooling and environmental sensors.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org