The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-28T08:44:50Zhttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/90Remove timer from connection tab2024-03-28T08:44:50ZcybertaRemove timer from connection tab~~The connection screens timer text jumps a little bit, depending on the displayed digits. In order to have a less noisy UI while tor is running, we should create a label that is able do display the timer text in monospace. The concrete ...~~The connection screens timer text jumps a little bit, depending on the displayed digits. In order to have a less noisy UI while tor is running, we should create a label that is able do display the timer text in monospace. The concrete implementation is up to the developer.~~VPN pre-alpha 06cybertacybertahttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41539Create an operations email list2024-03-28T01:14:48Zal smithCreate an operations email listThe operations team needs an email list to coordinate its work. (This will help with our grants@torproject.org email issues, as we'll be able to reduce the number of people using that alias once the operations list is established.)
**Re...The operations team needs an email list to coordinate its work. (This will help with our grants@torproject.org email issues, as we'll be able to reduce the number of people using that alias once the operations list is established.)
**Requirements**
1. Does **not** require a moderation queue
2. Allows people who are not subscribed to the list to send email to the list **without friction**
3. Is not archived (for anyone, including members of the list)
4. Is not displayed on lists.torproject.org
Is that something a list can do?
If so, we request `tor-operations@` to be created. :smile:
Note: It's possible that an operations list exits already, per this ticket from 8 years ago, but I don't think so based on my quick test. Just adding for due diligence since I noticed it: https://gitlab.torproject.org/tpo/tpa/team/-/issues/15992Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org2024-03-31https://gitlab.torproject.org/tpo/web/support/-/issues/285unify tor installation per platform2024-03-28T00:29:36Znyxnorunify tor installation per platform<!--
* Use this issue template for suggesting new docs or updates to existing docs.
-->
### Problem to solve
<!-- Include the following detail as necessary:
-->
* What feature(s) affected?
* What docs or doc section affected? Include ...<!--
* Use this issue template for suggesting new docs or updates to existing docs.
-->
### Problem to solve
<!-- Include the following detail as necessary:
-->
* What feature(s) affected?
* What docs or doc section affected? Include links or paths.
* Is there a problem with a specific document, or a feature/process that's not addressed sufficiently in docs?
* Any other ideas or requests?
There is not unified tor installation per package manager. One can find for OpenBSD on the `relay/setup/guard` and `relay/setup/bridge`, in which the instructions differ.
### Further details
<!--
* Include use cases, benefits, and/or goals for this work.
* If adding content: What audience is it intended for? (What roles and scenarios?)
-->
* https://community.torproject.org/relay/setup/guard/openbsd/
* https://community.torproject.org/relay/setup/bridge/openbsd/
### Proposal
<!-- Further specifics for how can we solve the problem. -->
My proposal is to maintain a tor/installation or any other name to instruct on ho to install tor per platform. The relay/setup guides will refer to this documentation and them they will slim down to just contain information about how to configure the wanted relay type.
### Who can address the issue
<!-- What if any special expertise is required to resolve this issue? -->
@gus if possible, create a page https://community.torproject.org/tor/pkg-manager or something like it.ebanamebanam@torproject.orgebanamebanam@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/1343tor-llcrypto 0.7.0 ed25519 apis seemingly incompatible with version 0.4.02024-03-27T22:50:43Zrichardtor-llcrypto 0.7.0 ed25519 apis seemingly incompatible with version 0.4.0**tldr;** how do I round-trip the ED25519-V3 keyblob format used in c-tor using the latest `tor-llcrypto` crate?
---
The title's not exactly accurate I suspect, but let me lay out the problem I"m having.
I'm attempting to upgrade the ...**tldr;** how do I round-trip the ED25519-V3 keyblob format used in c-tor using the latest `tor-llcrypto` crate?
---
The title's not exactly accurate I suspect, but let me lay out the problem I"m having.
I'm attempting to upgrade the `tor-llcrypto` crate in `gosling` from version 0.4.0 to 0.7.0 in preparation for implementing an `arti-client` based backend. I have various cryptographic primitives in my `tor-interface` crate needed for working with c-tor and the gosling handshake which can be found here: https://docs.rs/tor-interface/0.2.1/tor_interface/tor_crypto/index.html
---
So the problem I am currently running into is updating my `Ed25519Privateykey` type which used to simply wrap an `pk::ed25519::ExpandedSecretKey`. Of course this type is now unavailable from the underlying `ed25519_dalek` crate w/o the hazmat feature which seemss fine, I should be able to update my APIs to reflect this with little issue.
The problem I need to solve is round-tripping an ExpandedSecretKey to and from the ED25519-V3:blahblahblah... format used in c-tor for the `ADD_ONION` command.
From what I can tell, it *seems* like some of the bit-twiddling found here ( https://docs.rs/ed25519-dalek/1.0.1/src/ed25519_dalek/secret.rs.html#265 ) in older versions no longer happens or is no longer necessary somehow?
From what I can tell, the correct pipeline for me ought to now be:
- ED25519-V3 keyblob decoded to
- 64 byte array (lower 32 bytes the 'Scalar', upper 32 bytes the nonce/hash-prefix) to
- ExpandedKeyPair::from_secret_key_bytes()
and then the reverse to go the other way. The reason why I'm here is that my initial round-trip attempt has failed (existing test vectors no worky) and I've been staring at and comparing different versions of the ed25519 crates and my eyes are bleeding.
My existing code for this process can be found here: https://docs.rs/tor-interface/0.2.1/src/tor_interface/tor_crypto.rs.html#169
The main big red flag I'm seeing is that this code snippet with all the bit-twiddling on thje scalar does not seem to exist anymore anywhere I can find in the upstream ed25519 crates where I would have expected them: https://gitlab.torproject.org/tpo/core/arti/-/issues/1021#note_2936940
Namely, it seems the newer implementation just ensures the Scalar's signbit is 0 without un-setting the lowest 3 bits to 0 (though it seems Scalar::from_bits() has *always* unset the sigbit so I don't understand why it was being set there). But maybe I just need to dig deeper :shrug:
I'm sure I can get *something* working if I bash at this for long enough, but I wanted to check in and make sure I'm not missing something obvious or to see if I just need to keep the legacy crate around for the c-tor backend and drop the keyblob conversion codes for the arti-based backends.
In the end I don't know how ed25519 is meant to work beyond the user-facing hand-wavey public/private key cryptogrphay aspects of it so I could use some help here.
/cc @nickm @gabi-250richardrichardhttps://gitlab.torproject.org/tpo/team/-/issues/266Prepare DRL meeting2024-03-27T20:53:09ZGabagaba@torproject.orgPrepare DRL meetingGabagaba@torproject.orgGabagaba@torproject.org2024-03-19https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/259"Your default search engine is not respectful of your privacy"2024-03-27T20:34:29Ztwo"Your default search engine is not respectful of your privacy"1. click the mullvad icon on the top
2. click the wheel icon
3. scroll to bottom
> Your default search engine is not respectful of your privacy. We recommend you switch to a more private one.
the page in "Learn More" suggests to switch...1. click the mullvad icon on the top
2. click the wheel icon
3. scroll to bottom
> Your default search engine is not respectful of your privacy. We recommend you switch to a more private one.
the page in "Learn More" suggests to switch to duckduckgo, but i already have duckduckgo (it's default)https://gitlab.torproject.org/tpo/tpa/team/-/issues/41436TPA-RFC-61: 2024 roadmap2024-03-27T19:41:27ZanarcatTPA-RFC-61: 2024 roadmapcheck list:
- [x] review [last year's roadmap](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/roadmap/2023) (wiki-replica@38b0e30e)
- [x] find previous year's tickets, see what the process was (tpo/tpa/team#40924)
- [x] brainstorm i...check list:
- [x] review [last year's roadmap](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/roadmap/2023) (wiki-replica@38b0e30e)
- [x] find previous year's tickets, see what the process was (tpo/tpa/team#40924)
- [x] brainstorm ideas
- [x] propose / RFC ( https://gitlab.torproject.org/tpo/tpa/wiki-replica/-/blob/6c1bcc305f3ec7d02077a4b0fc3f377739d1c903/policy/tpa-rfc-61-roadmap-2024.md)
- [x] discuss in meeting / adopt
probably won't propose anything before january because we're swamped, but if time permits, maybe step 1-2 above?
/cc @gabaanarcatanarcathttps://gitlab.torproject.org/tpo/onion-services/onionspray-log-parser/-/issues/8Support for parsing Onion Service circuit IDs2024-03-27T18:41:23ZSilvio RhattoSupport for parsing Onion Service circuit IDs# Tasks
* [x] Add support for parsing Onion Service circuit IDs (tpo/onion-services/eotk-log-parser!1).
* [x] Add sample logs (examples [here](https://gitlab.torproject.org/tpo/onion-services/eotk/-/issues/7#note_2983581)).
* [x] Aggreg...# Tasks
* [x] Add support for parsing Onion Service circuit IDs (tpo/onion-services/eotk-log-parser!1).
* [x] Add sample logs (examples [here](https://gitlab.torproject.org/tpo/onion-services/eotk/-/issues/7#note_2983581)).
* [x] Aggregate page hits by site and circuit ID.
* [~] Optionally decode the circuit identifier to the actual circuit number (check `tor(1)` manpage for details). Not needed right now (as this tools is not intended to close circuits).
* [x] Release version 1.0.0 (major number bumped due to breaking changes).
# Time estimation
* Complexity: very small (0.5 day)
* Uncertainty: low (x1.1)
* [Reference](https://jacobian.org/2021/may/25/my-estimation-technique/) (adapted)Silvio RhattoSilvio Rhatto2024-03-28https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/90Firefox Webextension Not Found2024-03-27T17:56:18ZcypherpunksFirefox Webextension Not FoundThe extension has been uninstalled and the redirect from the Tor website is not working: https://addons.mozilla.org/en-US/firefox/addon/torproject-snowflake/.The extension has been uninstalled and the redirect from the Tor website is not working: https://addons.mozilla.org/en-US/firefox/addon/torproject-snowflake/.https://gitlab.torproject.org/tpo/core/onionmasq/-/issues/72Upstream the PT work2024-03-27T17:23:17ZetaUpstream the PT workThe PT stuff currently relies on horrid non-upstreamed arti hacks. This should be fixed.The PT stuff currently relies on horrid non-upstreamed arti hacks. This should be fixed.VPN pre-alpha 06https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42481Modularize SecurityLevel2024-03-27T17:19:44ZPier Angelo VendrameModularize SecurityLevelRecently, Firefox RR started turning off JSM/ES Modules compatibility (e.g., in imports).
I already converted some jsm to es modules in my rebase effort, except for Security Level.
Then yesterday I tried to build and run, and this brok...Recently, Firefox RR started turning off JSM/ES Modules compatibility (e.g., in imports).
I already converted some jsm to es modules in my rebase effort, except for Security Level.
Then yesterday I tried to build and run, and this broke the browser at runtime, so I had to convert Security Level to modules.
I think having this patch also for 13.5 is okay.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42375newwin: New Identity creates a non-rounded (taller) window, triggering letter...2024-03-27T17:15:28Zma1newwin: New Identity creates a non-rounded (taller) window, triggering letterboxingFrom [this comment](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41917#note_2985396) of @ruihildt's , I could reproduce on 13.0.8:
"Noticed this weird behavior: when you click on "New Identity", the re-spawn windo...From [this comment](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41917#note_2985396) of @ruihildt's , I could reproduce on 13.0.8:
"Noticed this weird behavior: when you click on "New Identity", the re-spawn window is using a size that is vertically a few pixels higher than the default size.
This makes the letterboxing apparent in a weird way."
<details><summary>Show screenshot</summary>
![image](/uploads/76e6be07379a5745a375d92103999c30/image.png)
</details>ma1ma1https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/277Rebase Mullvad Browser stable onto Firefox 115.9.1esr2024-03-27T16:36:14Zma1Rebase Mullvad Browser stable onto Firefox 115.9.1esr**NOTE:** All examples in this template reference the rebase from 102.7.0esr to 102.8.0esr
<details>
<summary>Explanation of Variables</summary>
- `$(ESR_VERSION)`: the Mozilla defined ESR version, used in various places for building m...**NOTE:** All examples in this template reference the rebase from 102.7.0esr to 102.8.0esr
<details>
<summary>Explanation of Variables</summary>
- `$(ESR_VERSION)`: the Mozilla defined ESR version, used in various places for building mullvad-browser tags, labels, etc
- **Example**: `102.8.0`
- `$(ESR_TAG)`: the Mozilla defined hg (Mercurial) tag associated with `$(ESR_VERSION)`
- **Example**: `FIREFOX_102_8_0esr_RELEASE`
- `$(BROWSER_MAJOR)`: the browser major version
- **Example**: `12`
- `$(BROWSER_MINOR)`: the browser minor version
- **Example**: either `0` or `5`; Alpha's is always `(Stable + 5) % 10`
- `$(BASE_BROWSER_BRANCH)`: the full name of the current `base-browser` branch
- **Example**: `base-browser-102.8.0esr-12.0-1`
- `$(BASE_BROWSER_BRANCH_PREV)`: the full name of the previous `base-browser` branch
- **Example**: `base-browser-102.7.0esr-12.0-1`
- `$(BASE_BROWSER_BRANCH_TAG)`: the `base-browser` build tag used as base commit for `mullvad-browser`
- **Example**: `base-browser-102.8.0esr-12.0-1-build1`
- `$(BASE_BROWSER_BRANCH_PREV_TAG)`: the `base-browser` build tag used as base commit for the previous `mullvad-browser`
- **Example**: `base-browser-102.7.0esr-12.0-1-build1`
- `$(MULLVAD_BROWSER_BRANCH)`: the full name of the current `mullvad-browser` branch
- **Example**: `mullvad-browser-102.8.0esr-12.0-1`
- `$(MULLVAD_BROWSER_BRANCH_PREV)`: the full name of the previous `mullvad-browser` branch
- **Example**: `mullvad-browser-102.7.0esr-12.0-1`
</details>
**NOTE:** It is assumed that we've already rebased and tagged `base-browser` stable
### **Bookkeeping**
- [x] Link this issue to the appropriate [Release Prep](https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=Release%20Prep) issue.
### Update Branch Protection Rules
- [x] In [Repository Settings](https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/settings/repository):
- [x] Remove previous stable `mullvad-browser` branch protection rules (this will prevent pushing new changes to the branches being rebased)
- [x] Create new `mullvad-browser` branch protection rule:
- **Branch**: `mullvad-browser-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1*`
- **Example**: `mullvad-browser-102.8.0esr-12.0-1*`
- **Allowed to merge**: `Maintainers`
- **Allowed to push and merge**: `Maintainers`
- **Allowed to force push**: `false`
### **Create and Push New Branch**
- [x] Create new stable `mullvad-browser` branch from this ESR's stable `base-browser` tag
- Branch name in the form: `mullvad-browser-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1`
- **Example**: `git branch mullvad-browser-102.8.0esr-12.0-1 base-browser-102.8.0esr-12.0-1-build1`
- [x] Push new `mullvad-browser` branch to `upstream`
- [x] Push `base-browser` tag to `upstream`
- [x] Push `$(ESR_TAG)` to `upstream`
### **Rebase mullvad-browser**
- [x] Checkout a new local branch for the `mullvad-browser` rebase
- **Example**: `git branch mullvad-browser-rebase upstream/mullvad-browser-102.8.0esr-12.0-1`
- [x] `mullvad-browser` rebase
- [x] Cherry-pick the previous `mullvad-browser` branch's commit range up to the last `mullvad-browser` `build1` tag
- **Example**: `git cherry-pick base-browser-102.7.0esr-12.0-1-build1..mullvad-browser-102.7.0esr-12.0-1-build1`
- [x] Rebase and autosquash these newly cherry-picked commits
- **Example**: `git rebase --autosquash --interactive upstream/mullvad-browser-102.8.0esr-12.0-1`
- [x] Cherry-pick remainder of patches after the last `mullvad-browser` `buildN` tag
- **Example**: `git cherry-pick mullvad-browser-102.7.0esr-12.0-1-build1..upstream/mullvad-browser-102.7.0esr-12.0-1`
- [x] Rebase and autosquash again, this time replacing all `fixup` and `squash` commands with `pick`. The goal here is to have all of the `fixup` and `squash` commits beside the commit which they modify, but kept un-squashed for easy debugging/bisecting.
- **Example**: `git rebase --autosquash --interactive upstream/mullvad-browser-102.8.0esr-12.0-1`
- [x] Compare patch sets to ensure nothing _weird_ happened during conflict resolution:
- [x] diff of diffs:
- Do the diff between `current_patchset.diff` and `rebased_patchset.diff` with your preferred difftool and look at differences on lines that starts with + or -
- `git diff $(BASE_BROWSER_BRANCH_PREV_TAG)..$(MULLVAD_BROWSER_BRANCH_PREV) > current_patchset.diff`
- `git diff $(BASE_BROWSER_BRANCH_TAG)..HEAD > rebased_patchset.diff`
- diff `current_patchset.diff` and `rebased_patchset.diff`
- If everything went correctly, the only lines which should differ should be the lines starting with `index abc123...def456` (unless the previous `base-browser` branch includes changes not included in the previous `mullvad-browser` branch)
- [ ] rangediff: `git range-diff $(BASE_BROWSER_BRANCH_PREV_TAG)..$(MULLVAD_BROWSER_BRANCH_PREV) $(BASE_BROWSER_BRANCH_TAG)..HEAD`
- **Example**: `git range-diff base-browser-102.7.0esr-12.0-1-build1..upstream/mullvad-browser-102.7.0esr-12.5-1 base-browser-102.8.0esr-12.5-1-build1..HEAD`
- [x] Open MR for the `mullvad-browser` rebase
- [x] Merge
### **Sign and Tag**
- [x] Sign/Tag `HEAD` of the merged `mullvad-browser` branch:
- [ ] **Tag**: `mullvad-browser-$(ESR_VERSION)esr-$(BROWSER_MAJOR).$(BROWSER_MINOR)-1-build1`
* **Message**: `Tagging build1 for $(ESR_VERSION)esr-based stable`
- [ ] Push tag to `upstream`ma1ma1https://gitlab.torproject.org/tpo/community/relays/-/issues/91Snowflake not available in Firefox Addon site2024-03-27T16:24:18ZcypherpunksSnowflake not available in Firefox Addon siteSnowflake is not on the addon site from firefox anymore.
https://addons.mozilla.org/en-US/firefox/addon/torproject-snowflake/
the link from the guide https://snowflake.torproject.org/
is directing to the addon site from firefox, it wou...Snowflake is not on the addon site from firefox anymore.
https://addons.mozilla.org/en-US/firefox/addon/torproject-snowflake/
the link from the guide https://snowflake.torproject.org/
is directing to the addon site from firefox, it would be nice if you could download the addon directly from the tor projecthttps://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues/28Add option to get notification for bridge events (like bridge is down)2024-03-27T16:01:03ZGeorg KoppenAdd option to get notification for bridge events (like bridge is down)At the last weekend's relay operator meetup we got asked to consider bridges as well to be eligible for inclusion in our weather monitoring system. That's in principle doable, however, using Onionoo for that might not be the right choice...At the last weekend's relay operator meetup we got asked to consider bridges as well to be eligible for inclusion in our weather monitoring system. That's in principle doable, however, using Onionoo for that might not be the right choice as e.g. some bridges have firewalled their `ORPort` to avoid censorship efforts. Thus, Onionoo might falsely report those bridges are down while they are actually fine and the bridge authority, `Serge`, can't just connect to them.
We could use [`bridgestrap`](https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap) [output](https://collector.torproject.org/recent/bridgestrap/) instead to get a clearer picture. Not sure how much of time-granularity we could offer in that case. Probably not a notify-me-after-my-bridge-is-down-for-an-hour.
Alternatively, if that's not sufficient we could think about running our own bridgestrap client for the bridges to monitor.
/cc @meskio from the a-c teamhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/13134Figure out access rights to new dists.torproject.org2024-03-27T15:26:46ZAndrew LewmanFigure out access rights to new dists.torproject.orgFigure out access rights to new dists.torproject.org so people can upload their precious binaries of love.Figure out access rights to new dists.torproject.org so people can upload their precious binaries of love.WebsiteV3https://gitlab.torproject.org/tpo/tpa/team/-/issues/41517retire majus2024-03-27T15:22:59Zanarcatretire majusin #40692, we upgraded majus to Debian bookworm, yay!
but unfortunately, the transifex-client package has been removed from debian, so it won't be covered by security support and has not been upgraded to the latest release.
so we need...in #40692, we upgraded majus to Debian bookworm, yay!
but unfortunately, the transifex-client package has been removed from debian, so it won't be covered by security support and has not been upgraded to the latest release.
so we need to find a solution for this. i favor completely retiring the host and @emmapeel seemed opened to the idea in https://gitlab.torproject.org/tpo/tpa/team/-/issues/41252#note_2993038
so what's the next step here, @emmapeel you were saying there were some leftovers to garbage-collect?
checklist:
1. [x] announcement
2. [x] nagios
3. [x] retire the host in fabric
4. [x] remove from LDAP with `ldapvi`
5. [x] power-grep
6. [x] remove from tor-passwords
7. [x] remove from DNSwl
8. [x] remove from docs
9. [x] remove from racks
10. [x] remove from reverse DNSold service retirement 2023anarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40577Migrate {anonticket, gitlab}.onionize.space to TPO infrastructure2024-03-27T14:10:44ZAlexander Færøyahf@torproject.orgMigrate {anonticket, gitlab}.onionize.space to TPO infrastructureBefore I went AFK during most of last year, we had some discussions about moving the anonticket and Gitlab sign-up portal moved to TPO infrastructure *eventually*. We didn't deem it urgent as it was just to test things, but now the syste...Before I went AFK during most of last year, we had some discussions about moving the anonticket and Gitlab sign-up portal moved to TPO infrastructure *eventually*. We didn't deem it urgent as it was just to test things, but now the system have been running "fine" for something around 9 months, and I can happily say the administration burden of running this have been so minimal that I can't remember having done anything since I set it up.
The two application are for simplification reasons currently running with sqlite as its database as the number of data records are usually trimmed in there by the moderators, but I think when we move it over we should switch to postgresql for backup reasons and generally maintainability.
The applications are written in Python 3 using the Django framework. I have not tested them with the Debian packages of Django, but it is instead using "what Pip brought me of the day".
This is by no means urgent, but let's keep it on our radar.
What would be the first steps to get this going?
(I don't know which label this belongs to, so leaving it entirely untriaged here)Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42466Drop the "Onion Logo" from trademark statement2024-03-27T11:07:18ZhenryDrop the "Onion Logo" from trademark statementCurrently, in the "About Tor Browser" dialog, we have the statement:
> `“Tor” and “The Onion Logo” are registered trademarks of The Tor Project, Inc.`
We don't actually use the trademarked onion logo in our builds any more. See the tra...Currently, in the "About Tor Browser" dialog, we have the statement:
> `“Tor” and “The Onion Logo” are registered trademarks of The Tor Project, Inc.`
We don't actually use the trademarked onion logo in our builds any more. See the trademark here: https://tsdr.uspto.gov/#caseNumber=77172363&caseSearchType=US_APPLICATION&caseType=DEFAULT&searchType=statusSearch
I've searched through our assets and I can't find this old logo, which I think was cleared out with the new designs from UX. @donuts can you please confirm we won't use the logo any more?
So I think we should change it to:
> `“Tor” is a registered trademark of The Tor Project, Inc.henryhenryhttps://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/40023A bridge without Running flag but with a working obfs4 port shouldn't be list...2024-03-27T09:38:10ZRoger DingledineA bridge without Running flag but with a working obfs4 port shouldn't be listed as downWe have a growing set of bridges that firewall their ORPort because clients connect on their obfs4 port. The goal is to slow enumeration attacks by not exposing an ORPort. These started off as the default bridges shipped in Tor Browser, ...We have a growing set of bridges that firewall their ORPort because clients connect on their obfs4 port. The goal is to slow enumeration attacks by not exposing an ORPort. These started off as the default bridges shipped in Tor Browser, but now that we're encouraging more bridge operators to do it, the issue is becoming broader, and I'm seeing a growing number of bridge operators get confused.
But because the bridge authority only knows how to test the ORPort, it doesn't give the bridges the Running flag. The bridgestrap tool measures obfs4 reachability, and outputs a file that bridgedb/rdsys use to decide whether the bridge is actually worth giving out.
But in the mean time, on the relay-search page, the bridge gets a red circle with a tooltip saying "This bridge is offline". See e.g. GeorgetownPontem, https://metrics.torproject.org/rs.html#details/7C95AED7256E1D10D134942532CC72AD73AC1BD8
We should pull in the data set from bridgestrap, like bridgedb/rdsys does, and if the bridge has an obfs4 port, and bridgestrap gives it a thumbs up, then we should give it a green circle on relay-search too.