The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-10-19T20:40:14Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40111Move bridge to a permanent faster server2022-10-19T20:40:14ZDavid Fifielddcf@torproject.orgMove bridge to a permanent faster serverBackground: [\[tor-project\] More resources required for Snowflake bridge](https://forum.torproject.net/t/tor-project-more-resources-required-for-snowflake-bridge/2353)
I expect to be able to move the snowflake bridge to a more permanen...Background: [\[tor-project\] More resources required for Snowflake bridge](https://forum.torproject.net/t/tor-project-more-resources-required-for-snowflake-bridge/2353)
I expect to be able to move the snowflake bridge to a more permanent home on a faster server after 2022-03-21.
#40110 is to use a *different* faster server in the meantime, until the permanent one is prepared.
- [x] get access to new server hardware
- [x] install new bridge ([installation guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide))
- [x] copy user accounts https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40091#note_2768855
- [x] copy identity and onion keys from existing bridge
- [x] double check onion keys
```
# md5sum /var/lib/tor-instances/*/keys/secret_onion_key{,_ntor}
f57a05262f65beea15ec05bbeefe404c /var/lib/tor-instances/snowflake1/keys/secret_onion_key
a16c5403d18509c79fa7b863eb66892a /var/lib/tor-instances/snowflake1/keys/secret_onion_key_ntor
```
- [x] copy HTTPS TLS keys and certificates from existing bridge
- [x] test tor bootstrap on new bridge using local broker and proxy, and /etc/hosts domain name record https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40095#note_2773365
- [x] test rebooting the server to make sure everything comes back up
- [x] start the tor@snowflake* services
- [x] make DNS for snowflake.torproject.net point to the new bridge tpo/tpa/team#40716
- [x] monitor for a day, be ready to switch DNS back if connections fail
- [x] after a week or so, shut down temporary bridge
Cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40844[Connection Settings] Update formatting of the bridge card's bridge-moji2022-04-13T00:22:21Zdonuts[Connection Settings] Update formatting of the bridge card's bridge-mojiI've been mulling over the bridge-moji and I'm starting to think it's probably too abstract as a concept, and runs the risk of causing more confusion than it alleviates. However we could still push it into Nightly & Alpha for feedback wi...I've been mulling over the bridge-moji and I'm starting to think it's probably too abstract as a concept, and runs the risk of causing more confusion than it alleviates. However we could still push it into Nightly & Alpha for feedback with some light design amends:
![connection-settings-bridge-configured_2x](/uploads/8b1b14613ddd5685394021aa696dd66b/connection-settings-bridge-configured_2x.png)
Changes include:
- Each emoji square is 36px with 4px rounded corners and a 4px margin between each
- The emoji themselves are 20px
- the "What's this?" link can be hidden/ignored until the tb-manual is updated.
I've started a new page in Figma for these changes here: [Figma link](https://www.figma.com/file/Vsh1aPOZGneDX4Zp27mjsK/torconnect?node-id=1667%3A11813)Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & TibetPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/network-health/team/-/issues/201Create bandwidth authority specification2023-12-11T09:56:45ZGeorg KoppenCreate bandwidth authority specificationWe have:
* https://research.torproject.org/techreports/torflow-2009-08-07.pdf
* https://gitlab.torproject.org/tpo/network-health/torflow/-/blob/main/NetworkScanners/BwAuthority/README.spec.txt
* https://gitlab.torproject.org/tpo/network...We have:
* https://research.torproject.org/techreports/torflow-2009-08-07.pdf
* https://gitlab.torproject.org/tpo/network-health/torflow/-/blob/main/NetworkScanners/BwAuthority/README.spec.txt
* https://gitlab.torproject.org/tpo/network-health/torflow/-/blob/main/NetworkScanners/BwAuthority/README.BwAuthorities
* https://gitlab.torproject.org/tpo/network-health/torflow/-/blob/main/README
* https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/bandwidth-file-spec.txt
We should create a single "bandwidth authority spec" including data from those documents and the current implementations.jugajugahttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40846HTTPS Everywhere not enabled for the default 'Private Browsing' mode2022-03-11T20:21:52Zchampionquizzerchampionquizzer@torproject.orgHTTPS Everywhere not enabled for the default 'Private Browsing' modeA couple of users on the forum have reported that HTTPS Everywhere seems not to be enabled in the private browsing mode (which is the default on Tor Browser) out of the box. https://forum.torproject.net/t/https-everywhere-does-not-work-i...A couple of users on the forum have reported that HTTPS Everywhere seems not to be enabled in the private browsing mode (which is the default on Tor Browser) out of the box. https://forum.torproject.net/t/https-everywhere-does-not-work-in-privacy-mode-from-11-0-3-to-11-0-6/2392
(Note: The 'incognito' icon next to https-e is missing and in Firefox one needs to explicitly tell extensions to run in the private/incognito mode and this just might be a confusion because of that)
Thanks!
![https-e-private-mode](https://aws1.discourse-cdn.com/standard21/uploads/torproject1/original/1X/665a6a7ff4c0e358aeaf4547ffa0e2b6abfa280c.png)https://gitlab.torproject.org/tpo/network-health/team/-/issues/202Set up monitoring of network health Tor nodes2022-10-26T19:46:34ZGeorg KoppenSet up monitoring of network health Tor nodesWe should set up some monitoring of our network health nodes using probably some Grafana/Prometheus/node_exporter combination. We could use for our exit an [unbound exporter](https://github.com/letsencrypt/unbound_exporter) as well which...We should set up some monitoring of our network health nodes using probably some Grafana/Prometheus/node_exporter combination. We could use for our exit an [unbound exporter](https://github.com/letsencrypt/unbound_exporter) as well which could help with issues like tpo/network-health/analysis#30.Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive placesDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/applications/android-components/-/issues/40076Rebase android-components patches to 99.02022-05-17T12:39:56ZaguestuserRebase android-components patches to 99.0Rebase android-components patches from [android-components-96.0.15-11.5-1](http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/applications/android-components/-/tree/android-components-96.0.15-11.5-1) to [android-co...Rebase android-components patches from [android-components-96.0.15-11.5-1](http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/applications/android-components/-/tree/android-components-96.0.15-11.5-1) to [android-components-99.0.3-11.5-1](http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/applications/android-components/-/tree/android-components-99.0.3-11.5-1)Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40472Prepare alpha release 11.5a10 (Android)2022-05-16T17:39:11ZrichardPrepare alpha release 11.5a10 (Android)<details>
<summary>Explanation of variables</summary>
- `$(TOR_LAUNCHER_VERSION)` : version of `tor-launcher`, used in tags
- example : `0.2.33`
- `$(ESR_VERSION)` : the Mozilla defined ESR version, used in various places for buil...<details>
<summary>Explanation of variables</summary>
- `$(TOR_LAUNCHER_VERSION)` : version of `tor-launcher`, used in tags
- example : `0.2.33`
- `$(ESR_VERSION)` : the Mozilla defined ESR version, used in various places for building tor-browser tags, labels, etc
- example : `91.6.0`
- `$(ESR_TAG)` : the Mozilla defined hg (Mercurial) tag associated with `$(ESR_VERSION)`
- exmaple : `FIREFOX_91_7_0esr_BUILD2`
- `$(TOR_BROWSER_MAJOR)` : the Tor Browser major version
- example : `11`
- `$(TOR_BROWSER_MINOR)` : the Tor Browser minor version
- example : either `0` or `5`; Alpha's is always (Stable + 5) % 10
- `$(FIREFOX_BUILD_N)` : the firefox build revision within a given `tor-browser` branch; this is separate from the `$(TOR_BROWSER_BUILD_N) ` value
- example : `build1`
- `$(TOR_BROWSER_BUILD_N)` : the tor-browser build revision for a given Tor Browser release; used in tagging git commits
- example : `build2`
- *NOTE* : `$(FIREFOX_BUILD_N)` and `$(TOR_BROWSER_BUILD_N)` typically are the same, but it is possible for them to diverge. For example :
- if we have multiple Tor Browser releases on a given ESR branch the two will become out of sync as the `$(FIREFOX_BUILD_N)` value will increase, while the `$(TOR_BROWSER_BUILD_N)` value may stay at `build1` (but the `$(TOR_BROWSER_VERSION)` will increase)
- if we have build failures unrelated to `tor-browser`, the `$(TOR_BROWSER_BUILD_N)` value will increase while the `$(FIREFOX_BUILD_N)` will stay the same.
- `$(TOR_BROWSER_VERSION)` : the published Tor Browser version
- example : `11.5a6`, `11.0.7`
</details>
### **torbutton** ***(Desktop Only, Optional)***
- [ ] Update translations :
- [ ] `./import-translations.sh`
- [ ] Commit with message `Translation updates`
- [ ] *(Optional)* Backport to maintenance branch if present
- [ ] fixup! `tor-browser`'s `Bug 10760 : Integrate TorButton to TorBrowser core` issue to point to updated `torbutton` commit
### **tor-launcher** ***(Desktop Only, Optional)***
- [ ] Update `install.rdf` file with new version
- [ ] Sign/Tag commit :
- Tag : `$(TOR_LAUNCHER_VERSION)`
- Message `Tagging $(TOR_LAUNCHER_VERSION)`
- [ ] Push `master` and tag to origin
### **geckoview** ***(Android Only)***
_TODO_
### tba-translation ***(Android Only, Optional)***
_TODO_
### tor-browser
- [ ] ***(Optional)*** Rebase to `$(ESR_VERSION)`
- [ ] Find the Firefox hg tag here : https://hg.mozilla.org/releases/mozilla-esr91/tags
- [ ] `$(ESR_TAG)` : `INSERT_TAG_HERE`
- [ ] Identify the hg patch associated with above hg tag, and find the equivalent `gecko-dev` git commit (search by commit message)
- [ ] `gecko-dev` commit : `INSERT_COMMIT_HASH_HERE`
- [ ] Create new `tor-browser` branch with the discovered `gecko-dev` commit as `HEAD` named `tor-browser-$(ESR_VERSION)esr-$(TOR_BROWSER_MAJOR).$(TOR-BROWSER_MINOR)-1`
- [ ] Sign/Tag commit :
- Tag : `$(ESR_TAG)`
- Message : `Mercurial $(ESR_TAG) tag`
- [ ] Push new branch and tag to origin
- [ ] Rebase `tor-browser` patches
- [ ] Open MR for the rebase
- [ ] ***(Optional)*** Backport any required patches
- [ ] Sign/Tag commit :
- Tag : `tor-browser-$(ESR_VERSION)esr-$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-1-$(FIREFOX_BUILD_N)`
- Message : `Tagging $(FIREFOX_BUILD_N) for $(ESR_VERSION)esr-based (alpha|stable)`
- [ ] Push tag to origin
### tor-browser-build
Tor Browser Alpha (and Nightly) are on the `master` branch, while Stable lives in the various `$(TOR_BROWSER_MAJOR).$(TOR_BROWSER_MINOR)-maint` (and possibly more specific) branches
- [ ] Update `rbm.conf`
- [ ] `var/torbrowser_version` : update to next version
- [ ] `var/torbrowser_build` : update to `$(TOR_BROWSER_BUILD_N)`
- [ ] `var/torbrowser_incremental_from` : update to previous version
- [ ] **IMPORTANT** Really actually make sure this is the previous Desktop/Android version or else the `make incrementals-*` step will fail
- [ ] Update `projects/firefox/config`
- [ ] `git_hash` : update the $(FIREFOX_BUILD_N) section to match `tor-browser` tag
- [ ] ***(Optional)*** `var/firefox_platform_version` : update to latest $(ESR_VERSION) if rebased
- [ ] Check for NoScript updates here : https://addons.mozilla.org/en-US/firefox/addon/noscript
- [ ] ***(Optional)*** If version available, update `noscript` section of `input_files` in `projects/tor-browser/config`
- [ ] `URL`
- [ ] `sha256sum`
- [ ] Check for openssl updates here : https://github.com/openssl/openssl/tags
- [ ] ***(Optional)*** If new 1.X.Y series tag available, update `projects/openssl/config`
- [ ] `version` : update to next 1.X.Y release tag
- [ ] `input_files/sha256sum` : update to sha256 sum of source tarball
- [ ] Check for tor updates here : https://gitlab.torproject.org/tpo/core/tor/-/tags ; Tor Browser Alpha uses `-alpha` tagged tor, while stable uses the stable series
- [ ] ***(Optional)*** If new tor version is available, update `projects/tor/config`
- [ ] `version` : update to next release tag
- [ ] Check for go updates here : https://golang.org/dl (Tor Browser Alpha uses the latest Stable go version, while Tor Browser Stable uses the latest of the previous Stable major series version (eg: if Tor Browser Alpha is on the go1.17 series, Tor Browser Stable is on the go1.16 series)
- [ ] ***(Optional)*** If new go version is available, update `projects/go/config`
- [ ] `version` : update go version
- [ ] `input_files/sha256sum` for `go` : update sha256sum of archive (sha256 sums are displayed on the go download page)
- [ ] ***(Android Only)*** Update allowed_addons.json by running (from `tor-browser-build` root)`./tools/fetch_allowed_addons.py > projects/tor-browser/allowed_addons.json
- [ ] Update `ChangeLog.txt`
- [ ] Open MR with above changes
- [ ] Sign/Tag commit : `make signtag-(alpha|release)`
- [ ] Push tag to origin
### blog
- [ ] Duplicate previous Stable or Alpha release blog post as appropriate to new directory under `content/blog/new-release-tor-browser-$(TOR_BROWSER_VERSION)` and update with info on release :
- [ ] Update Tor Browser version numbers
- [ ] Note any ESR rebase
- [ ] Link to any Firefox security updates
- [ ] Note any updates to :
- [ ] tor
- [ ] openssl
- [ ] go
- [ ] noscript
- [ ] Convert ChangeLog.txt to markdown format used here by : `tor-browser-build/tools/changelog-format-blog-post`
- [ ] Push to origin as new branch, open 'Draft :' MR
- [ ] Remove draft from MR once signed-packages are uploaded
### website
- [ ] `databags/versions.ini` : Update the downloads versions
- `torbrowser-stable/version` : sort of a catch-all for latest stable version
- `torbrowser-stable/win32` : tor version in the expert bundle
- `torbrowser-*-stable/version` : platform-specific stable versions
- `torbrowser-*-alpha/version` : platform-specific alpha versions
- `tor-stable`,`tor-alpha` : set by tor devs, do not touch
- [ ] Push to origin as new branch, open 'Draft :' MR
- [ ] Remove draft from MR once signed-packages are uploaded
### unsigned build uploads
- [ ] Upload unsigned builds to people.torproject.org
- [ ] Email tor-qa@lists.torproject.org with links to unsigned builds
### signing
_TODO_
### signed build uploads
_TODO_Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40847Migrate from HTTPS-Everywhere to FIrefox's own HTTPS-First feature2022-03-14T09:02:21ZSeirdyMigrate from HTTPS-Everywhere to FIrefox's own HTTPS-First featureFirefox exposes the prefs `dom.security.https_first` and `dom.security.https_only`. The former attempts to default to HTTPS when no protocol is specified; the latter forces all connections to HTTPS and displays a warning if this causes a...Firefox exposes the prefs `dom.security.https_first` and `dom.security.https_only`. The former attempts to default to HTTPS when no protocol is specified; the latter forces all connections to HTTPS and displays a warning if this causes a failure. The warning looks similar to the warning for expired TLS certs, and allows users to bypass it.
Firefox also has `dom.security.https_only_mode.upgrade_onion` to allow an exception for all hidden services.
Using these facilities could eliminate the need for the HTTPS-Everywhere addon, keeping the Tor Browser's addon list smaller.https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40043Display blocklist param on relay search2022-03-31T21:14:35ZHiroDisplay blocklist param on relay searchThe anticensorship team has introduced a new param to inform when a bridge is blocked for certain countries (https://gitlab.torproject.org/tpo/network-health/metrics/collector/-/issues/40019). This needs to be added to relay search.The anticensorship team has introduced a new param to inform when a bridge is blocked for certain countries (https://gitlab.torproject.org/tpo/network-health/metrics/collector/-/issues/40019). This needs to be added to relay search.Metrics OKR Q1 - Q2 2022HiroHirohttps://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/issues/40027Update processes/ReleaseProcess following changes from tor-browser-build#404142022-04-20T09:47:46ZboklmUpdate processes/ReleaseProcess following changes from tor-browser-build#40414After the changes from tor-browser-build#40414, we should update processes/ReleaseProcess.After the changes from tor-browser-build#40414, we should update processes/ReleaseProcess.boklmboklmhttps://gitlab.torproject.org/tpo/core/arti/-/issues/403Set `If-Modified-Since` on every consensus request2022-03-16T21:32:48ZNick MathewsonSet `If-Modified-Since` on every consensus requestEven if we have no consensus at all, we won't use one that's from than a day or two in the past. Getting one of those would indicate that the cache is very stale, or that our clock is set in the future.
Therefore, perhaps we should set...Even if we have no consensus at all, we won't use one that's from than a day or two in the past. Getting one of those would indicate that the cache is very stale, or that our clock is set in the future.
Therefore, perhaps we should set our `If-Modified-Since` header no matter whether we have an older consensus or not, to defend the network against needless load created by downloading things we can't use.
Found while investigating #329. Also see #402.Arti 1.0.0: Ready for production useNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/404Remember which directory caches give us unusable consensuses.2022-03-21T19:23:34ZNick MathewsonRemember which directory caches give us unusable consensuses.If we are looking for a usable consensus and our directory has given us one that's far in the past, we should not try that same directory again right away!
Unfortunately, that seems to be what our current code will do. One option here ...If we are looking for a usable consensus and our directory has given us one that's far in the past, we should not try that same directory again right away!
Unfortunately, that seems to be what our current code will do. One option here is to kill the circuit to that directory and hope that we pick a better one at random. Another one is to be a bit more thorough about somehow marking that directory as misbehaving, perhaps in the `tor-netdir` code.
Found while investigating #329.Arti 1.0.0: Ready for production useNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/386Use less space in hashmaps to store Microdescs and RouterDescs2022-03-17T16:45:38ZNick MathewsonUse less space in hashmaps to store Microdescs and RouterDescsThe hashmaps in `NetDir` and in `MdConsensus` have values much larger than their keys: that wastes unnecessary space in comparison to an equivalent implementation in which the values are stored in Box<>es (or in a slab allocator or somet...The hashmaps in `NetDir` and in `MdConsensus` have values much larger than their keys: that wastes unnecessary space in comparison to an equivalent implementation in which the values are stored in Box<>es (or in a slab allocator or something).
(To confirm this effect for yourself, use your favorite allocation-measurement tool to see how much RAM is needed for `HashMap::<String,[u8;4096]>::with_capacity(1024)` vs `HashMap::<String,Box<[u8;4096]>::with_capacity(1024)`)Arti 1.0.0: Ready for production useNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/406Fallback identity mismatches lead to awful behavior2022-03-30T16:25:38ZNick MathewsonFallback identity mismatches lead to awful behaviorWhile testing #329, I found a case that seems to be almost fractally bad. When every fallback has an unexpected ed25519 identity, we get huuuge errors. Here is part of one:
```
2022-03-11T21:03:56.242150Z WARN tor_dirmgr::bootstrap: e...While testing #329, I found a case that seems to be almost fractally bad. When every fallback has an unexpected ed25519 identity, we get huuuge errors. Here is part of one:
```
2022-03-11T21:03:56.242150Z WARN tor_dirmgr::bootstrap: error while
downloading: DirClientError(CircMgr(RequestFailed(RetryError { doing: "find
or build a circuit", errors: [(Single(1), Channel { peer: OwnedChanTarget {
addrs: [127.0.0.1:5001], ed_identity: Ed25519Identity {
7oQU1z0DV6+pLNNOfsEJ2bAZH1oaDa3IibkE0vHWg8M }, rsa_identity: RsaIdentity {
$96228149133d75383e4ae471b6ee80c853d6fb6a } }, cause:
Proto(HandshakeProto("Peer ed25519 id not as expected")) }), (Single(2),
Channel { peer: OwnedChanTarget { addrs: [127.0.0.1:5000], ed_identity:
Ed25519Identity { PYct0gFHas1Hofua7s5Iwhb/pA2IjwOF2RcXjxnhwmc },
rsa_identity: RsaIdentity { $cac2e36f67c817c2ecb6284a5af7a8c6c119f5f7 } },
cause: Proto(HandshakeProto("Peer ed25519 id not as expected")) }),
(Single(3), Channel { peer: OwnedChanTarget { addrs: [127.0.0.1:5002],
ed_identity: Ed25519Identity { Baj8TtEMVhFUAcVq0dVVjS4PRubKb890bqOGfHAXQhk },
rsa_identity: RsaIdentity { $8218c2079fe2a2f7291f88afd95871f4608c57f5 } },
cause: Proto(HandshakeProto("Peer ed25519 id not as expected")) }),
(Single(4), Channel { peer: OwnedChanTarget { addrs: [127.0.0.1:5000],
ed_identity: Ed25519Identity { PYct0gFHas1Hofua7s5Iwhb/pA2IjwOF2RcXjxnhwmc },
rsa_identity: RsaIdentity { $cac2e36f67c817c2ecb6284a5af7a8c6c119f5f7 } },
cause: Proto(HandshakeProto("Peer ed25519 id not as expected")) }),
(Single(5), Channel { peer: OwnedChanTarget { addrs: [127.0.0.1:5002],
ed_identity: Ed25519Identity { Baj8TtEMVhFUAcVq0dVVjS4PRubKb890bqOGfHAXQhk },
rsa_identity: RsaIdentity { $8218c2079fe2a2f7291f88afd95871f4608c57f5 } },
cause: Proto(HandshakeProto("Peer ed25519 id not as expected")) }),
...
(Single(95), Channel { peer: OwnedChanTarget { addrs: [127.0.0.1:5002],
ed_identity: Ed25519Identity { Baj8TtEMVhFUAcVq0dVVjS4PRubKb890bqOGfHAXQhk },
rsa_identity: RsaIdentity { $8218c2079fe2a2f7291f88afd95871f4608c57f5 } },
cause: Proto(HandshakeProto("Peer ed25519 id not as expected")) }),
(Single(96), Channel { peer: OwnedChanTarget { addrs: [127.0.0.1:5002],
ed_identity: Ed25519Identity { Baj8TtEMVhFUAcVq0dVVjS4PRubKb890bqOGfHAXQhk },
rsa_identity: RsaIdentity { $8218c2079fe2a2f7291f88afd95871f4608c57f5 } },
cause: Proto(HandshakeProto("Peer ed25519 id not as expected")) })],
n_errors: 96 })))
```
Probably we are retrying too aggressively. It is not yet clear to me where we need to add a backoff, but we should definitely do that.
This ticket will probably get more specific as we investigate further.Arti 1.0.0: Ready for production useNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/407Possibly use decorrelated-jitter backoff for channel/circuits too?2022-03-21T19:22:46ZNick MathewsonPossibly use decorrelated-jitter backoff for channel/circuits too?There are some cases I've found in my #329 work that suggest Arti is willing to attempt channels and circuits far too aggressively. Probably, if the connection to a single relay has failed, we shouldn't retry that relay too much, too fa...There are some cases I've found in my #329 work that suggest Arti is willing to attempt channels and circuits far too aggressively. Probably, if the connection to a single relay has failed, we shouldn't retry that relay too much, too fast.
(One case to look at here is the case when every channel gives an `io::Error`. Also see #406)Arti 1.0.0: Ready for production useNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/397arti-testing needs some kind of directory-modification mechanism2022-03-31T15:43:29ZNick Mathewsonarti-testing needs some kind of directory-modification mechanismFor #329, I'm trying to simulate a bunch of failure conditions on the Tor network so that we can see how well arti tolerates them. I've found that there are a number of target failure conditions that would be easier to simulate if `DirM...For #329, I'm trying to simulate a bunch of failure conditions on the Tor network so that we can see how well arti tolerates them. I've found that there are a number of target failure conditions that would be easier to simulate if `DirMgr` had some mechanism to modify the consensus and microdescriptors in a directory before passing them on as a `NetDir`.
For example:
* _A guard that refuses all circuits_ can be simulated with a filter that corrupts the onion key for every guard, so that all the client's
* _All relays have the wrong identity_ can be simulated with a filter that changes relay identites.
* _No circuit supports desired path_ can be simulated with a filter that removes port 443 from every exit policy.
With that in mind, I'm wondering the best way to build this. Some approaches:
* I could write a new `DirProvider` implementation (see !318) from scratch, with filtering support. A lot of work, not a great idea.
* I could try to write a new `DirProvider` implementation that wraps the existing DirMgr, and posprocesses the `NetDir` before passing it on. That's a bit tricky, though, since `NetDir` is intentionally immutable, and not really designed for creating a new NetDir based on an old one.
* I could add some mechanism to `DirMgr` (probably optional and feature-gated) to install a filter on consensus objects and individual microdescs before building a netdir out of them. This is how I'm leaning, but I'm wondering what you think.
In addition to those options, I need some way to actually modify the MdConsensus or UnverifiedConsensus, and some way to modify Microdescs after they're made. Options are:
* Implement `From<FOO>` for `FOOBuilder` for these types. (There are already optional `MdConsensusBuilder` and `MicrodescBuilder` objects for testing.) This is the way I'm leaning.
* Add a set of `set_foo()` functions to the base types for these objects.
If this seems plausible, I'll go ahead with it.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/121Remote hook failed when pushing to torspec on git-rw.2022-03-14T20:08:24ZNick MathewsonRemote hook failed when pushing to torspec on git-rw.IIUC, git-rw.tpo is still canonical for the torspec repository. I just pushed a commit there, but found that it didn't go through to gitlab.
Here is what git said:
```
[1118]$ git push
Enumerating objects: 12, done.
Counting objects: ...IIUC, git-rw.tpo is still canonical for the torspec repository. I just pushed a commit there, but found that it didn't go through to gitlab.
Here is what git said:
```
[1118]$ git push
Enumerating objects: 12, done.
Counting objects: 100% (12/12), done.
Delta compression using up to 8 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 2.14 KiB | 2.14 MiB/s, done.
Total 7 (delta 5), reused 0 (delta 0), pack-reused 0
remote: via /srv/git.torproject.org/git-helpers/post-receive-diff
remote: == 00-sync-to-mirror ==
remote: == commit-mail ==
remote: WARNING: this hook (/srv/git.torproject.org/git-helpers/post-receive.d/commit-mail) is known to fail to send email
remote:
remote: The replacement is called 'multimail' and can be enabled in gitolite by changing:
remote:
remote: config hooks.mailinglist = tor-commits@lists.torproject.org
remote:
remote: to:
remote:
remote: config multimailhook.mailinglist = tor-commits@lists.torproject.org
remote:
remote: ... and remove the 'config hooks.email-enabled' block to turn off this legacy hook
remote:
remote: see https://gitlab.torproject.org/tpo/tpa/team/-/issues/40659
remote: == git-multimail ==
remote: No email recipients configured!
remote: == github-push ==
remote: To github.com:torproject/torspec
remote: 80e9d9e..3b8a143 main -> main
remote: == gitlab-push ==
remote: remote: GitLab: You are not allowed to force push code to a protected branch on this project.
remote: To dip.torproject.org:tpo/core/torspec
remote: ! [remote rejected] main -> main (pre-receive hook declined)
remote: error: failed to push some refs to 'dip.torproject.org:tpo/core/torspec'
remote: == irc-message ==
remote: == per-repo-hook ==
To git-rw.torproject.org:/torspec.git
80e9d9e7dbbc36..3b8a1436c96215 main -> main
```
(My apologies in advance if I have put this issue in the wrong place.)https://gitlab.torproject.org/tpo/network-health/metrics/collector/-/issues/40022Potentially unwanted files on colchicifolium2022-03-14T17:30:43ZJérôme Charaouilavamind@torproject.orgPotentially unwanted files on colchicifoliumAs mentioned in the discussion of tpo/tpa/team#40650, it seems there are some leftover uncompressed tarballs that we could delete and free up to 162G on the server (almost 1/4th of the total storage!).
```
# find /srv/collector.torproje...As mentioned in the discussion of tpo/tpa/team#40650, it seems there are some leftover uncompressed tarballs that we could delete and free up to 162G on the server (almost 1/4th of the total storage!).
```
# find /srv/collector.torproject.org/collector/data -name \*.tar -and -not -name webstats\* -and -not -empty | xargs du -shc
27G /srv/collector.torproject.org/collector/data/votes-2021-12.tar
20G /srv/collector.torproject.org/collector/data/votes-2020-10.tar
1.6G /srv/collector.torproject.org/collector/data/extra-infos-2022-02.tar
26G /srv/collector.torproject.org/collector/data/votes-2022-02.tar
2.6G /srv/collector.torproject.org/collector/data/server-descriptors-2022-02.tar
1.7G /srv/collector.torproject.org/collector/data/extra-infos-2021-12.tar
25G /srv/collector.torproject.org/collector/data/votes-2021-11.tar
1.8G /srv/collector.torproject.org/collector/data/consensuses-2021-12.tar
13G /srv/collector.torproject.org/collector/data/bandwidths-2020-01.tar
628M /srv/collector.torproject.org/collector/data/server-descriptors-2021-12.tar
2.7G /srv/collector.torproject.org/collector/data/server-descriptors-2022-01.tar
12G /srv/collector.torproject.org/collector/data/bandwidths-2022-02.tar
396K /srv/collector.torproject.org/collector/data/certs.tar
20G /srv/collector.torproject.org/collector/data/votes-2021-05.tar
151G total
```
```
# ls -lah /srv/collector.torproject.org/home/*.tar
-rw-r--r-- 1 collector collector 11G Dec 1 2020 2020-11.tar
```
Is it OK to delete them?https://gitlab.torproject.org/tpo/web/team/-/issues/32The future of media.tpo2022-10-26T23:23:24ZKezThe future of media.tpoIn #30 @emmapeel brought up the fact we have a media.tpo service that is undocumented and seemingly unmaintained, and unused. Until I updated the README today, the last update was in Dec. 2018. We aren't using the service right now, so i...In #30 @emmapeel brought up the fact we have a media.tpo service that is undocumented and seemingly unmaintained, and unused. Until I updated the README today, the last update was in Dec. 2018. We aren't using the service right now, so it there are several options for what we should do with it:
- Keep the service as it is, adding documentation, and possibly restoring rsync
- Start using the service more actively, with documentation and possibly restoring rsync
- Decommission the service entirely
@lavamind, @anarcat, @gaba, and I discussed this a bit in the monthly TPA sync today. We decided we shouldn't make any moves on this without talking to the comms team about it. Since lavamind and I are going to be meeting with the comms team for the S9 meeting on Thursday, we've decided to bring it up then.https://gitlab.torproject.org/tpo/core/arti/-/issues/410Refactor `UDPSocket `API2022-03-21T12:45:28ZNick MathewsonRefactor `UDPSocket `APIMR !390 introduced a new `UdpSocket` trait in `tor-rtcompat`. We should consider refactoring it a bit before we make its API semi-stable in our end-of-March release.
A couple changes I was thinking of:
* Possibly, refactor UdpSocket ...MR !390 introduced a new `UdpSocket` trait in `tor-rtcompat`. We should consider refactoring it a bit before we make its API semi-stable in our end-of-March release.
A couple changes I was thinking of:
* Possibly, refactor UdpSocket so that it it is necessarily not "connected". (`ConnectedConnectedUdpSocket` would have to be a separate API, if we someday need it.)
* Possibly, refactor `UdpSocket` to implement Stream/Sink rather than using async_trait for sending and receiving.Arti 1.0.0: Ready for production useNick MathewsonNick Mathewson