Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T18:21:52Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33669"Pluggable Transport process terminated" but Tor keeps on going (and of cours...2020-06-13T18:21:52ZRoger Dingledine"Pluggable Transport process terminated" but Tor keeps on going (and of course doesn't work)In https://trac.torproject.org/projects/tor/ticket/33336#comment:20 I encountered the unfortunate situation where my snowflake client exited:
```
Feb 25 14:36:24.458 [warn] Pluggable Transport process terminated with status code 512
```
...In https://trac.torproject.org/projects/tor/ticket/33336#comment:20 I encountered the unfortunate situation where my snowflake client exited:
```
Feb 25 14:36:24.458 [warn] Pluggable Transport process terminated with status code 512
```
It still remains unclear whether snowflake had a bug that crashed it, or if Tor has a bug that made it close the socket to snowflake.
But either way, after this event Tor quietly cries to itself:
```
Feb 25 14:36:44.825 [warn] The connection to the SOCKS5 proxy server at 127.0.0.1:45527 just failed. Make sure that the proxy server is up and running.
```
and Tor Browser has no idea this is happening, or that trying to use Tor is now hopeless.
We should figure out something smarter that Tor should do in this situation. Perhaps it should exit, forcing the user to notice? Perhaps it should emit an event that Tor Browser picks up on? Maybe we have an even better idea?Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/32562Allow ONION_CLIENT_AUTH_ADD credentials to be made permanent2020-06-13T15:48:25ZGeorge KadianakisAllow ONION_CLIENT_AUTH_ADD credentials to be made permanentThe Permanent flag of ONION_CLIENT_AUTH_ADD is not implemented yet.The Permanent flag of ONION_CLIENT_AUTH_ADD is not implemented yet.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30381Provide control port commands to ADD/REMOVE/VIEW v3 client-auth2020-06-13T15:46:25ZGeorge KadianakisProvide control port commands to ADD/REMOVE/VIEW v3 client-authWe need control port commands so that TB can add/remove/view client auth credentials.
Furthermore, the 'add' command should be able to decrypt any existing non-decryptable descriptors in the cache (see #30382).We need control port commands so that TB can add/remove/view client auth credentials.
Furthermore, the 'add' command should be able to decrypt any existing non-decryptable descriptors in the cache (see #30382).Tor: 0.4.3.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/29893have a way to create forwards for the old links that are going to be broken w...2020-06-13T17:27:40Zemmapeelhave a way to create forwards for the old links that are going to be broken with the tpo website moveWe maybe can use an .htaccess file or another method, but we should map the links we are going to brake and make the corresponding forwards to the new links.We maybe can use an .htaccess file or another method, but we should map the links we are going to brake and make the corresponding forwards to the new links.website redesignHiroHirohttps://gitlab.torproject.org/legacy/trac/-/issues/29850localize sublinks so you stay on the current language2020-06-13T17:27:39Zemmapeellocalize sublinks so you stay on the current language* go to https://lektor-staging.torproject.org/tpo/staging/es/about/history/
* click on 'informes' on the menu under the title
* you are sent to /staging/about/reports/ , instead of /es/staging/about/reports/ (mind the /es).
what shou...* go to https://lektor-staging.torproject.org/tpo/staging/es/about/history/
* click on 'informes' on the menu under the title
* you are sent to /staging/about/reports/ , instead of /es/staging/about/reports/ (mind the /es).
what should happen:
* You stay navigating in /es/ as you have selected it previously.
note: it works ok for button About that is part of the menu at the top of the page: that button changes along with the selected language.website redesignHiroHirohttps://gitlab.torproject.org/legacy/trac/-/issues/29849first text is duplicated when browsing /about/* subpages2020-06-13T17:27:39Zemmapeelfirst text is duplicated when browsing /about/* subpagesWhen browsing pages on the new tpo site, the first two paragraphs are duplicated, see:
https://lektor-staging.torproject.org/tpo/staging/es/about/history/When browsing pages on the new tpo site, the first two paragraphs are duplicated, see:
https://lektor-staging.torproject.org/tpo/staging/es/about/history/website redesignHiroHirohttps://gitlab.torproject.org/legacy/trac/-/issues/28532Map link changes from current tpo to lektor projects2020-06-13T17:27:17ZtraumschuleMap link changes from current tpo to lektor projectsTo port tpo and wiki content to lektor it helps to document where content of current pages reappears and to concentrate scattered info a bit. This eventually can be useful for rewrite rules.
The goal is to create a list of pages with a ...To port tpo and wiki content to lektor it helps to document where content of current pages reappears and to concentrate scattered info a bit. This eventually can be useful for rewrite rules.
The goal is to create a list of pages with a link to the old and new locations.
* Overview: #21222, [[Website/MainSiteRedesign]]
* Sitemap: #10591, #25637, #25638
- #24131: https://torproject.org - outline: #22198, sitemap: #25637, #25638
- #24129: https://support.torproject.org - sketches: #22200
- [/projects/tor/query?status=!closed&component=Community%2FTor+Browser+Manual tb-manual]: https://tb-manual.torproject.org
- #24133: https://community.torproject.org - sketches: comment:5:issue:24133
- #24132: https://dev.torproject.org - structure: #22199
Previews: https://lektor-staging.torproject.org/website redesignhttps://gitlab.torproject.org/legacy/trac/-/issues/27691reset bootstrap progress when enough things change2020-06-13T15:31:22ZTaylor Yureset bootstrap progress when enough things changeRight now, setting DisableNetwork=1 doesn't reset the bootstrap progress indicator. It probably should, because all network connections to bridges or relays will close. This will improve the user experience once we have #27103 in place...Right now, setting DisableNetwork=1 doesn't reset the bootstrap progress indicator. It probably should, because all network connections to bridges or relays will close. This will improve the user experience once we have #27103 in place, because then the earlier progress shown will be the initial network connection that everything else depends on.
We probably also want to reset the bootstrap progress when a configuration change causes us to disconnect from all our guards.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27308report bootstrap phase when we actually start, not just unblock something2020-06-13T15:30:07ZTaylor Yureport bootstrap phase when we actually start, not just unblock somethingRight now many bootstrap events get reported when the preceding task has completed. This makes it somewhat harder to tell what has gone wrong if bootstrap progress stalls.
[edit: The following isn't necessarily the best way to fix this...Right now many bootstrap events get reported when the preceding task has completed. This makes it somewhat harder to tell what has gone wrong if bootstrap progress stalls.
[edit: The following isn't necessarily the best way to fix this. It might be better to figure out how to report starting something when actually starting it.]
We should add completion milestones to bootstrap reporting. This makes bootstrap reporting more future-proof. If in the future we add a time-consuming task with (no bootstrap reporting) between two existing bootstrap tasks, it will be a little more obvious what's going on.
For example, say we have task X followed by task Z, but then we add a lengthy task Y without adding bootstrap reporting to it. In the old scheme without completion milestones, if Y stalls, the user sees:
* starting X
* starting Z
* [hang]
The user thinks Z has already started when no such thing has happened because Y is still in progress. If we add completion milestones, the user will see:
* starting X
* finished X
* starting Z
* finishing Z
in a normal bootstrap. If something gets stuck in task Y, the user will see:
* starting X
* finished X
* [hang]
This will make it more clear that something got stuck in between tasks.
In a one-line display like Tor Launcher, the completion milestones will normally flash by quickly and not be very visible to users. Completion milestones might make the NOTICE logs a bit more verbose.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27239TB team feedback on jump-to-80% work2020-06-16T00:49:21ZIsabela FernandesTB team feedback on jump-to-80% workHello TB team,
we would like your feedback on this work, and let us know if there is anything we need to know regarding this on Tor Browser side.Hello TB team,
we would like your feedback on this work, and let us know if there is anything we need to know regarding this on Tor Browser side.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/27169monitor bootstrap directory info progress separately2020-06-13T15:34:23ZTaylor Yumonitor bootstrap directory info progress separatelyAbstract out the current monitoring of bootstrap directory information progress, so we can track it state more independently. This allows us to defer reporting that we have sufficient directory information until we know that we can actua...Abstract out the current monitoring of bootstrap directory information progress, so we can track it state more independently. This allows us to defer reporting that we have sufficient directory information until we know that we can actually connect to a relay or bridge at all.
This also allows us to eliminate or simplify special case logic in `control_event_bootstrap()` that handles incremental progress during descriptor downloads.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/27167track "first" OR_CONN2020-06-13T17:44:18ZTaylor Yutrack "first" OR_CONNRight now the first stages of the "first" OR_CONN get reported as `BOOTSTRAP_STATUS_CONN_DIR` and `BOOTSTRAP_STATUS_HANDSHAKE` (the latter is a special bootstrap phase that gets translated into `BOOTSTRAP_STATUS_HANDSHAKE_DIR` or `BOOTST...Right now the first stages of the "first" OR_CONN get reported as `BOOTSTRAP_STATUS_CONN_DIR` and `BOOTSTRAP_STATUS_HANDSHAKE` (the latter is a special bootstrap phase that gets translated into `BOOTSTRAP_STATUS_HANDSHAKE_DIR` or `BOOTSTRAP_STATUS_HANDSHAKE_OR` depending on how much progress was previously reported. The logic in functions that report these events should be moved up to a new abstraction so lower level code has to track less high-level state.
This also eliminates some logic in `control_event_bootstrap()` that tries to figure out whether a given handshake attempt corresponds to a directory connection or an application circuit connection.Tor: 0.4.0.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/27132find Tor-friendly payment site2020-06-13T17:37:26Ztraumschulefind Tor-friendly payment siteFrom parent #11569
> it seems the clear next step is to find one not-totally-unusable payment site that doesn't hate Tor users, and drive all the traffic there.From parent #11569
> it seems the clear next step is to find one not-totally-unusable payment site that doesn't hate Tor users, and drive all the traffic there.WebsiteV3https://gitlab.torproject.org/legacy/trac/-/issues/27104report intermediate status when building application circuits2020-06-13T15:29:19ZTaylor Yureport intermediate status when building application circuitsDuring bootstrap, some minimum number of application circuits must be established before bootstrapping will complete. Right now, the user will receive no feedback of intermediate progress as a bootstrap circuit is being built. We shoul...During bootstrap, some minimum number of application circuits must be established before bootstrapping will complete. Right now, the user will receive no feedback of intermediate progress as a bootstrap circuit is being built. We should make this more granular, probably with intermediate progress at each EXTEND, to make visible when Tor is being slow to build circuits.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27103report initial OR_CONN as the earliest bootstrap phases2020-06-13T15:31:22ZTaylor Yureport initial OR_CONN as the earliest bootstrap phasesWe should always make the earliest bootstrap phases be our first connection to any OR, regardless of whether we already have enough directory info to start building circuits.
When starting to boostrap with existing directory info, there...We should always make the earliest bootstrap phases be our first connection to any OR, regardless of whether we already have enough directory info to start building circuits.
When starting to boostrap with existing directory info, there might not be a need to make an initial connection to a bridge or fallback directory server to download directory info. This means that the initial OR_CONN to a bridge or guard displays on a progress bar as 80%, when in fact a fairly "early" dependency (the initial connection to any OR) could be failing.
Intuitively, starting Tor Browser and seeing the progress bar hang at 80% for a very long time is frustrating and misleading. A user who sees the progress bar hang at at 5% or 10% has a much better idea of what's going on.
Existing directory info can be reflected in the progress bar as a rapid jump after the initial OR_CONN succeeds. This seems less likely to frustrate users.Tor: 0.4.0.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/27102gather feedback re decoupling bootstrap progress numbers from BOOTSTRAP_STATU...2020-06-13T15:29:17ZTaylor Yugather feedback re decoupling bootstrap progress numbers from BOOTSTRAP_STATUS enum valuesIf we start reporting intermediate bootstrap phases, for example when reporting PT status when connecting to the Tor network through a PT bridge (#25502), there aren't many numbers remaining to insert between some existing phases (if we ...If we start reporting intermediate bootstrap phases, for example when reporting PT status when connecting to the Tor network through a PT bridge (#25502), there aren't many numbers remaining to insert between some existing phases (if we stick to integers).
We should decouple these so we don't have to cram everything into a tiny portion of the progress bar. It also doesn't make sense to report progress phases that we will never need to execute.
Alternatively, renumber the enums to give us more space toward the beginning of the progress bar.Tor: 0.4.0.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/25713"DisableNetwork is set" log message in Tor Browser scares/confuses users2020-06-13T15:24:08ZRoger Dingledine"DisableNetwork is set" log message in Tor Browser scares/confuses usersWhen Tor Browser has trouble connecting, we tell users to go look at the logs. The first thing they see in their logs is something like
```
13/06/2017 11:31:29.600 [NOTICE] DisableNetwork is set. Tor will not make
or accept non-c...When Tor Browser has trouble connecting, we tell users to go look at the logs. The first thing they see in their logs is something like
```
13/06/2017 11:31:29.600 [NOTICE] DisableNetwork is set. Tor will not make
or accept non-control network connections. Shutting down all existing
connections.
```
and if they're hunting for a log message that gives them a hint about why Tor doesn't work, that one is easy to find and seems really related to why their tor might not work.
So we have this recurring event where users come to us and say "My Tor Browser isn't working, it says DisableNetwork is set."
Now, Tor Browser legitimately starts Tor with DisableNetwork set, so Tor Browser will have time to ask the user whether they want to use bridges or proxies or etc before their Tor starts interacting with the network. So "well stop using that option then" is hopefully not our best plan.
But I wonder if there is a smarter way to have that phrased in the logs, so users have a better chance of guessing correctly what is going on.
(Long term we want to not send Tor Browser users to go read Tor's logs. But we're not there yet either.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25642translation of torproject.org2020-06-13T17:26:24ZIsabela Fernandestranslation of torproject.orgthis ticket is to track the work to send string to be translated and translation progress of it.this ticket is to track the work to send string to be translated and translation progress of it.website redesignemmapeelemmapeelhttps://gitlab.torproject.org/legacy/trac/-/issues/25641content for torproject.org2020-06-13T17:26:23ZIsabela Fernandescontent for torproject.orgThis ticket is to track the work to create content and review content related to the new torproject.org site
https://storm.torproject.org/shared/wyGr33d_9LtKwtleVpg5kOvP_XM2S2Zm01UpHgrWYnaThis ticket is to track the work to create content and review content related to the new torproject.org site
https://storm.torproject.org/shared/wyGr33d_9LtKwtleVpg5kOvP_XM2S2Zm01UpHgrWYnawebsite redesignIsabela FernandesIsabela Fernandeshttps://gitlab.torproject.org/legacy/trac/-/issues/25640coding torproject.org2020-06-13T17:26:23ZIsabela Fernandescoding torproject.orgticket to track the coding work for torproject.org new siteticket to track the coding work for torproject.org new sitewebsite redesignHiroHiro