The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-10-20T15:25:32Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40290standalone snowflake README still says go 1.15+ needed2023-10-20T15:25:32ZRoger Dingledinestandalone snowflake README still says go 1.15+ neededThe proxy/README.md file still says you need Go 1.15+, but it appears from e.g. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/184 like the go version requirement is now 1.21.
So, two t...The proxy/README.md file still says you need Go 1.15+, but it appears from e.g. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/184 like the go version requirement is now 1.21.
So, two things:
* We should update the README to reflect current requirements
and
* We should figure out what we want to tell people on Debian, who can no longer build snowflake, if they don't want to engage in installing and maintaining the whole toolchain manually. Do they stick with v2.6.1? Do they turn off their snowflake? Something even smarter? ...and then write that in the README too.https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/176run some experiments with CAPTCHAs2023-12-18T18:28:37Zmeskiomeskio@torproject.orgrun some experiments with CAPTCHAsAs we are planning to phase out CAPTCHAs (#173), can we run some experiments and see if they can be still effective?
We could either use the existing moat CAPTCHA API as we have some months until clients stop using it, or we could do it...As we are planning to phase out CAPTCHAs (#173), can we run some experiments and see if they can be still effective?
We could either use the existing moat CAPTCHA API as we have some months until clients stop using it, or we could do it in the HTTPS distributor as soon as we have migrated it to rdsys (#2).
There was a thread in the mailing list some years ago about this:
https://lists.torproject.org/pipermail/tor-dev/2021-July/014604.html
We should explore the space and see what better options for CAPTCHAs exist now a days.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42117Tor Bootstrap Log on Android becomes small2023-09-27T21:31:12ZPier Angelo VendrameTor Bootstrap Log on Android becomes smallI'm not sure of the STR, I think swiping left and right could help.
<details><summary>Screenshot</summary>
![Screenshot_20230920-173414](/uploads/5a11ba7505f431aa12c0d4bbee989b7e/Screenshot_20230920-173414.png)
</details>I'm not sure of the STR, I think swiping left and right could help.
<details><summary>Screenshot</summary>
![Screenshot_20230920-173414](/uploads/5a11ba7505f431aa12c0d4bbee989b7e/Screenshot_20230920-173414.png)
</details>https://gitlab.torproject.org/tpo/network-health/metrics/tagtor/-/issues/25Add filtering options for relays one is interested in2024-01-16T13:50:05ZGeorg KoppenAdd filtering options for relays one is interested inFor bad-relay work or general tagging help it would be nice if we could filter relays, eg. wrt AS, uptime, first_seen dates etc.For bad-relay work or general tagging help it would be nice if we could filter relays, eg. wrt AS, uptime, first_seen dates etc.TagTor is completed for its scope in Sponsor 112https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42116Possible confusion between search engine mismatch in URL bar and settings?2023-12-01T19:32:13ZJag TalonPossible confusion between search engine mismatch in URL bar and settings?In 13.0a4, there seems to be a mismatch between the search engines in the search bar (I believe called search shortcuts) and the default search engine setting. I'm wondering:
- Will people lose their default search engine on upgrade? I ...In 13.0a4, there seems to be a mismatch between the search engines in the search bar (I believe called search shortcuts) and the default search engine setting. I'm wondering:
- Will people lose their default search engine on upgrade? I personally use DuckDuckGoOnion, so I'm wondering now that it moved to the search shortcuts will it stop being the default?
- Should it be moved to search shortcuts completely or just be duplicated? I feel like the discrepancy creates confusion (at least it did for me!) cc @donuts
Apologies if this has been discussed before!
<details><summary>Screenshots of the pages</summary>
![signal-2023-09-20-083453_003](/uploads/734a3e9bdf526973b695330a17a7aa3f/signal-2023-09-20-083453_003.png)
![signal-2023-09-20-083453_002](/uploads/978d090a4b140fd5afe1ab904864b958/signal-2023-09-20-083453_002.png)
</details>https://gitlab.torproject.org/tpo/core/arti/-/issues/1040tor-guardmgr wakes arti up every second!2023-11-15T19:00:53ZNick Mathewsontor-guardmgr wakes arti up every second!See https://gitlab.torproject.org/tpo/core/arti/-/issues/1040#note_2950549
I think this is rather poor. People have spent a lot of effort abolishing high-frequency periodic wakeups, because they waste energy (battery). And apparently,...See https://gitlab.torproject.org/tpo/core/arti/-/issues/1040#note_2950549
I think this is rather poor. People have spent a lot of effort abolishing high-frequency periodic wakeups, because they waste energy (battery). And apparently, the work done is sufficiently extensive to make a test unreasonably slow.
(The test `tor_hsclient::state::test::expiry` is using a "giant leap" clock update because otherwise it has to similate every one of these wakeups.
Perhaps `tor_hsservice::timeout_track` could help.
### Old description
cc @gabi-250
Not a huge issue, but state::test::expiry now takes longer to run than any other test in Arti. Perhaps worth fixing if it's easy to do so?
(Found because I use `cargo-nextest`, which runs everything in parallel and displays the times.)Arti: Feature parity with the C implementationIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40861Look into build failures on modern Debian for CI on main2024-03-20T14:33:46ZAlexander Færøyahf@torproject.orgLook into build failures on modern Debian for CI on main@weasel reported a build issue on i386 with test failures. Have a look at:
```
180923 19:04:59 + weasel: sandbox/openat_filename: [forking] OK
180923 19:05:00 + weasel: sandbox/opendir_dirname: [forking]
180923 19:05:00 + ...@weasel reported a build issue on i386 with test failures. Have a look at:
```
180923 19:04:59 + weasel: sandbox/openat_filename: [forking] OK
180923 19:05:00 + weasel: sandbox/opendir_dirname: [forking]
180923 19:05:00 + weasel: FAIL ../src/test/test_sandbox.c:266: opendir: Operation not permitted [1]
180923 19:05:00 + weasel: [opendir_dirname FAILED]
180923 19:05:00 + weasel: sandbox/chmod_filename: [forking] OK
180923 19:05:00 + weasel: sandbox/chown_filename: [forking] OK
180923 19:05:02 + weasel: hm.
180923 19:05:17 + weasel: https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/367821
180923 19:05:59 + weasel: https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/367812
180923 19:06:00 + weasel: https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/367811
180923 19:06:04 + weasel: https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/367808
180923 19:06:06 + weasel: they all do that
180923 19:06:35 trinity-1686: maybe related to core/tor!446 ?
180923 19:06:35 -tor:#tor-dev- https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/446 - Fix sandbox on AArch64, RISC-V
180923 19:06:53 + weasel: i386
chat and mess w it
180923 19:09:48 + ahf: weasel: it's only impacting 0.4.9, right?
180923 19:09:56 + ahf: as in, main - not your 0.4.8 builds
180923 19:10:44 + weasel: maybe
180923 19:11:14 + weasel: if that's likely, then I'll push the signed tag and see how those go
180923 19:11:43 + ahf: 0.4.9 is main, so things can break there a bit more frequently than it should on any of the release-* branches
180923 19:12:34 + weasel: pushed the tag, let's see how that pipeline goes
180923 19:12:43 + ahf: oki, let us know how it goes!
180923 19:13:04 + weasel: https://gitlab.torproject.org/tpo/core/debian/tor/-/pipelines/104953 you can know as soon as I know :)
180923 19:13:34 + ahf: i am not going to monitor a build log for a hopeful success here - i am deep into other things in parallel
180923 19:41:39 + ahf: ../src/test/test_bt_cl.c: In function 'crash':
180923 19:41:40 + ahf: ../src/test/test_bt_cl.c:46:24: warning: null pointer dereference [-Wnull-dereference] 46 | *(volatile int *)0 = 0;
180923 19:41:43 + ahf: it's not wrong
180923 20:01:27 + weasel: 0.4.8 did build
180923 20:03:55 + ahf: so 0.4.9 has some build issue on ... all your debian's?
180923 20:06:57 + weasel: just i386 on more modern ones
180923 20:09:45 + ahf: so i386 on modern debian?
180923 20:09:55 + ahf: thank you, weasel
180923 20:09:59 + ahf: creating a ticket
```Tor: 0.4.8.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/docker-snowflake-proxy/-/issues/13Upload the container to our registry2024-03-03T14:07:46Zmicahmicah@torproject.orgUpload the container to our registryRight now, the only place you can pull the built container is from dockerhub. Now that Tor's gitlab has the container registry enabled, we should be building and pushing the container to our registry and consider that the main place we a...Right now, the only place you can pull the built container is from dockerhub. Now that Tor's gitlab has the container registry enabled, we should be building and pushing the container to our registry and consider that the main place we ask people to pull from.
This can be integrated into the CI relatively easily, and I've got some example for that, if it would be helpful!meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/1039netdoc: Sort introduction points before encoding2023-10-16T15:21:00ZNick Mathewsonnetdoc: Sort introduction points before encodingWe should ensure that our introduction points are sorted in some order before we encode them, so that we do not leak information about when we added them to our list of introduction points.
I don't think that this is specified in rend-s...We should ensure that our introduction points are sorted in some order before we encode them, so that we do not leak information about when we added them to our list of introduction points.
I don't think that this is specified in rend-spec or done by C tor (cc @dgoulet), but it's probably a good security feature to add in both of those places too.https://gitlab.torproject.org/tpo/core/arti/-/issues/1038Possibly, lower public part of key-bundle logic from hsclient to hscrypto?2024-01-10T20:11:25ZNick MathewsonPossibly, lower public part of key-bundle logic from hsclient to hscrypto?In `tor_hsclient::keys`, there is some code for managing secret keys from a client. While we decide whether to remove or disable `intro_auth` support there (#1037), we should also decide if it makes sense to lower this code into `tor-h...In `tor_hsclient::keys`, there is some code for managing secret keys from a client. While we decide whether to remove or disable `intro_auth` support there (#1037), we should also decide if it makes sense to lower this code into `tor-hscrypto`, since a lot of it will be shared with `tor-hsservice`.
In particular, we want the _public_ part of a key-bundle to be serialized and deserialized in either the format expected by C tor, or in the format expected by arti (discussed in #1028). Since clients will want to be able to generate and export their public keys, and services will want to be able to read them, it probably makes sense for the data structure itself to be shared.
cc @gabi-250Arti: Onion service supporthttps://gitlab.torproject.org/tpo/network-health/margot/-/issues/44margot throws error on first run2023-11-30T11:16:07ZGeorg Koppenmargot throws error on first runLet's say I run `margot` once a day. Every time in the last weeks I did that the first try always resulted in an error:
```
Error: deadline has elapsed
```
Once that error shows up and I run it again it works as expected. Ideally, it sho...Let's say I run `margot` once a day. Every time in the last weeks I did that the first try always resulted in an error:
```
Error: deadline has elapsed
```
Once that error shows up and I run it again it works as expected. Ideally, it should do so on the first run already, though. :)https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42107Strange connection issue with gitlab.io subdomains2023-10-17T10:47:20ZnervuriStrange connection issue with gitlab.io subdomainsFor Tor Browser (both 12.5.4 and 13.0a4) on Debian, gitlab.io subdomains fail to load on the first connection, but work on subsequent connections. The TLS handshake appears to fail on the first connection. There are, however, rare exce...For Tor Browser (both 12.5.4 and 13.0a4) on Debian, gitlab.io subdomains fail to load on the first connection, but work on subsequent connections. The TLS handshake appears to fail on the first connection. There are, however, rare exceptions in which the connection does work on the first try.
I have provided more details in [**this forum post**](https://forum.torproject.org/t/strange-issue-with-gitlab-io-subdomains/8265). There's also [**a reply by PieroV**](https://forum.torproject.org/t/strange-issue-with-gitlab-io-subdomains/8265/7) in which he lays out a hypothesis for why this is happening. This problem does not occur on Windows and Android.
The mystery is: why does it only happen on gitlab.io subdomains and why only for the GNU/Linux version of Tor Browser? Is it a purely local problem in TBB’s code, or can GitLab’s firewall tell that the first and second visits were made within the same browsing session? If so, how? What gives it away? It has to be a TCP or TLS-level thing, as HTTP isn't used in the first connection attempt.
Also, Tor Browser has the same JA3 fingerprint on both Linux and Android, their TLS configurations seem to be identical. So if it’s some kind of firewall issue on GitLab’s end, why doesn’t it block them both? How does it tell them apart? And how does it tell the first and second visits apart?
Example links to test with:
* https://charts.gitlab.io/
* https://sigvids.gitlab.io/
* https://wolfree.gitlab.io/
* https://tpoforks.gitlab.io/tor-browser-manual/
* https://oniondocs.gitlab.io/tbmanual/
I want to underscore that there are two parts to this issue:
1. Explaining why this happens (important).
2. Stopping it from happening (less important).
There's also a third, UI-related problem connected to this, I've created a separate issue for it: #42108.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42106SessionFileInternal.getWriter() called too early in new identity2023-10-11T21:37:25ZJeremyRandSessionFileInternal.getWriter() called too early in new identityWhile debugging #42085, Patrick from Whonix [took a log from the Tor Browser JS console](http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/tor-browser-refactored-control-port-tor-daemon-codebase/17164/14) aft...While debugging #42085, Patrick from Whonix [took a log from the Tor Browser JS console](http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/tor-browser-refactored-control-port-tor-daemon-codebase/17164/14) after the fixes from @pierov's testbuild were applied. There are still a few errors showing up in the log. Neither Patrick nor I am confident about whether they're harmless, so probably someone should investigate them.
The most concerning (to my untrained eye) log entries are:
```
NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIAppStartup.secondsSinceLastOSRestart]
_collectStartupConditionsTelemetry resource:///modules/BrowserGlue.sys.mjs:1649
BG__onFirstWindowLoaded resource:///modules/BrowserGlue.sys.mjs:1759
BG_observe resource:///modules/BrowserGlue.sys.mjs:981
_delayedStartup chrome://browser/content/browser.js:2106
BrowserGlue.sys.mjs:1658:15
```
```
uncaught exception: SessionFileInternal.getWriter() called too early! Please read the session file from disk first. 2
```
```
TypeError: this.client is undefined
RemoteSecuritySettings.sys.mjs:538:7
```
See the above forum link for full context on where the errors show up in the log. I have no idea whether these errors also show up in non-Whonix environments. To be clear, Patrick isn't observing any actually-wrong *behavior*, so *probably* everything is OK... but seems better to check than assume.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42105Mullvad Browser (maybe tor browser) on win11 with Desktop on Onedrive becomes...2023-10-11T21:40:15ZDan BallardMullvad Browser (maybe tor browser) on win11 with Desktop on Onedrive becomes unrunnableWill need more testing to reproduce, but a new laptop I was helping setup defaulted to Desktop on OneDrive. Mullvad Browser installed to desktop, ran, but shortly later could not be run. The `Start Mullvad Browser` link lined to Mullvard...Will need more testing to reproduce, but a new laptop I was helping setup defaulted to Desktop on OneDrive. Mullvad Browser installed to desktop, ran, but shortly later could not be run. The `Start Mullvad Browser` link lined to Mullvard Browser/Browser which was gone.
A little checking, OneDrive is case insensitive, I believe the fact we have a `Browser` executable and `browser` directory caused some collision cus sure enough, a bit after installing the `Browser` executable disappeared and Mullvad Browser was unrunnable. We've just unlinked OneDrive from the computer and it seems this is no longer happening.https://gitlab.torproject.org/tpo/applications/rbm/-/issues/40061Add some profiling instrumentation2023-12-05T18:19:53ZPier Angelo VendrameAdd some profiling instrumentationA few projects take a very long time between the log is opened and the build is actually started, mainly Android projects:
```
(datetime.timedelta(seconds=40), 'fonts-macos-x86_64.log')
(datetime.timedelta(seconds=40), 'fonts-windows-i6...A few projects take a very long time between the log is opened and the build is actually started, mainly Android projects:
```
(datetime.timedelta(seconds=40), 'fonts-macos-x86_64.log')
(datetime.timedelta(seconds=40), 'fonts-windows-i686.log')
(datetime.timedelta(seconds=42), 'fonts-linux-x86_64.log')
(datetime.timedelta(seconds=42), 'fonts-windows-x86_64.log')
(datetime.timedelta(seconds=49), 'llvm-runtimes-android-armv7.log')
(datetime.timedelta(seconds=104), 'tor-android-service-android-armv7.log')
(datetime.timedelta(seconds=125), 'tor-onion-proxy-library-android-armv7.log')
(datetime.timedelta(seconds=189), 'application-services-android-armv7.log')
(datetime.timedelta(seconds=223), 'geckoview-android-armv7.log')
(datetime.timedelta(seconds=228), 'geckoview-android-x86.log')
(datetime.timedelta(seconds=228), 'geckoview-android-x86_64.log')
(datetime.timedelta(seconds=232), 'geckoview-android-aarch64.log')
(datetime.timedelta(seconds=387), 'android-components-android-x86_64.log')
(datetime.timedelta(seconds=399), 'android-components-android-aarch64.log')
(datetime.timedelta(seconds=405), 'android-components-android-armv7.log')
(datetime.timedelta(seconds=406), 'android-components-android-x86.log')
(datetime.timedelta(seconds=430), 'fenix-android-x86_64.log')
(datetime.timedelta(seconds=443), 'fenix-android-aarch64.log')
(datetime.timedelta(seconds=447), 'fenix-android-x86.log')
(datetime.timedelta(seconds=456), 'fenix-android-armv7.log')
(datetime.timedelta(seconds=461), 'firefox-android-android-armv7.log')
```
AC and Fenix isn't a big deal, since we're switching to `firefox-android` only very soon.
However, it would be great to get a way of profiling why these projects are taking so long.
I think an option to print what's happening would work, too, at least to understand the problems.https://gitlab.torproject.org/tpo/core/arti/-/issues/1034High-level testing for onion service configuration parsing2023-10-31T16:47:20ZNick MathewsonHigh-level testing for onion service configuration parsingAs a followup to #699, I want to implement tests for our configuration formats like those in `arti::cfg.rs`.
There is a wrinkle here that onion services themselves do not exist by default, so the default configuration is just "", so I...As a followup to #699, I want to implement tests for our configuration formats like those in `arti::cfg.rs`.
There is a wrinkle here that onion services themselves do not exist by default, so the default configuration is just "", so I'm not sure the right way for us to test them via our existing mechanisms.
@diziet, please let me know how you think I should approach this. That is, what tests do you think I should write, and about what parts of the code should I tweak?Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/1032TLS reads and writes are not effectively buffered2023-10-19T15:03:21ZMicah Elizabeth ScottTLS reads and writes are not effectively buffered<!--
* Use this issue template for reporting a new bug.
-->
### Summary
This issue comes from the investigation behind https://gitlab.torproject.org/tpo/core/arti/-/issues/786, a code cleanup ticket about auto-flushing copiers. Those c...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
This issue comes from the investigation behind https://gitlab.torproject.org/tpo/core/arti/-/issues/786, a code cleanup ticket about auto-flushing copiers. Those copiers are one tool in a toolbox of I/O buffering strategies, so it raises questions about how the tool is being used, for what, and how effectively. I tried to get some idea of our end-to-end buffering behavior in Arti using strace, and the trace shows some areas for improvement.
### Steps to reproduce:
1. Release build, `cargo build --release`
2. Trace Arti to a file, no string dumps, `strace -s 0 -o trace.log -f target/release/arti -o application.permit_debugging=true proxy`
3. Generate some load.. how about downloading a complex application over HTTP2, `curl -x socks5h://localhost:9150 -v https://www.youtube.com/ | less`
### What is the current bug behavior?
There are several places where we may potentially have buffering issues, I'm looking at them individually in this test.
The SOCKS end might be fine. Reads are buffered into 1024-byte chunks, a little small in general for user/kernel buffers but okay in practice for HTTP. I'd recommend increasing this to 8K or so by default.
The very small reads I'm seeing (5 bytes) are actually on the TLS end. The size and context would explain this as a TLS record header read. Normally this would be buffered, we are missing a buffering layer here. TLS is reading using syscall buffer sizes that match the TLS records.
Writes on the SOCKS end are never larger than 1 cell, even when larger buffers are being processed on the input side of the stream.
Trace excerpts below.
### What is the expected behavior?
Ideally every wakeup from epoll_wait should result in some number of full (8K or so) buffers exchanged per socket plus no more than one under-full buffer per socket.
The TLS connection definitely needs to be buffered, and ideally we would have a way to flush multiple cells at once to the kernel when multiple cells are processed per wakeup.
### Environment
<!--
Please fill in the following information in bug reports, removing the comments like this one in brackets.
-->
- Version: git main
- Operating system: debian sid
### Relevant logs and/or screenshots:
FD 15 is TLS, 16 is SOCKS.
```
2386747 epoll_wait(3, [...], 1024, 664) = 1
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 531, 0, NULL, NULL) = 531
2386747 recvfrom(15, 0x7fc090213833, 5, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
2386747 sendto(16, ""..., 31, MSG_NOSIGNAL, NULL, 0) = 31
2386747 epoll_wait(3, [...], 1024, 524) = 1
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 4065, 0, NULL, NULL) = 4065
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 3679, 0, NULL, NULL) = 3679
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 4065, 0, NULL, NULL) = 3825
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 164, MSG_NOSIGNAL, NULL, 0) = 164
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 epoll_wait(3, [...], 1024, 481) = 1
2386747 recvfrom(15, ""..., 240, 0, NULL, NULL) = 240
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 81, 0, NULL, NULL) = 81
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 531, 0, NULL, NULL) = 531
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 4065, 0, NULL, NULL) = 581
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 310, MSG_NOSIGNAL, NULL, 0) = 310
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 11, MSG_NOSIGNAL, NULL, 0) = 11
2386747 epoll_wait(3, [...], 1024, 469) = 1
2386747 recvfrom(15, ""..., 3484, 0, NULL, NULL) = 2896
2386747 epoll_wait(3, [], 1024, 0) = 0
2386747 epoll_wait(3, [...], 1024, 363) = 1
2386747 recvfrom(15, ""..., 588, 0, NULL, NULL) = 588
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 4065, 0, NULL, NULL) = 4065
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 4065, 0, NULL, NULL) = 4065
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 1751, 0, NULL, NULL) = 1751
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 1045, 0, NULL, NULL) = 1045
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 4065, 0, NULL, NULL) = 4065
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 81, 0, NULL, NULL) = 81
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 4065, 0, NULL, NULL) = 4065
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 1109, 0, NULL, NULL) = 1109
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 4065, 0, NULL, NULL) = 2051
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 310, MSG_NOSIGNAL, NULL, 0) = 310
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
```
### Possible fixes:
The missing buffers on TLS can be fixed by adding buffers presumably, but we need to be very careful about the end-to-end flush behavior in order to balance latency and overhead. Write buffering may need to be written with KIST in mind, but read buffering should be straightforwardly implementable.https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/172bridges.torproject.org's alternative ways to get bridges doesn't mention tele...2024-03-04T15:32:55ZRoger Dingledinebridges.torproject.org's alternative ways to get bridges doesn't mention telegramOn https://bridges.torproject.org/options/ we have "I need an alternative way of getting bridges!" which mentions email, but it doesn't mention any of our newer mechanisms, like telegram, circumvention settings, etc.
We should either:
...On https://bridges.torproject.org/options/ we have "I need an alternative way of getting bridges!" which mentions email, but it doesn't mention any of our newer mechanisms, like telegram, circumvention settings, etc.
We should either:
* flesh out this page to properly list the various ways you can get bridges
or
* identify that there is a better page that already does this up to date list, and change the text here to simply point there.https://gitlab.torproject.org/tpo/core/arti/-/issues/1029non-anonymous hidden service configuration option details2023-10-31T16:46:50ZIan Jacksoniwj@torproject.orgnon-anonymous hidden service configuration option detailsCurrently (after !1557) the code expects this:
```
# in TOML
anonymity = "not_anonymous"
// in Rust
OnionServiceConfig::builder()
.anonymity(Anonymity::DangerouslyNonAnonymous)
...
```
IMO:
* This does not warrant "Dangerousl...Currently (after !1557) the code expects this:
```
# in TOML
anonymity = "not_anonymous"
// in Rust
OnionServiceConfig::builder()
.anonymity(Anonymity::DangerouslyNonAnonymous)
...
```
IMO:
* This does not warrant "Dangerously".
"Dangerously" should be reserved for APIs where the programmer takes on a proof obligation (eg a typecheck is being bypassed), or the configuration being requested is not expected to be safe for use in the real world, not ordinary config options. As precedent I offer (for example) `address_filter.allow_local_addrs`, `override_net_params`, `storage.permissions.trust_user`. Like in those caes, the right answer for "single onions" configuration is to name the configuration option so that it does what it says on the tin.
* I think the name in the config file and the name in the Rust source code should be the same.
* OTOH this is insufficiently explicit: IMO it should mention in the name or value (at least in the TOML) that it is the *server end* (ie, us) which is being non-anonymous (ie, this is a "Tor Hidden Service" but it is not in fact *hidden*). `anonymity = "not_anonymous"` might mean that it is the *clients* who don't get anonymity.
I don't have particularly strong opinions about the precise names, subject to the above constraints. Following on from some things I said in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1557#note_2938351, how about:
```
# in TOML
server_end_privacy = "non_anonymous"
// in Rust
OnionServiceConfig::builder()
.server_end_privacy(Anonymity::NonAnonymous)
...
```
I suspect that the above arguments won't be convincing to @nickm. I suggest we get a third opinion, and go with that. Although I would like this changed before we release, this is a bit of a bikeshed.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/1026Could not connect to guard2023-11-13T14:55:35ZLowLandMink543Could not connect to guard### Summary
When build arti from source following direction from README.md, arti builds successfully and compiles but is unable to connect to any
### Steps to reproduce:
1. Clone the Arti branch with hash a05d64d7f1424f140c49a5897f05...### Summary
When build arti from source following direction from README.md, arti builds successfully and compiles but is unable to connect to any
### Steps to reproduce:
1. Clone the Arti branch with hash a05d64d7f1424f140c49a5897f05b26a1eef7c2d, better known as release 1.1.8
2. Build arti create as a release bundle
2. Open a command prompt or PowerShell window
3. Navigate to the release binary
4. Run the binary with the command `arti.exe proxy`
### What is the current bug behavior?
Arti fails to connect to guard nodes
### What is the expected behavior?
Arti will connect to a guard node and then establish the rest of a 3 hop circuit without any significant errors
### Environment
- Cargo Version: 1.69.0
- RustC Version: 1.69.0
- Operating System: Windows 11 Home 22H2 22621.2215
- Install Method: Building from source
### Relevant logs and/or screenshots:
[Arti Trace Log](/uploads/4eeebc7554be0c35cd8cd3f1caa8453f/arti-trace.log)
[Arti Info Log](/uploads/7930d013a1587ff03295937c6e1a63ef/arti-info.log)
### Possible fixes:
Unknown at this timeArti: Feature parity with the C implementation