The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-05-12T16:23:06Zhttps://gitlab.torproject.org/tpo/web/team/-/issues/38Broken link on archive.torproject.org2022-05-12T16:23:06ZsreadyBroken link on archive.torproject.orgIn README.txt of archive.torproject.org, there is a link to https://metrics.torproject.org/data.html. It should probably be changed to https://metrics.torproject.org/sources.html?In README.txt of archive.torproject.org, there is a link to https://metrics.torproject.org/data.html. It should probably be changed to https://metrics.torproject.org/sources.html?anarcatanarcathttps://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/128Broken link on help page2022-08-30T21:03:58ZStefani BanerianBroken link on help pagepage
https://gitlab.torproject.org/help/gitlab-basics/start-using-git#merge-a-branch-with-default-branch
has a broken link, right under the code section.
https://gitlab.torproject.org/help/user/project/merge_requests/ gives a '404'page
https://gitlab.torproject.org/help/gitlab-basics/start-using-git#merge-a-branch-with-default-branch
has a broken link, right under the code section.
https://gitlab.torproject.org/help/user/project/merge_requests/ gives a '404'anarcatanarcathttps://gitlab.torproject.org/tpo/web/donate-static/-/issues/93Broken Reports page link at donor FAQ2022-10-14T17:55:21ZmattlavBroken Reports page link at donor FAQA job for @kez - Our Donor FAQ has a missing link, here:
https://donate.torproject.org/donor-faq/#how-will-you-use-my-donation
It should lead to:
https://www.torproject.org/about/reports/A job for @kez - Our Donor FAQ has a missing link, here:
https://donate.torproject.org/donor-faq/#how-will-you-use-my-donation
It should lead to:
https://www.torproject.org/about/reports/https://gitlab.torproject.org/tpo/tpa/team/-/issues/41382BTC PayServer offline?2023-11-06T19:02:59ZmattlavBTC PayServer offline?Got a [RT ticket](https://rt.torproject.org/Ticket/Display.html?id=318472) today indicating that our BTC PayServer is offline; @smith checked and confirmed this is the case. That's about all I know about it; we need this running in order...Got a [RT ticket](https://rt.torproject.org/Ticket/Display.html?id=318472) today indicating that our BTC PayServer is offline; @smith checked and confirmed this is the case. That's about all I know about it; we need this running in order to accept cryptodonations, so I'm making a ticket here. Let me know any way I can be useful -Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/web/donate-static/-/issues/134BTC PayServer offline?2023-11-06T19:01:15ZmattlavBTC PayServer offline?Got a [RT ticket](https://rt.torproject.org/Ticket/Display.html?id=318472) today indicating that our BTC PayServer is offline; @smith checked and confirmed this is the case. That's about all I know about it; we need this running in order...Got a [RT ticket](https://rt.torproject.org/Ticket/Display.html?id=318472) today indicating that our BTC PayServer is offline; @smith checked and confirmed this is the case. That's about all I know about it; we need this running in order to accept cryptodonations, so I'm making a ticket here. Let me know any way I can be useful -Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41549BTCPayServer is Down2024-03-18T23:29:44ZSusanBTCPayServer is DownI am unable to connect to the btcpay.torproject.org. It says the site cannot be reached. I believe this means that donors cannot use it to donate either.I am unable to connect to the btcpay.torproject.org. It says the site cannot be reached. I believe this means that donors cannot use it to donate either.anarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41477btcpayserver-02 is using 90% of its swap2024-01-17T21:00:59ZKezbtcpayserver-02 is using 90% of its swapNagios is reporting an alert on btcpayserver-02: `SWAP CRITICAL - 9% free (180MB out of 2047MB)`. I've checked the server, it's only using 3G of its 7.76G of available memory. The most memory intensive process is bitcoind at 14%. I'll st...Nagios is reporting an alert on btcpayserver-02: `SWAP CRITICAL - 9% free (180MB out of 2047MB)`. I've checked the server, it's only using 3G of its 7.76G of available memory. The most memory intensive process is bitcoind at 14%. I'll start looking to see what's eating the swap space.https://gitlab.torproject.org/tpo/tpa/team/-/issues/41240btcpayserver-02 not in nagios?2023-06-26T18:59:13ZJérôme Charaouilavamind@torproject.orgbtcpayserver-02 not in nagios?`btcpayserver-02` is not monitored in Nagios. Is that intentional, or an oversight?
I could not find any explanation about this in the previous tickets related to that server's setup.`btcpayserver-02` is not monitored in Nagios. Is that intentional, or an oversight?
I could not find any explanation about this in the previous tickets related to that server's setup.anarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41292btcpayserver-02: /srv 90% full2023-08-08T17:10:46ZKezbtcpayserver-02: /srv 90% fullnagios is warning about disk space usage on btcpayserver-02. the specific issue is that the docker overlay fs is using most of the /srv partition.
```
root@btcpayserver-02:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev ...nagios is warning about disk space usage on btcpayserver-02. the specific issue is that the docker overlay fs is using most of the /srv partition.
```
root@btcpayserver-02:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 3.9G 0 3.9G 0% /dev
tmpfs 795M 1.2M 794M 1% /run
/dev/sda1 9.8G 3.3G 6.0G 36% /
tmpfs 3.9G 72K 3.9G 1% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 3.9G 0 3.9G 0% /tmp
/dev/sdc 69G 59G 7.2G 90% /srv
overlay 69G 59G 7.2G 90% /srv/docker/overlay2/735b6383a11fd94e44c441aa5e103191b89c14cc8855e07ffb40da340b80f928/merged
overlay 69G 59G 7.2G 90% /srv/docker/overlay2/7895c81f2090c42896189ea70665c39b743dfc668d9ccb2ffd6e73a4a441520b/merged
overlay 69G 59G 7.2G 90% /srv/docker/overlay2/1b8d41ee0217e2d24e630345d323f71ac0f65441c0517fa02ff08a5f94232a6d/merged
shm 64M 16K 64M 1% /srv/docker/containers/f0734d0f17976e9ede4ad209f085773ee4e80852287ecd96fa501a8e28626178/mounts/shm
shm 64M 0 64M 0% /srv/docker/containers/cef2842f39d4da80150c219cc71430a07137e8719e2b8324c57a8b2e4d857ed2/mounts/shm
shm 64M 0 64M 0% /srv/docker/containers/2bb6c98d05f06ecd3f7e58c1184d2150c4c1de813c89226a955308521c9d3471/mounts/shm
overlay 69G 59G 7.2G 90% /srv/docker/overlay2/d37fe48eace9b88c00924bcc66fa96dcaf650006d5e1c39c759455abc5921c20/merged
overlay 69G 59G 7.2G 90% /srv/docker/overlay2/75438c97c9e77763eb7cd84a5177041b696845cc1d3807dbeddcead826d37f32/merged
shm 64M 0 64M 0% /srv/docker/containers/c07628f5a627e0d401230e4f9fe8b0d9eb8c614ef7762acc9d81dbda569537ae/mounts/shm
shm 64M 0 64M 0% /srv/docker/containers/6559636f50460a4d26855eb80b1f2c446fafd2b6a2f9b6d4322418518a242259/mounts/shm
overlay 69G 59G 7.2G 90% /srv/docker/overlay2/86a07343fdf41d9309519fc14b1e5f8eb85fb90d275312d89ff0d27f30dee8df/merged
overlay 69G 59G 7.2G 90% /srv/docker/overlay2/333c5454cb901eb8b25f8f20227edec35188659d9098604dd8c7f31c174e16f0/merged
shm 64M 0 64M 0% /srv/docker/containers/f8d04c7284c79b1bd383d64e6b5d0305d0d6272c2eb14fff11340eb8461003da/mounts/shm
shm 64M 0 64M 0% /srv/docker/containers/2c8e162b5ae001a436afd31294f3c8551fca4413c6b81b50643356620d818569/mounts/shm
overlay 69G 59G 7.2G 90% /srv/docker/overlay2/9e572a7553a25246e3f72f46a6f0f0be327b44e2b146d61705ae9a8b866bb5e0/merged
shm 64M 0 64M 0% /srv/docker/containers/7a924b30814683a78b533f0c83bb5a8b6e46dc333bf9cacb1cd71cbf68ae37a5/mounts/shm
overlay 69G 59G 7.2G 90% /srv/docker/overlay2/89084fcfe2ba1e042e250175f6dcc29147e60617b477a60f85a63f862b08b528/merged
shm 64M 0 64M 0% /srv/docker/containers/8de0025ef6ff1d53f7976bc8f7d93856ad87dbe764beac6f6a8824d35cf041cc/mounts/shm
tmpfs 795M 0 795M 0% /run/user/0
```anarcatanarcathttps://gitlab.torproject.org/tpo/team/-/issues/219Budget for Translations into Turkmen2024-01-16T13:08:32ZGabagaba@torproject.orgBudget for Translations into TurkmenWe need to write the budget and scope to request Localization Lab for the translation for turkmen.
cc @emmapeelWe need to write the budget and scope to request Localization Lab for the translation for turkmen.
cc @emmapeelGabagaba@torproject.orgGabagaba@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40289Bug 0.4.5.5-rc ORPort relay (using both IPv4 & IPv6)2021-02-22T14:10:24ZcypherpunksBug 0.4.5.5-rc ORPort relay (using both IPv4 & IPv6)Hi,
I'm using Debian Buster to run my (non-exit) relay. I use 'deb https://deb.torproject.org/torproject.org buster main' repository in apt sources list.
After I upgraded to Tor 0.4.5.5-rc from 0.4.4.6, my configuration does not work a...Hi,
I'm using Debian Buster to run my (non-exit) relay. I use 'deb https://deb.torproject.org/torproject.org buster main' repository in apt sources list.
After I upgraded to Tor 0.4.5.5-rc from 0.4.4.6, my configuration does not work anymore. My relay has (/etc/network/interfaces) public IPv6 address and private IPv4 address, because relay is behind NAT (there is no configuration errors in general firewall settings, and this setup has worked before).
After upgrade to 0.4.5.5-rc, Tor does not bind anymore to IPv4 address. Just to make sure again: there has not been problem whatsoever with my configuration, and after I downgraded back to 0.4.4.6, everything worked as before. I spotted that somebody else has some problems also with 0.4.5.5-rc https://www.reddit.com/r/TOR/comments/lgnt7g/orport_is_not_reachable_after_updating_tor_from/
I think that something has changed in a way 0.4.5.5-rc is handling configuration file (“torrc”).
Log from syslog:
```
Feb 10 20:53:39 Tor[1004]: Opening Socks listener on 127.0.0.1:9050
Feb 10 20:53:39 Tor[1004]: Opened Socks listener connection (ready) on 127.0.0.1:9050
Feb 10 20:53:39 Tor[1004]: Opening Control listener on 127.0.0.1:9051
Feb 10 20:53:39 Tor[1004]: Opened Control listener connection (ready) on 127.0.0.1:9051
Feb 10 20:53:39 Tor[1004]: Opening OR listener on [{my public working IPv6 address}]:443
Feb 10 20:53:39 Tor[1004]: Opened OR listener connection (ready) on [{my public working IPv6 address}]:443
Feb 10 20:53:39 Tor[1004]: Opening Directory listener on 0.0.0.0:80
Feb 10 20:53:39 Tor[1004]: Opened Directory listener connection (ready) on 0.0.0.0:80
Feb 10 20:53:39 Tor[1004]: Opening Directory listener on [{my public working IPv6 address}]:80
Feb 10 20:53:39 Tor[1004]: Opened Directory listener connection (ready) on [{my public working IPv6 address}]:80
Feb 10 20:54:34 Tor[1004]: Now checking whether IPv4 ORPort {my public working IPv4 address}:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Feb 10 20:54:34 Tor[1004]: Now checking whether IPv6 ORPort [{my public working IPv6 address}]:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Feb 10 20:54:34 Tor[1004]: Now checking whether IPv4 DirPort {my public working IPv4 address}:80 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Feb 10 20:54:34 Tor[1004]: Self-testing indicates your DirPort is reachable from the outside. Excellent.
Feb 10 20:54:52 Tor[1004]: Self-testing indicates your ORPort [{my public working IPv6 address}]:443 is reachable from the outside. Excellent.
Feb 10 21:14:32 Tor[1004]: Your server has not managed to confirm reachability for its ORPort(s) at {my public working IPv4 address}:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
```
“tor --verify-config command says:
"[warn] Configured public relay to listen only on an IPv6 address. Tor needs to listen on an IPv4 address too.
[warn] Failed to parse/validate config: Misconfigured server ports"
My /etc/tor/torrc file (also, there is Debian default shipped “tor-service-defaults-torrc” -file, which I have not edited and I think it does not have any relevance on this issue; I think that file just sets user permissions of tor daemon to behave in a Debian way):
```
ControlPort 9051
ControlSocket 0
CookieAuthentication 0
HashedControlPassword {my hashed password}
ORPort {my internal/local IPv4 address behind NAT}:443 NoAdvertise
ORPort {my public working IPv4 address}:443 NoListen
ORPort [{my public working IPv6 address}]:443
OutboundBindAddress {my internal/local IPv4 address behind NAT}
OutboundBindAddress [{my public working IPv6 address}]
DirPort {my public working IPv4 address}:80 NoListen
DirPort {my internal/local IPv4 address behind NAT}:80 NoAdvertise
DirPort [{my public working IPv6 address}]:80 NoAdvertise
DirPortFrontPage /etc/tor/tor-exit-notice.html
ExitPolicy reject *:*
ExitPolicy reject6 *:*
ExitRelay 0
BandwidthRate {private} MBits
BandwidthBurst {private} MBits
MaxAdvertisedBandwidth {private} MBits
RelayBandwidthRate {private} MBits
RelayBandwidthBurst {private} MBits
LogMessageDomains 0
BridgeRelay 0
ContactInfo {private}
IPv6Exit 0
Nickname {private}
EntryStatistics 1
DoSCircuitCreationEnabled auto
DoSConnectionEnabled auto
AuthoritativeDirectory 0
V3AuthoritativeDirectory 0
VersioningAuthoritativeDirectory 0
BridgeAuthoritativeDir 0
ConnDirectionStatistics 1
CellStatistics 1
HardwareAccel 1
MaxUnparseableDescSizeToLog 100 MB
RendPostPeriod 15 minutes
```
I posted my whole /etc/tor/torrc file. I know, that there maybe some unnecessary settings, but anyway, that configuration has worked prior 0.4.5.5-rc.
P.S. This Anon Ticket service is very good for one-time bug senders, like I am.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40388bug : rep_hist_note_dns_error: Non-fatal assertion2021-05-13T19:19:41Ztoralfbug : rep_hist_note_dns_error: Non-fatal assertionHappened in latest -git
```
May 12 18:56:32.000 [warn] tor_bug_occurred_(): Bug: src/feature/stats/rephist.c:328: rep_hist_note_dns_error: Non-fatal assertion !(!dns_stats) failed. (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56...Happened in latest -git
```
May 12 18:56:32.000 [warn] tor_bug_occurred_(): Bug: src/feature/stats/rephist.c:328: rep_hist_note_dns_error: Non-fatal assertion !(!dns_stats) failed. (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:32.000 [warn] Bug: Tor 0.4.7.0-alpha-dev (git-22861c2f4083e7e2): Non-fatal assertion !(!dns_stats) failed in rep_hist_note_dns_error at src/feature/stats/rephist.c:328. Stack trace: (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:32.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x5a) [0x5644503140ca] (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:32.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0x173) [0x56445031f113] (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:32.000 [warn] Bug: /usr/bin/tor(+0x1add9f) [0x5644503ecd9f] (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:32.000 [warn] Bug: /usr/lib64/libevent-2.1.so.7(+0x2bc4d) [0x7f0726168c4d] (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:32.000 [warn] Bug: /usr/lib64/libevent-2.1.so.7(+0x1f9dc) [0x7f072615c9dc] (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:32.000 [warn] Bug: /usr/lib64/libevent-2.1.so.7(event_base_loop+0x53f) [0x7f072615d98f] (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:32.000 [warn] Bug: /usr/bin/tor(do_main_loop+0xdd) [0x5644502a513d] (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:32.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x185) [0x5644502a0c25] (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:32.000 [warn] Bug: /usr/bin/tor(tor_main+0x46) [0x56445029d276] (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:32.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x56445029ce29] (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:32.000 [warn] Bug: /lib64/libc.so.6(__libc_start_main+0xea) [0x7f0725ac7e3a] (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:32.000 [warn] Bug: /usr/bin/tor(_start+0x2a) [0x56445029ce7a] (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:37.000 [warn] tor_bug_occurred_(): Bug: src/feature/stats/rephist.c:328: rep_hist_note_dns_error: Non-fatal assertion !(!dns_stats) failed. (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:37.000 [warn] Bug: Tor 0.4.7.0-alpha-dev (git-22861c2f4083e7e2): Non-fatal assertion !(!dns_stats) failed in rep_hist_note_dns_error at src/feature/stats/rephist.c:328. Stack trace: (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:37.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x5a) [0x5644503140ca] (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:37.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0x173) [0x56445031f113] (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:37.000 [warn] Bug: /usr/bin/tor(+0x1add9f) [0x5644503ecd9f] (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
May 12 18:56:37.000 [warn] Bug: /usr/lib64/libevent-2.1.so.7(+0x2bc4d) [0x7f0726168c4d] (on Tor 0.4.7.0-alpha-dev 22861c2f4083e7e2)
```
...Tor: 0.4.7.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40295Bug Report for Metrics Endpoint2021-04-16T14:16:05ZGusBug Report for Metrics EndpointFrom RT:
I am testing the metrics port from this issue:
https://gitlab.torproject.org/tpo/core/tor/-/issues/40063
The issue I am getting is `"connection_finished_flushing(): Bug: got unexpected conn type 20. (on Tor 0.4.5.6 )"`
My set...From RT:
I am testing the metrics port from this issue:
https://gitlab.torproject.org/tpo/core/tor/-/issues/40063
The issue I am getting is `"connection_finished_flushing(): Bug: got unexpected conn type 20. (on Tor 0.4.5.6 )"`
My setup is the following:
```
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal
```
```
$ tor --version
Tor version 0.4.5.6.
```
I added the following values to my torrc:
```
MetricsPort 127.0.0.1:9135
MetricsPortPolicy accept 127.0.0.1
```
Several issues arise:
a) Tor is not able to determine, that the Metrics Port has already been opened. Tor tried to open it again
b) Something inside tor crashes as soon as someone tries to access the metrics information.
I attached the log messages from syslog. [logfile.txt](/uploads/dfc846864430f16cc038447c64e04e55/logfile.txt)
Please note, that I am using tor for relay as well as for a hidden service.
I checked, there is nothing listening on port 9135. Tor has this port exclusively.
The metrics port is disabled again for my setup. If you need more information, please don't hesitate to ask.Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/40Bug with how intervals are being calculated2023-06-22T06:30:09ZHiroBug with how intervals are being calculatedI found a bug regarding intervals being negative and producing negative bandwidth values.I found a bug regarding intervals being negative and producing negative bandwidth values.HiroHirohttps://gitlab.torproject.org/tpo/core/tor/-/issues/40071Bug: Bridge obfs4 0.4.5.0-alpha-dev rebuilding descriptor (source: METHOD=NON...2021-07-09T17:30:28ZLX1Bug: Bridge obfs4 0.4.5.0-alpha-dev rebuilding descriptor (source: METHOD=NONE) | Don't know my address while generating descriptor**syslog**:
Self-testing indicates your ORPort xxxxxxx:443 is reachable from the outside. Excellent. Publishing server descriptor.
THEN:
Our IP Address has changed from xxxxxxx to ???; rebuilding descriptor (source: METHOD=NONE).
---
He...**syslog**:
Self-testing indicates your ORPort xxxxxxx:443 is reachable from the outside. Excellent. Publishing server descriptor.
THEN:
Our IP Address has changed from xxxxxxx to ???; rebuilding descriptor (source: METHOD=NONE).
---
Hello. **After update alpha dev**:
> log: "Don't know my address while generating descriptor"
> https://metrics.torproject.org/rs.html#search/agileresearchlab but from the same location stable relay runs normally
I have 2 relays alpha/stable in the same location / 1 fix IP.
This happened after the update, only alpha bridge, stable bridge running normally.
Until then, everything was normal > 1 IP == 2x bridge obfs4.
OS: Debian
I provide alpha just for development research primarily..![obfs4_0.4.5.0-alpha-dev_rebuilding_descriptor](/uploads/97b4a23f12f8b13a4807fc3949e3177b/obfs4_0.4.5.0-alpha-dev_rebuilding_descriptor.jpg)
![_source__METHOD_NONE_](/uploads/8cb0281c7956df60fb0eaf5d84bf63d4/_source__METHOD_NONE_.jpg)Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40596Bug: Non-fatal assertion failed in process_win32_read_from_handle2022-11-01T13:16:09ZcypherpunksBug: Non-fatal assertion failed in process_win32_read_from_handleOn win32, latest Tor 0.4.6.10
when starting with torrc consisting of:
<code>ClientTransportPlugin trebuchet exec /path/to/snowflake-client.exe
Bridge trebuchet 127.0.0.1:123</code>
Logs the following:
```
Jan 1 00:00:00.000 [notice] B...On win32, latest Tor 0.4.6.10
when starting with torrc consisting of:
<code>ClientTransportPlugin trebuchet exec /path/to/snowflake-client.exe
Bridge trebuchet 127.0.0.1:123</code>
Logs the following:
```
Jan 1 00:00:00.000 [notice] Bootstrapped 0% (starting): Starting
Jan 1 00:00:00.000 [notice] Starting with guard context "default"
Jan 1 00:00:00.000 [warn] Client managed proxy encountered a method error. (trebuchet no such method)
Jan 1 00:00:00.000 [warn] Managed proxy at '/path/to/snowflake-client.exe' failed the configuration protocol and will be destroyed.
Jan 1 00:00:00.000 [warn] tor_bug_occurred_(): Bug: process_win32.c:891: process_win32_read_from_handle: Non-fatal assertion !(handle->reached_eof) failed. (on Tor 0.4.6.10 22fd351cf582aa2b)
Jan 1 00:00:00.000 [warn] Bug: Tor 0.4.6.10 (git-22fd351cf582aa2b): Non-fatal assertion !(handle->reached_eof) failed in process_win32_read_from_handle at process_win32.c:891. (Stack trace not available) (on Tor 0.4.6.10 22fd351cf582aa2b)
Jan 1 00:00:00.000 [warn] Pluggable Transport process terminated with status code 0
Jan 1 00:00:00.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
```
Interestingly, bug doesn't happen if I put obfs4proxy instead of snowflake-client, so something additional triggers it in Snowflake (version from latest TBB). But I think tor mustn't log Bug's no matter how broken PT is.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32666BUG: Non-fatal assertion info failed in onion_extend_cpath at src/core/or/cir...2021-01-21T17:28:19ZcypherpunksBUG: Non-fatal assertion info failed in onion_extend_cpath at src/core/or/circuitbuild.c:2663. (Stack trace not available) (on Tor 0.4.1.5 439ca48989ece545)Got this in orbot After startup.
```
NOTICE: Bootstrapped 100% (done): Done
Ignoring start request, already started.
WARN: tor_bug_occurred_: Bug: src/core/or/circuitbuild.c:2663: onion_extend_cpath: Non-fatal assertion info failed. (on...Got this in orbot After startup.
```
NOTICE: Bootstrapped 100% (done): Done
Ignoring start request, already started.
WARN: tor_bug_occurred_: Bug: src/core/or/circuitbuild.c:2663: onion_extend_cpath: Non-fatal assertion info failed. (on Tor 0.4.1.5 439ca48989ece545)
WARN: Bug: Non-fatal assertion info failed in onion_extend_cpath at src/core/or/circuitbuild.c:2663. (Stack trace not available) (on Tor 0.4.1.5 439ca48989ece545)
WARN: Failed to find node for hop #2 of our path. Discarding this circuit.
NOTICE: Our circuit 0 (id: 15) died due to an invalid selected path, purpose General-purpose client. This may be a torrc configuration issue, or a bug.
```
Orbot 16.1.2rc2Tor: 0.4.5.x-stableAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40240Build 10.5a11 with rootless containers2021-03-01T16:50:58ZboklmBuild 10.5a11 with rootless containersIn order to check that the patch for #23631 is not introducing unexpected issues, I am planning to build 10.5a11 with the patch from #23631 on two different machines:
* to check that the build is reproducible
* to check whether the build...In order to check that the patch for #23631 is not introducing unexpected issues, I am planning to build 10.5a11 with the patch from #23631 on two different machines:
* to check that the build is reproducible
* to check whether the build differs from builds done with the old system (I previously looked at this for 10.5a8 in https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/23631#note_2724637). If it doesn't match, I will compare the containers used to do the build to try to understand what is causing the difference.boklmboklmhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41108build a new VM to deploy donate-neo review environments2023-09-20T00:55:55ZKezbuild a new VM to deploy donate-neo review environmentscontext: tpo/web/donate-neo#6
donate-neo needs a place to deploy CI environments. we'll do this by creating a new server named donate-review-01, with 8G memory, 2 vCPU cores, 10G root, 2G swap, and 20G HDD. thw software stack for the re...context: tpo/web/donate-neo#6
donate-neo needs a place to deploy CI environments. we'll do this by creating a new server named donate-review-01, with 8G memory, 2 vCPU cores, 10G root, 2G swap, and 20G HDD. thw software stack for the review deployments will be apache, mod_wsgi, python 3.10, and sqlite.
as for the deployment procedure, i was thinking of having the CI pipeline build an installable package and scp it to the donate-review-01 box, SSH in, and call a script. this script will set up a virtual environment, install the required packages, and create a new apache config and restart apache.
@anarcat do those VM specs and deployment steps look good to you?https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40193Build all mobile Rust targets in a single compilation step2021-01-14T20:57:42ZGeorg KoppenBuild all mobile Rust targets in a single compilation stepWhile we can't use more than one `--target` argument we can
comma-separate the Rust targets we want to build. Thus, no need to
compile five times e.g LLVM just to build Rust for all platforms.
(Note: In principle this works for desktop,...While we can't use more than one `--target` argument we can
comma-separate the Rust targets we want to build. Thus, no need to
compile five times e.g LLVM just to build Rust for all platforms.
(Note: In principle this works for desktop, too, but the different
toolchains needed for the different platforms makes this (slightly) more
complicated. So, we start with mobile-only here first)Tor Browser: 10.5Georg KoppenGeorg Koppen