The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-01-07T16:46:16Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40060server is still logging io.ErrClosedPipe errors because of wrapped errors2022-01-07T16:46:16ZDavid Fifielddcf@torproject.orgserver is still logging io.ErrClosedPipe errors because of wrapped errorsDespite !30, the Snowflake server is still logging `io.ErrClosedPipe` errors:
```
2021/06/24 17:41:12 error copying WebSocket to ORPort readfrom tcp [scrubbed]->[scrubbed]: io: read/write on closed pipe
2021/06/24 17:46:11 acceptStreams...Despite !30, the Snowflake server is still logging `io.ErrClosedPipe` errors:
```
2021/06/24 17:41:12 error copying WebSocket to ORPort readfrom tcp [scrubbed]->[scrubbed]: io: read/write on closed pipe
2021/06/24 17:46:11 acceptStreams: io: read/write on closed pipe
2021/06/24 17:46:33 error copying WebSocket to ORPort readfrom tcp [scrubbed]->[scrubbed]: io: read/write on closed pipe
2021/06/24 18:20:20 error copying ORPort to WebSocket io: read/write on closed pipe
```
The reason is that the errors are not really `io.ErrClosedPipe`; they are wrapped by [`errors.WithStack`](https://pkg.go.dev/github.com/pkg/errors#WithStack) in kcp-go. You can see the different using `log.Printf("%T", err)`, which yields `*errors.withStack`.
I was having the same problem in the dnstt server. I solved it by using [`errors.Is`](https://pkg.go.dev/errors#Is) from the [go1.13 errors interface](https://blog.golang.org/go1.13-errors), rather than plain equality.
https://repo.or.cz/dnstt.git/commitdiff/e4dc2883efea932f1da62ef35c3e88806aed9eeahttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40007Clean up unused bridgedb mock2021-12-16T11:56:42ZCecylia BocovichClean up unused bridgedb mock`bridgedb mock` was an old utility for generating mock bridgedb descriptors for tests. This functionality has been replaced with the new `./scripts/create_descriptors`. It's also currently broken. Rather than fixing it, it would be bette...`bridgedb mock` was an old utility for generating mock bridgedb descriptors for tests. This functionality has been replaced with the new `./scripts/create_descriptors`. It's also currently broken. Rather than fixing it, it would be better to just remove it all-together.55abhilash55abhilashhttps://gitlab.torproject.org/tpo/web/manual/-/issues/25Sidebar doesn't display all the topics2021-12-13T18:28:34ZGusSidebar doesn't display all the topicsYou need to scroll down the page to see "Mobile Tor" itemYou need to scroll down the page to see "Mobile Tor" itemhttps://gitlab.torproject.org/tpo/web/community/-/issues/159[Relay Operations] Issues with formatting2021-11-12T11:19:40Zchampionquizzerchampionquizzer@torproject.org[Relay Operations] Issues with formattingOn the ['Relay Operations/Technical Setup/Bridge' page for various operating systems](https://community.torproject.org/relay/setup/bridge/) -
1. All the terminal commands must be formatted in the manner other commands are in order to ...On the ['Relay Operations/Technical Setup/Bridge' page for various operating systems](https://community.torproject.org/relay/setup/bridge/) -
1. All the terminal commands must be formatted in the manner other commands are in order to maintain a consistency throughout our docs.
2. It must be mentioned whether to run the commands as user or as root (by $ and #/sudo respectively)(like it has been explained on this [page](https://support.torproject.org/rpm/#install)).https://gitlab.torproject.org/tpo/web/community/-/issues/236Relay operations is missing from secondary navbar2021-10-29T19:59:35ZemmapeelRelay operations is missing from secondary navbarThe secondary navbar that we have on the different sections of the website is missing the Relay Operations link. See the 6 sections on the homepage:
![all-sections.cleaned](/uploads/97700a38f46adaa78a4d2dd8354bfd21/all-sections.cleaned....The secondary navbar that we have on the different sections of the website is missing the Relay Operations link. See the 6 sections on the homepage:
![all-sections.cleaned](/uploads/97700a38f46adaa78a4d2dd8354bfd21/all-sections.cleaned.png)
And only 5 sections on the navbar:
![missig-relays.cleaned](/uploads/bd7a13aa9b381de314f5fd257c43a558/missig-relays.cleaned.png)https://gitlab.torproject.org/tpo/core/arti/-/issues/164Brainstorm some example programs to ship with arti 0.0.12021-10-29T16:25:01ZNick MathewsonBrainstorm some example programs to ship with arti 0.0.1We've found that example code is a good way to teach the APIs, and also to make sure that the APIs are nice and simple.
This is not the ticket for writing that example code; this is the ticket for deciding what we want to write in order...We've found that example code is a good way to teach the APIs, and also to make sure that the APIs are nice and simple.
This is not the ticket for writing that example code; this is the ticket for deciding what we want to write in order to document and refine our APIs a little in our 0.0.1 milestone phase.
cc @dgoulet @ahfArti 0.0.1 release: basic anonymityhttps://gitlab.torproject.org/tpo/web/community/-/issues/213Come up with a better terminology for bridges2021-10-27T13:31:53ZPhilipp Winterphw@torproject.orgCome up with a better terminology for bridgesOur terminology for bridges is confusing:
* *Private* bridges are bridges that BridgeDB doesn't know about. Users may mistakenly conclude that if a bridge isn't private, it must be public, which is incorrect. Suggestions for other terms:...Our terminology for bridges is confusing:
* *Private* bridges are bridges that BridgeDB doesn't know about. Users may mistakenly conclude that if a bridge isn't private, it must be public, which is incorrect. Suggestions for other terms: unshared, exclusive, unlisted, unknown.
* *Default* bridges are part of Tor Browser. Conceptually, default bridges are more like obfs4-enabled guard relays. Suggestions for other terms: built-in (we may have been using that term occasionally), standard, public.
* We don't have a consistent term for bridges that are distributed by BridgeDB/rdsys. Perhaps we don't need a term because that's the default?
How can we improve the situation?
Copying @cohosh, @antonela, @arma, and @gus.
# Update
proposal is to change this terminology **everywhere**
- default bridges -> built-in bridges
- will not do private/public bridges anymore
- private bridges -> secret bridges
- public bridges -> distributed bridges
Everywhere means:
- [ ] documentation - needs tickets in each portal
- [ ] [Browser's UI](tpo/applications/tor-browser#40623)
- [ ] Code - needs ticketSponsor 30 - Objective 2.2GusGushttps://gitlab.torproject.org/tpo/core/arti/-/issues/149MockSleepRuntime::wait_for doesn't work very well.2021-10-26T17:14:56ZNick MathewsonMockSleepRuntime::wait_for doesn't work very well.For testing, we have the capacity to replace the regular timer implementation from our asynchronous runtime with a fake one that doesn't ever have to actually wait. That's `MockSleepProvider` and `MockSleepRuntime` in the `tor-rtmock` cr...For testing, we have the capacity to replace the regular timer implementation from our asynchronous runtime with a fake one that doesn't ever have to actually wait. That's `MockSleepProvider` and `MockSleepRuntime` in the `tor-rtmock` crate.
We also provide another function that tries to run a future to completion, while advancing "mock time" step by step until it is ready. That's `MockSleepRuntime::wait_for` in `tor-rtmock/src/sleep_runtime.rs`. But unfortunately, it doesn't work too well, and I'm not sure why. I had it advancing one millisecond at a time, but the tests would fail under some circumstances when I did that (specifically, the circmgr tests under test coverage). I had to decrease the increment to 10 microseconds to make it work, which suggests to me that there is some fundamental problem in this code with making sure that all our futures get polled when they ought to get polled.
I'm marking this as ~"First Contribution" , but it is probably not a good fit for anybody without a deep understanding of Rust async implementations and their internals. On the other hand, if you know that stuff very well, you probably don't need to know Arti at all to solve this ticket.Arti 0.0.1 release: basic anonymityetaetahttps://gitlab.torproject.org/tpo/web/lego/-/issues/33Add Discourse forum logo on the footer2021-10-25T19:31:15ZGusAdd Discourse forum logo on the footerAs part of our [Soft launch plan](https://gitlab.torproject.org/tpo/web/team/-/wikis/Plan-To-Launch-Tor's-Forum#timeline), we need to add [Discourse logo](https://fontawesome.com/v5.15/icons/discourse) on the footer.As part of our [Soft launch plan](https://gitlab.torproject.org/tpo/web/team/-/wikis/Plan-To-Launch-Tor's-Forum#timeline), we need to add [Discourse logo](https://fontawesome.com/v5.15/icons/discourse) on the footer.2021-10-20https://gitlab.torproject.org/tpo/web/community/-/issues/233[Onion Services] Update NYT onion service2021-10-20T13:23:15Zchampionquizzerchampionquizzer@torproject.org[Onion Services] Update NYT onion serviceNew York Times have updated their onion service to v3: https://www.nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lljsciiyd.onion/
.. and we must update it on the 'featured onions' section: https://community.torproject.org/onion-servic...New York Times have updated their onion service to v3: https://www.nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lljsciiyd.onion/
.. and we must update it on the 'featured onions' section: https://community.torproject.org/onion-services/#featured-onions
Proof: TLS/SSL certificate and onion-location header on https://www.nytimes.com/HackerNCoderhackerncoder@encryptionin.spaceHackerNCoderhackerncoder@encryptionin.spacehttps://gitlab.torproject.org/tpo/core/tor/-/issues/22469tor should probably reject "0x00" in port range specifications2021-10-04T19:22:56Ztoralftor should probably reject "0x00" in port range specificationssomething like
```
ExitPolicy reject6 [2a00:1450:4001:0815:0000:0000:0000:200e]:0x00
```
should spew an error message.something like
```
ExitPolicy reject6 [2a00:1450:4001:0815:0000:0000:0000:200e]:0x00
```
should spew an error message.https://gitlab.torproject.org/tpo/core/tor/-/issues/25284hidden-service-dir description in dir-spec should reference HSDir protovers2021-09-30T13:50:08Zteorhidden-service-dir description in dir-spec should reference HSDir protoversSince 0.3.0, tor supports HSDir versions 2 and 3 by default, and advertises no hidden-service-dir VersionNums.
But the spec says:
"If any VersionNum(s) are specified, this router supports those descriptor versions. If none are specified...Since 0.3.0, tor supports HSDir versions 2 and 3 by default, and advertises no hidden-service-dir VersionNums.
But the spec says:
"If any VersionNum(s) are specified, this router supports those descriptor versions. If none are specified, it defaults to version 2 descriptors"Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25116hs: circuit_log_ancient_one_hop_circuits() should probably not log single oni...2021-09-30T13:50:08ZDavid Gouletdgoulet@torproject.orghs: circuit_log_ancient_one_hop_circuits() should probably not log single onion service rendezvous circuitAssume an email server where clients often keep a connection open and regularly exchange traffic on them.
Making that email server an .onion, RP circuits will stay open for a while and more than 1800 seconds which is the cutoff of `circ...Assume an email server where clients often keep a connection open and regularly exchange traffic on them.
Making that email server an .onion, RP circuits will stay open for a while and more than 1800 seconds which is the cutoff of `circuit_log_ancient_one_hop_circuits()` to log single hop circuits.
I think we want to ignore to log anything service related in there. Some v3 services have started seeing that heartbeat more and more in the last days.
Related: legacy/trac#8387Tor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25108hs: nodelist_recompute_all_hsdir_indices() is not used2021-09-30T13:50:08ZDavid Gouletdgoulet@torproject.orghs: nodelist_recompute_all_hsdir_indices() is not usedDead code that we should remove.Dead code that we should remove.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24991relay frequently claiming "missing descriptors for 1/2 of our primary entry g...2021-09-30T13:50:08Zalecmuffettrelay frequently claiming "missing descriptors for 1/2 of our primary entry guards"This is the first of a pair of bugs with the same logfiles, so unless requested I'll only attach the logs once, here, unless there's a real need to duplicate them.
I have an EOTK SingleOnion, config attached.
Per the logfile, it is bo...This is the first of a pair of bugs with the same logfiles, so unless requested I'll only attach the logs once, here, unless there's a real need to duplicate them.
I have an EOTK SingleOnion, config attached.
Per the logfile, it is both HiddenServiceSingleHopMode and HiddenServiceNonAnonymousMode.
It's from "dropsafezeahmyho" which is the onion for my personal blog (dropsafe.crypticide.com) which is very low traffic as an Onion, in fact it exists mostly as a test onion.
Issue #1 - after an extended period of uptime, tor claims:
```
Jan 21 08:45:04.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 5975/6006).
Jan 21 08:45:04.000 [notice] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 5975/6006).
```
...which should not be happening, because (as a single onion) there are no Guards.
Issue 2 will be described in the next ticket, and linked back to this one.
Attachments: logfile and configfile.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25661RendPostPeriod and HiddenServiceAuthorizeClient are v2 only2021-09-30T13:46:29ZteorRendPostPeriod and HiddenServiceAuthorizeClient are v2 onlyRendPostPeriod and HiddenServiceAuthorizeClient only apply to v2 onion services. We should update the man page so this is clearer.RendPostPeriod and HiddenServiceAuthorizeClient only apply to v2 onion services. We should update the man page so this is clearer.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26932Soft assert in HS3 with vanguards ([warn] Invalid signature for service descr...2021-09-30T13:45:56ZGeorge KadianakisSoft assert in HS3 with vanguards ([warn] Invalid signature for service descriptor signing key: expired)I recently got the following soft assert on my HSv3 with latest master:
```
Jul 22 09:05:41.000 [warn] Invalid signature for service descriptor signing key: expired
Jul 22 09:05:41.000 [warn] tor_bug_occurred_(): Bug: src/feature/hs/hs_...I recently got the following soft assert on my HSv3 with latest master:
```
Jul 22 09:05:41.000 [warn] Invalid signature for service descriptor signing key: expired
Jul 22 09:05:41.000 [warn] tor_bug_occurred_(): Bug: src/feature/hs/hs_descriptor.c:2367: hs_desc_encode_descriptor: Non-fatal assertion !(ret < 0) failed. (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: Non-fatal assertion !(ret < 0) failed in hs_desc_encode_descriptor at src/feature/hs/hs_descriptor.c:2367. Stack trace: (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(log_backtrace_impl+0x47) [0x7f9979f5b437] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(tor_bug_occurred_+0xbe) [0x7f9979f56d0e] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(hs_desc_encode_descriptor+0xb2) [0x7f9979e5dba2] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(hs_service_run_scheduled_events+0x1a75) [0x7f9979e64ac5] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(+0x51fb1) [0x7f9979dc4fb1] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(+0x593b1) [0x7f9979dcc3b1] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f99793f63dc] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(do_main_loop+0x203) [0x7f9979dc8e13] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(tor_run_main+0x2a5) [0x7f9979dca325] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(tor_main+0x3a) [0x7f9979dc364a] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(main+0x19) [0x7f9979dc33b9] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f99785e92b1] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(_start+0x2a) [0x7f9979dc340a] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
```
I'm suspecting it might have to do with the legacy/trac#25552 fix because the code changed there is relevant to this bug, altho I don't see how it can cause this bug.
Based on the logs, it seems like my HSv3 kept that descriptor around for about 56 hours when the descriptor signing key cert lifetime is 54 hours (see `HS_DESC_CERT_LIFETIME`).Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28560hs: Mention in the manpage that Sandbox and adding a service with the control...2021-09-30T13:25:26ZDavid Gouletdgoulet@torproject.orghs: Mention in the manpage that Sandbox and adding a service with the control port failsFrom legacy/trac#16106.
We can't tell the sandbox about a new `HiddenServiceDir` at runtime so this will always fail until we get a better sandbox system.
For now, we should at least document it in the manpage.From legacy/trac#16106.
We can't tell the sandbox about a new `HiddenServiceDir` at runtime so this will always fail until we get a better sandbox system.
For now, we should at least document it in the manpage.Tor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/web/community/-/issues/230[onion services] Update BBC onion site2021-09-28T12:02:24ZGus[onion services] Update BBC onion siteBBC upgraded their onion site to v3. Let's update the featured onions page:
https://www.bbcnewsd73hkzno2ini43t4gblxvycyac5aw4gnv7t2rccijh7745uqd.onion/
https://community.torproject.org/onion-services/#featured-onionsBBC upgraded their onion site to v3. Let's update the featured onions page:
https://www.bbcnewsd73hkzno2ini43t4gblxvycyac5aw4gnv7t2rccijh7745uqd.onion/
https://community.torproject.org/onion-services/#featured-onionshttps://gitlab.torproject.org/tpo/core/fallback-scripts/-/issues/26502Stop using the fallback blacklist, and delete it2021-09-16T14:48:14ZteorStop using the fallback blacklist, and delete itWe require relay operators to opt-in to being fallbacks, and we won't ever switch to opt-out. (See legacy/trac#24789.)
So we don't need the fallback blacklist any more.
We should stop loading the blacklist in the script, then delete it.We require relay operators to opt-in to being fallbacks, and we won't ever switch to opt-out. (See legacy/trac#24789.)
So we don't need the fallback blacklist any more.
We should stop loading the blacklist in the script, then delete it.Tor: 0.3.5.x-final