The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-06-16T16:59:33Zhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40299Please extend PGP/GPG subkey for torbrowser@tpo (0x4E2C6E8793298290)2021-06-16T16:59:33ZRoger ShimizuPlease extend PGP/GPG subkey for torbrowser@tpo (0x4E2C6E8793298290)PGP/GPG subkey for torbrowser@tpo (0x4E2C6E8793298290) expired already on last Saturday, June/12.
And I also tried to refresh the key by using a few well-known key servers, and found it's not updated.
```
$ gpg --keyserver hkps://hkps.p...PGP/GPG subkey for torbrowser@tpo (0x4E2C6E8793298290) expired already on last Saturday, June/12.
And I also tried to refresh the key by using a few well-known key servers, and found it's not updated.
```
$ gpg --keyserver hkps://hkps.pool.sks-keyservers.net --keyserver-options self-sigs-only --refresh-keys 0x4E2C6E8793298290
gpg: refreshing 1 key from hkps://hkps.pool.sks-keyservers.net
gpg: key 0x4E2C6E8793298290: number of dropped non-self-signatures: 121456
gpg: pub rsa4096/0x4E2C6E8793298290 2014-12-15 Tor Browser Developers (signing key) <torbrowser@torproject.org>
gpg: key 0x4E2C6E8793298290: 12 duplicate signatures removed
gpg: key 0x4E2C6E8793298290: 2 signatures reordered
gpg: key 0x4E2C6E8793298290/0x7017ADCEF65C2036: removed multiple subkey binding
gpg: key 0x4E2C6E8793298290/0x2E1AC68ED40814E0: removed multiple subkey binding
gpg: key 0x4E2C6E8793298290/0xEB774491D9FF06E2: removed multiple subkey binding
gpg: Note: signature key 0xD1483FA6C3C07136 expired Fri 24 Aug 2018 08:26:24 PM JST
gpg: Note: signature key 0xEB774491D9FF06E2 expired Sat 12 Jun 2021 11:35:23 AM JST
gpg: Note: signature key 0x2E1AC68ED40814E0 expired Fri 25 Aug 2017 08:26:30 PM JST
gpg: Note: signature key 0x7017ADCEF65C2036 expired Fri 25 Aug 2017 08:23:23 PM JST
gpg: Note: signature key 0x2D000988589839A3 has been revoked
gpg: key 0x4E2C6E8793298290: "Tor Browser Developers (signing key) <torbrowser@torproject.org>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
```
So currently there's only valid subkey for certification, but no valid subkey for signature:
```
$ gpg -k 0x4E2C6E8793298290
pub rsa4096/0x4E2C6E8793298290 2014-12-15 [C] [expires: 2025-07-21]
Key fingerprint = EF6E 286D DA85 EA2A 4BA7 DE68 4E2C 6E87 9329 8290
uid [ unknown] Tor Browser Developers (signing key) <torbrowser@torproject.org>
```
And there're quite a few issue reports that failed to get TBB installed:
- https://github.com/micahflee/torbrowser-launcher/issues/562
- https://github.com/micahflee/torbrowser-launcher/issues/563
- https://github.com/micahflee/torbrowser-launcher/issues/564
- https://github.com/micahflee/torbrowser-launcher/issues/565
- https://github.com/micahflee/torbrowser-launcher/issues/566
- https://github.com/micahflee/torbrowser-launcher/issues/567
- https://github.com/micahflee/torbrowser-launcher/issues/569
I hope this key update can be fixed soon. Thank you!Gabagaba@torproject.orgGabagaba@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40105establish 2021 roadmap2021-06-16T20:17:57Zanarcatestablish 2021 roadmapWe should make a roadmap for 2021. This could be either milestones in GitLab, or a roadmap page in the wiki, something like:
https://trac.torproject.org/projects/tor/wiki/org/teams/SysadminTeam
or the original, non-trac roadmap from th...We should make a roadmap for 2021. This could be either milestones in GitLab, or a roadmap page in the wiki, something like:
https://trac.torproject.org/projects/tor/wiki/org/teams/SysadminTeam
or the original, non-trac roadmap from the wiki:
https://gitlab.torproject.org/tpo/tpa/wiki-replica/-/blob/e5e84236b5072cb28f630b1ab62bcc32f8163903/tsa/roadmap/2020.mdwn
It's unclear to me how we'll make a roadmap for next year. Month-per-month long-term planning did not seem to work, or at least we definitely stopped tracking that after summer (although that could be due to the GitLab migration). I still think it would be wise to setup larger goals in the roadmap and not get tangled up in smaller details.
We should use the survey data (#40106) to prioritize the work.
I hope to complete this in January, with the rest of the team of course (but I volunteer to bottomline this).anarcatanarcat2021-01-15https://gitlab.torproject.org/tpo/tpa/team/-/issues/40279Configure new server for Shadow experiments (chi-node-14)2021-06-16T20:25:30ZGabagaba@torproject.orgConfigure new server for Shadow experiments (chi-node-14)Please setup the new donated server the same as you did for [shadow 01](https://gitlab.torproject.org/tpo/tpa/team/-/issues/40248).
Dell PowerEdge R640 server with two Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz processors (40 cores total)...Please setup the new donated server the same as you did for [shadow 01](https://gitlab.torproject.org/tpo/tpa/team/-/issues/40248).
Dell PowerEdge R640 server with two Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz processors (40 cores total), 1536 GB of RAM, 2x 900GB SSD hard drives and an integrated Intel(R) X550 4-port 10G Ethernet NIC.
install checklist:
1. [x] BIOS upgrades (@lavamind)
* [x] Upgraded BIOS from 2.10.2 to [2.11.2](https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=92rfg&oscode=naa&productcode=poweredge-r640)
* [x] Upgraded iDRAC9 from 4.40.10.00 to [4.40.40.00](https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=1r1y2)
2. [x] burn-in (@lavamind):
* [x] Hardware Diagnostics mechanism integrated into the system's "Lifecycle controller"
* [x] memtest86 (stopped at test 13, no flaw found yet)
3. [x] BIOS configuration:
* [x] serial console access (@lavamind)
* [x] disable PXE (slows down boot)
* [x] SSH RACDM access (@lavamind)
* [x] admin iDRAC password change (@lavamind)
4. [x] automated install procedure from new-machine-cymru (@anarcat), missing:
* [x] <del>iSCSI servers access</del> (not necessary?)
5. [x] post-install procedure checklist
1. [x] partitions
1. [x] upgrades
1. [x] FQDN
1. [x] public IP
1. [x] hostname config
1. [x] working resolver
1. [x] root and LUKS passwords set in `tor-passwords.git`
6. [x] post-install procedure:
1. [x] add to spreadsheet
1. [x] tsa-misc
1. [x] ldap-vi
1. [x] alberti puppet
1. [x] bootstrap puppet
1. [x] reboot
1. [x] add to nagios
1. [x] dnswl (N/A)
1. [x] mandos
7. [x] CI runner setup (@anarcat)Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive placesJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-mobile/-/issues/11Design for final application UI.2021-06-17T14:14:01ZHashikDDesign for final application UI.Making and designing the final application UI.Making and designing the final application UI.Antonelaantonela@torproject.orgAntonelaantonela@torproject.orghttps://gitlab.torproject.org/tpo/community/outreach/-/issues/40005Ask volunteers to run emma in countries that are likely to block Tor2021-06-17T14:50:45ZPhilipp Winterphw@torproject.orgAsk volunteers to run emma in countries that are likely to block TorThe [Censored Planet paper](https://censorbib.nymity.ch/pdf/Raman2020c.pdf) recently got published. Appendix B.1 talks about blocking of our default bridges:
> Tor bridges are also blocked aggressively in Tanzania (seven bridges blocked)...The [Censored Planet paper](https://censorbib.nymity.ch/pdf/Raman2020c.pdf) recently got published. Appendix B.1 talks about blocking of our default bridges:
> Tor bridges are also blocked aggressively in Tanzania (seven bridges blocked), Venezuela (five bridges blocked) and Ukraine (five bridges blocked)
It would be helpful to find volunteers in Tanzania, Venezuela, and Ukraine to confirm these incidents.Sponsor 30 - Objective 2.2GusGushttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40287provision new OSUOSL ARM servers2021-06-17T20:21:21Zanarcatprovision new OSUOSL ARM serverswe have 32GB of RAM and 14 CPUs of ARM virtual machines to provision in their openstack cluster (thanks!!!). this should probably be used for gitlab runners to replace the retired jenkins / build-arm-10 builder (tpo/tpa/team#40284).
pre...we have 32GB of RAM and 14 CPUs of ARM virtual machines to provision in their openstack cluster (thanks!!!). this should probably be used for gitlab runners to replace the retired jenkins / build-arm-10 builder (tpo/tpa/team#40284).
pre-req checklist:
1. [x] partitions: setup /swapfile
2. [x] upgrades
3. [x] hostname fixed (had `.novalocal` suffix)
4. [ ] reverse DNS
5. [x] root password
6. [x] DNS works
main procedure:
1. [x] nextcloud spreadsheet
2. [x] tsa-misc
3. [x] puppet bootstrap
4. [x] nagios
6. [x] DNSWL (n/a)
5. [x] rebootanarcatanarcat2021-06-30https://gitlab.torproject.org/tpo/core/fallback-scripts/-/issues/309744-5. Announce the new fallback list, and tell downstream maintainers that it ...2021-06-19T09:13:31Zteor4-5. Announce the new fallback list, and tell downstream maintainers that it has changedHere are the instructions for running a rebuild:
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrors
This ticket covers steps 4 and 5.Here are the instructions for running a rebuild:
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrors
This ticket covers steps 4 and 5.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40314Misconfigured DNS allows same-site-scripting2021-06-21T17:31:14ZGeorg KoppenMisconfigured DNS allows same-site-scriptingWe got a bug report at HackerOne which I am not sure what to do about. Here it is to get input from our sysadmins (which need to fix it anyway, in case it's deemed valid):
```
Same site scripting
I have found an error of some misconfigr...We got a bug report at HackerOne which I am not sure what to do about. Here it is to get input from our sysadmins (which need to fix it anyway, in case it's deemed valid):
```
Same site scripting
I have found an error of some misconfigrured DNS in a subdomain of yours which causes same site scripting.
Steps To Reproduce:
Step 1 : Go to terminal or cmd
Step 2 : Now type host localhost.torproject.org
Step 3 : Has Now you can see the response from localhost 127.0.0.1
Step 4 : This lead to Same site scripting
Referance :
http://www.securityfocus.com/archive/1/486606/30/0/threaded
Solution:
Kindly remove DNS record from nameserver or use that subdomain.
Impact
Same site scripting may lead to internal DOS
```weasel (Peter Palfrader)weasel (Peter Palfrader)https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/34108Write script to keep track of toolchain changes2021-06-22T14:26:54ZGeorg KoppenWrite script to keep track of toolchain changesWe have a lot of different requirements for our toolchain (see: legacy/trac#33557) due to a number of different projects involved in building Fenix. We should write a script that we run periodically to keep track of necessary toolchain c...We have a lot of different requirements for our toolchain (see: legacy/trac#33557) due to a number of different projects involved in building Fenix. We should write a script that we run periodically to keep track of necessary toolchain changes ahead of time.Tor Browser: 10.5boklmboklmhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40088Investigate rise and drop of measured relays by maatuska's bwauth2021-06-23T13:59:06ZGeorg KoppenInvestigate rise and drop of measured relays by maatuska's bwauthLast week on the the 20th and 21st we had a curious rise and drop of relays measured by `maatuska`'s bwauth. We should investigate whether this makes sense: ![maatuska_raise_drop_05_20_21_2021](/uploads/afbd61af6c6c54ce0101ac6eb1975ce5/m...Last week on the the 20th and 21st we had a curious rise and drop of relays measured by `maatuska`'s bwauth. We should investigate whether this makes sense: ![maatuska_raise_drop_05_20_21_2021](/uploads/afbd61af6c6c54ce0101ac6eb1975ce5/maatuska_raise_drop_05_20_21_2021.png)sbws: 1.2.x-finalGeorg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34087HSv3: Bug: Non-fatal assertion in hs_client.c:981: close_or_reextend_intro_circ2021-06-23T17:22:07Zs7rHSv3: Bug: Non-fatal assertion in hs_client.c:981: close_or_reextend_intro_circClient side HSv3 non fatal bug. It occurs like between ~20 - 30 times in a total of 100.000 built rendezvous circuits:
```
Apr 11 08:58:25.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:981: close_or_reextend_intro_c...Client side HSv3 non fatal bug. It occurs like between ~20 - 30 times in a total of 100.000 built rendezvous circuits:
```
Apr 11 08:58:25.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:981: close_or_reextend_intro_circ: Non-fatal assertion !(desc == NULL) failed. (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Non-fatal assertion !(desc == NULL) failed in close_or_reextend_intro_circ at ../src/feature/hs/hs_client.c:981. Stack trace: (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(log_backtrace_impl+0x56) [0x55d874ac7ee6] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(tor_bug_occurred_+0x16c) [0x55d874ac30ec] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(hs_client_receive_introduce_ack+0x2f5) [0x55d8749cfe95] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(rend_process_relay_cell+0x226) [0x55d874a1e796] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(+0xbe368) [0x55d874966368] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(+0xbf1c5) [0x55d8749671c5] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(circuit_receive_relay_cell+0x2b4) [0x55d874968a44] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(command_process_cell+0x2c8) [0x55d87494b788] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(channel_tls_handle_cell+0x4eb) [0x55d87492af0b] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(+0xac5ca) [0x55d8749545ca] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(connection_handle_read+0xa92) [0x55d8749183a2] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(+0x75609) [0x55d87491d609] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f1984b569ba] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f1984b57537] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(do_main_loop+0xff) [0x55d87491e88f] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(tor_run_main+0x10b5) [0x55d87490bbc5] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(tor_main+0x3a) [0x55d8749092ca] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(main+0x19) [0x55d874908e89] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f198443809b] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(_start+0x2a) [0x55d874908eda] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:981: close_or_reextend_intro_circ: Non-fatal assertion !(desc == NULL) failed. (on Tor 0.4.4.0-alpha-dev )
```Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40063stats: Create a stat exporter port for monitoring purposes2021-06-23T17:22:08ZDavid Gouletdgoulet@torproject.orgstats: Create a stat exporter port for monitoring purposesThe `Control Port` does basically export a lot of data that tor holds but this new `Stat Port` (we'll call that for now) differs in a couple of ways.
The idea is that it would be a pull mechanism so tools connect to the port, request a ...The `Control Port` does basically export a lot of data that tor holds but this new `Stat Port` (we'll call that for now) differs in a couple of ways.
The idea is that it would be a pull mechanism so tools connect to the port, request a series of stats, tor sends it and then disconnects. This follows the Prometheus model which is to expose your stats through an HTTP interface and the monitoring server just comes in regularly and get the data.
Tor has already everything to support that that is listener port and HTTP interface we can hook on (with a bit of work :).
We can export all sorts of stats useful for monitoring relays and onion services. For example, for onion service monitoring, exporting these would be game changer for service operators:
1. Amount of traffic the .onion is getting
2. Amount of introduction requests
3. Amount of rendezvous requests and how many succeeds vs fails.
4. Descriptor status with HSDir
...
The reason it differs from the Control Port is that most public relays or onion services would prefer not having that port open **especially** on a public address. But also, this follows the concept of providing a `REST` interface which would be very little amount of work for the tor daemon where with the control port, is often a mixed of poking at our internal state instead of a pre-populated memory with stats.
There is of course the question of data safety here. If we build nice interface that in couple clicks allows operators to have beautiful Grafana graphs, then some says it is an incentive to export it and sometimes publicly.
However, this is really not different from the Control Port or Nyx monitoring interface. The problem shows up when the third part tool gathering the data actually archives. That today, is doable. This would yes be lowering the bar for this to happen but I think the ability to properly monitor a relay or an onion service outweigh the cons.
We could see that at first it is only for onion services and on a non public port. We could think of security checks like this but in the end, this is would just be another tool in the service operator belt to properly monitor tor if they choose to with of course risks associated with it like anything tor opens.
This is one example that @ahf worked on but with a push model: https://github.com/ahf/tor/tree/ahf/feature/stats_reporterTor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40266hs-v2: Farewell Old Friend2021-06-23T17:22:08ZDavid Gouletdgoulet@torproject.orghs-v2: Farewell Old FriendThe 0.4.6 merge window has opened earlier this year, thus it is time to say goodbye to our great friend, the onion service version 2.
It has served us incredibly well, it has done its time and can now retire with pride and glory.
This ...The 0.4.6 merge window has opened earlier this year, thus it is time to say goodbye to our great friend, the onion service version 2.
It has served us incredibly well, it has done its time and can now retire with pride and glory.
This ticket is about the removal of v2 support from tor.git. As per our deprecation timeline:
https://lists.torproject.org/pipermail/tor-dev/2020-June/014365.htmlTor: 0.4.6.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40481Small Quickstart explanation fixups2021-06-24T16:47:23ZMatthew FinkelSmall Quickstart explanation fixupsOn `about:torconnect`, we mention `Quickstart` but it isn't obviously a reference to anything on that page (except, maybe, `Always connect automatically`, but that isn't clear). I think we should delete the sentence `Quickstart allows To...On `about:torconnect`, we mention `Quickstart` but it isn't obviously a reference to anything on that page (except, maybe, `Always connect automatically`, but that isn't clear). I think we should delete the sentence `Quickstart allows Tor Browser to connect automatically.` on that page.
On `about:preferences#tor`, we have a Quickstart section, and that uses the same text as `about:torconnect`, but it ends with `Learn More` where it links to general information about Tor - not information about Quickstart. Richard had the good idea of splitting the text and putting the first sentence under `Tor Settings` with `Learn More`, and keeping the second sentence about `Quickstart` under the `Quickstart` header.richardrichardhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40052Snowflake bridge keeps triggering OOM killer2021-06-25T14:24:09ZCecylia BocovichSnowflake bridge keeps triggering OOM killerSeems like #40051 did not solve our problem. The server was down again this morning:
```
Jun 18 11:58:44 snowflake kernel: [240512.397993] sshd invoked oom-killer: gfp_mask=0x100cca(GFP_HIGH
USER_MOVABLE), order=0, oom_score_adj=0
[snip...Seems like #40051 did not solve our problem. The server was down again this morning:
```
Jun 18 11:58:44 snowflake kernel: [240512.397993] sshd invoked oom-killer: gfp_mask=0x100cca(GFP_HIGH
USER_MOVABLE), order=0, oom_score_adj=0
[snip]
Jun 18 11:58:44 snowflake kernel: [240512.444250] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
Jun 18 11:58:44 snowflake kernel: [240512.472145] [ 1641] 106 1641 168150 93653 1089536 0 0 tor
Jun 18 11:58:44 snowflake kernel: [240512.473285] [ 1642] 106 1642 548343 234687 2072576 0 0 snowflake-serve
Jun 18 11:58:44 snowflake kernel: [240512.476205] [ 7901] 108 7901 621 21 40960 0 0 timeout
Jun 18 11:58:44 snowflake kernel: [240512.477206] [ 7902] 108 7902 231410 2098 196608 0 0 proxy-go
Jun 18 11:58:44 snowflake kernel: [240512.477909] [ 12745] 108 12745 621 22 45056 0 0 timeout
Jun 18 11:58:44 snowflake kernel: [240512.479216] [ 12746] 108 12746 231410 3605 200704 0 0 proxy-go
[snip]
Jun 18 11:58:44 snowflake kernel: [240512.482848] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/system-tor.slice/tor@default.service,task=snowflake-serve,pid=1642,uid=106
Jun 18 11:58:44 snowflake kernel: [240512.485406] Out of memory: Killed process 1642 (snowflake-serve) total-vm:2193372kB, anon-rss:938748kB, file-rss:0kB, shmem-rss:0kB, UID:106 pgtables:2024kB oom_score_adj:0
Jun 18 11:58:44 snowflake kernel: [240512.496421] oom_reaper: reaped process 1642 (snowflake-serve), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
```Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/community/l10n/-/issues/40013Install and configure tools and scripts for translation automation of trainin...2021-06-25T19:06:13ZGabagaba@torproject.orgInstall and configure tools and scripts for translation automation of training materialsThe first presentation is live at https://community.torproject.org/training/resources/tor-training/ and will soon be up for translation.
We are only missing to integrate the presentation on the rest of the page, probably linking it on h...The first presentation is live at https://community.torproject.org/training/resources/tor-training/ and will soon be up for translation.
We are only missing to integrate the presentation on the rest of the page, probably linking it on https://community.torproject.org/training/resources/.Sponsor 9 - Phase 5 - Usability and Community Intervention on Support for Democracy and Human RightsGusGushttps://gitlab.torproject.org/tpo/onion-services/onionbalance/-/issues/3should support balancing many onion addresses2021-06-28T10:56:43Zweasel (Peter Palfrader)should support balancing many onion addressesCurrently for v3 onion services, onionbalance only can balance a single hostname. As a result, both tor and debian need to run 40-60 onionbalance instances each. That is not cheap on memory use. For instance, a VM with only 6 gigabyte...Currently for v3 onion services, onionbalance only can balance a single hostname. As a result, both tor and debian need to run 40-60 onionbalance instances each. That is not cheap on memory use. For instance, a VM with only 6 gigabytes of ram is not able to provide the onionbalance service for debian.
Please make onionbalance be able to balance any number of v3 services.
On top, it'd be nice if it could balance both v3 and v2 at the same time. But that's less of an issue.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/community/training/-/issues/12Create internal criteria on which external material to include or not in the ...2021-06-28T17:53:59ZGabagaba@torproject.orgCreate internal criteria on which external material to include or not in the Community portal.Discussed in meeting:
- Being updated and maintained. - have a date when it was last updated (no older than X months).
- Mentions that Tor is dangerous and to be away from it.
- It does not includes a more than 1 version old Tor Browse...Discussed in meeting:
- Being updated and maintained. - have a date when it was last updated (no older than X months).
- Mentions that Tor is dangerous and to be away from it.
- It does not includes a more than 1 version old Tor Browser.
- It does not mention or teach to use tools that is not maintained.
- Do not harm: demystifies the "dark/deep web", no training materials that will scare people, or put them at risk.
- It need to mention Tor and our products.
- It is a link in the web (that work with Tor).
- It should follow the best practices of Tor. For example, we do not recommend people to [pick which country they're exiting from](https://support.torproject.org/tbb/tbb-16/), plain language, explains acronyms.
An example of good resources made by external organizations:
- EFF security and self defense) - https://ssd.eff.org/
- Security in a box
- Totem https://totem-project.org/Sponsor 9 - Phase 5 - Usability and Community Intervention on Support for Democracy and Human RightsAntonelaantonela@torproject.orgAntonelaantonela@torproject.orghttps://gitlab.torproject.org/tpo/web/donate-static/-/issues/23Add a Dogecoin Wallet Address to the Donate Page2021-06-28T20:08:15ZSusanAdd a Dogecoin Wallet Address to the Donate PageHey @gus,
Can you add the following wallet address for Dogecoin to the crypto currency donate page?
`DJwRnafcjDbzqWM5vsCphuyQuTc2QB3a8F`
Thanks,
SueHey @gus,
Can you add the following wallet address for Dogecoin to the crypto currency donate page?
`DJwRnafcjDbzqWM5vsCphuyQuTc2QB3a8F`
Thanks,
SueGusGushttps://gitlab.torproject.org/tpo/core/tor/-/issues/40408Add tracepoint for performance measurements2021-06-29T14:45:15ZDavid Gouletdgoulet@torproject.orgAdd tracepoint for performance measurementsThis is part of sponsor 61 from which we need to measure a series of performance metrics in tor as a baseline and then we'll do the same once we implement congestion control.
Initial list, more might come:
- Record EWMA values (halflif...This is part of sponsor 61 from which we need to measure a series of performance metrics in tor as a baseline and then we'll do the same once we implement congestion control.
Initial list, more might come:
- Record EWMA values (halflife)
- cell transit time in queues at relays
- min/avg/max queue length of circuitmux and channel outbuf
- Time from every 100th cell sent and SENDME response (RTT), for each circuit
- OOM circuit killer being triggered
The plan is to add tracepoints that will be used to record data and from the collected trace(s) we'll compute the various metrics from above like SENDME RTT, cell transit time, and so on.
Parent ticket is #40404Tor: 0.4.7.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org