The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-25T19:09:50Zhttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/278Create asset(s) for the Mullvad Browser installer2024-03-25T19:09:50ZPier Angelo VendrameCreate asset(s) for the Mullvad Browser installerCurrently, we use NSIS's default images for the last page of the installers, however we could customize it:
<details><summary>Screenshots</summary>
Our page:
![Screenshot_from_2024-02-06_17-22-53](/uploads/cbbb28d1d4fb72f83165b82ba92...Currently, we use NSIS's default images for the last page of the installers, however we could customize it:
<details><summary>Screenshots</summary>
Our page:
![Screenshot_from_2024-02-06_17-22-53](/uploads/cbbb28d1d4fb72f83165b82ba920bc04/Screenshot_from_2024-02-06_17-22-53.png)
Firefox:
![Screenshot_2024-01-17_054914](/uploads/513037b0c2df23114fb5008bf431fa0f/Screenshot_2024-01-17_054914.png)
</details>
Firefox uses the same asset is used also for the first page.
We don't use that page, but in case we can also re-use the same asset, or create a new issue if needed.
We customize the icon for the channel, so if easy enough we could have multiple version of that asset, too (but I'm not sure of the requirement on the sponsor side).
/cc @donuts @nicobnicobnicobhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40354Extract reusable parts to a shared library2024-03-26T10:41:06Zmeskiomeskio@torproject.orgExtract reusable parts to a shared library[RoundCounter](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/broker/prometheus.go?ref_type=heads) is a useful wrapper on top of prometheus to round metrics to 8. We want to use it in other p...[RoundCounter](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/broker/prometheus.go?ref_type=heads) is a useful wrapper on top of prometheus to round metrics to 8. We want to use it in other projects like rdsys.
Another useful piece for other projects is [safelog](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/tree/main/common/safelog?ref_type=heads) that is already being imported by bridgestrap and conjure. Maybe we want to be able to import it without snowflake.
We could bundle both into a single library as this might make it easier to add other pieces in the future and each extra library makes it harder to package software to distros.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42478Update text in the "remove all bridges" warning dialog2024-03-25T16:15:15ZhenryUpdate text in the "remove all bridges" warning dialogTaken from https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/890#note_2985074.
Currently, whenever the user selects "..." > "Remove all bridges", they get a warning dialog, with the text:
> Remove all bridges?...Taken from https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/890#note_2985074.
Currently, whenever the user selects "..." > "Remove all bridges", they get a warning dialog, with the text:
> Remove all bridges?
>
> If these bridges were received from torproject.org or added manually, this action cannot be undone
This is shown whether the user is removing *any* of the following:
1. Bridges they added themselves.
2. Bridges added through the Tor Browser captcha request.
3. Built-in bridges.
4. Bridge pass (Lox) bridges.
Do we want to update this text, or customize it for the individual cases? For example, if you are removing built-in bridges the warning is less relevant.
The other consideration is that "added manually" is the old wording, that we replaced with "added by you" in the UI.
/cc @donutshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40353Rename Container Image Tag for containers built from main branch to nightly2024-03-25T15:21:37ZshelikhooRename Container Image Tag for containers built from main branch to nightlyThe current container image tag for container images built from main branch is latest, which is typically expected to the most recent stable release, instead of the unstable main branch build result. The tag should be renamed to `nightly...The current container image tag for container images built from main branch is latest, which is typically expected to the most recent stable release, instead of the unstable main branch build result. The tag should be renamed to `nightly` as [discussed](https://lists.torproject.org/pipermail/tor-project/2024-March/003787.html) in the during the weekly meeting.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42477Decide what to do with the "Choose a bridge for me" button in Tor Connection ...2024-03-25T15:53:46ZhenryDecide what to do with the "Choose a bridge for me" button in Tor Connection settings.Spin off from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036#note_2974796.
When "about:torconnect" has failed to perform a regular Bootstrap we show in "about:preferences#connection" the location selector and ...Spin off from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42036#note_2974796.
When "about:torconnect" has failed to perform a regular Bootstrap we show in "about:preferences#connection" the location selector and a "Choose a Bridge for me..." button to open "about:preferences" and trigger "Auto-Bootstrapping". Once connected to tor, it won't show again.
![Screenshot of location selector and trigger button shown in the bridge settings](/uploads/7f82218d21c518f003e24931d9775ddf/choose-bridge.png)
We should decide on whether we want to drop this, or replace it with something else.
/cc @donuts do we want to do anything for 13.5?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42476Only allow Lox (invites) in alpha and nightly builds2024-03-25T14:14:39ZhenryOnly allow Lox (invites) in alpha and nightly buildsWe should add some kind of guard to prevent Lox invites for the stable 13.5 release.
I imagine we could use a preference. In terms of the UI, I think we only need to change [one line](https://gitlab.torproject.org/tpo/applications/tor-b...We should add some kind of guard to prevent Lox invites for the stable 13.5 release.
I imagine we could use a preference. In terms of the UI, I think we only need to change [one line](https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/b7fc915f3ed100830bd8574a62f9cd653c1ec250/browser/components/torpreferences/content/provideBridgeDialog.js#L79-80) to disallow Lox invites in the "Add new bridges" dialog.
Do we also want some extra safety checks in other places to prevent the Lox module from doing anything?
/cc @richard @pierovhttps://gitlab.torproject.org/tpo/network-health/metrics/tor_fusion/-/issues/6Use UPDATE instead of INSERT?2024-03-25T09:08:39ZjugaUse UPDATE instead of INSERT?Reviewing !5 with a local database, i realized that to insert the same data with the changes, i've to truncate the tables first,because the primary keys already existed. I wonder whether using update instead of insert, would easy new dep...Reviewing !5 with a local database, i realized that to insert the same data with the changes, i've to truncate the tables first,because the primary keys already existed. I wonder whether using update instead of insert, would easy new deployments, since it'd modify the existing rows for the same primary keys. However i've not checked how worst would performance be nor how it could break if we change primary keys.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/40Can't connect to phantoms acquired from CDN77 domain front2024-03-24T18:39:43ZCecylia BocovichCan't connect to phantoms acquired from CDN77 domain frontConjure works just fine with the fastly front and by contacting the registration server directly, but any connections through CDN77 fail. If I recall correctly, Conjure does a check to see whether the originating IP to the phantom matche...Conjure works just fine with the fastly front and by contacting the registration server directly, but any connections through CDN77 fail. If I recall correctly, Conjure does a check to see whether the originating IP to the phantom matches the IP address of the client registration. So either CDN77 is doing something unexpected with the `X-Forwarded-For` header, or the station needs to be told to check for it from CDN77 addresses.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42475about:tor lacks branding2024-03-25T03:51:14ZThorinabout:tor lacks branding![about-tor](/uploads/1aa737b9f7b5de00b0d3540cf5689521/about-tor.png)
Roger brought up that there's nothing to "say" Tor Browser (excluding when you have the byline that Tor Browser updated)
> - i am trying to show a screenshot of tor ...![about-tor](/uploads/1aa737b9f7b5de00b0d3540cf5689521/about-tor.png)
Roger brought up that there's nothing to "say" Tor Browser (excluding when you have the byline that Tor Browser updated)
> - i am trying to show a screenshot of tor browser and i find myself needed to write "Tor Browser" at the top or nobody will know what it is a screenshot of
> - it looks mainly like a duck duck go browser because that's what gets the real estate
My initial suggestion is add a smaller sized `Tor Browser` byline directly beneath `Explore. Privately`, but inline to the icon, and obviously adjust their vertical alignment
cc: @donuts @armahttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41110Avoid Fontconfig warning about "ambiguous path"2024-03-27T08:15:02ZRusty BirdAvoid Fontconfig warning about "ambiguous path" $ ./start-tor-browser --verbose
Fontconfig warning: "/home/user/tor-browser/Browser/fontconfig/fonts.conf", line 42: Use of ambiguous path in <dir> element. please add prefix="cwd" if current behavior is desired.
I'll open a mer... $ ./start-tor-browser --verbose
Fontconfig warning: "/home/user/tor-browser/Browser/fontconfig/fonts.conf", line 42: Use of ambiguous path in <dir> element. please add prefix="cwd" if current behavior is desired.
I'll open a merge request that adds `prefix="cwd"`.Rusty BirdRusty Birdhttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/149Bridge bot/manual flow2024-03-22T14:48:16ZkwadronautBridge bot/manual flowSee #140 and https://www.figma.com/file/sjNWeIOpb0BckjmxApXd5m/Tor-VPN-for-Android?type=design&node-id=4515%3A4799&mode=design&t=y0K62dcCkhHHjU9x-1 Some comments/ideas here: https://www.figma.com/file/sjNWeIOpb0BckjmxApXd5m?type=design&n...See #140 and https://www.figma.com/file/sjNWeIOpb0BckjmxApXd5m/Tor-VPN-for-Android?type=design&node-id=4515%3A4799&mode=design&t=y0K62dcCkhHHjU9x-1 Some comments/ideas here: https://www.figma.com/file/sjNWeIOpb0BckjmxApXd5m?type=design&node-id=4515-4646&mode=design#741278163
There's also #119
Current situation is that users choose to use a built-in bridge, either snowflake or obfs4. When requesting new bridges, users can not choose which bridge type to use, they get both. They could remove the lines that contain the other type, quite hackish. I find this counter-intuitive, there are other ways approach this. The bridge-bot-expanded touches this with the ``what bridge should I use``.
Idea:
On the bridge screen, instead of `choose a built-in bridge` `choose a bridge type`. Below you can **not** click on the title `add a new bridge` (I tried to use that a dozen times, instead of tapping the white text under bridge address). Changing the title to `Pick your bridge type` with a default of `built-in` selected is a possibility, but @donuts probably has better ideas, see #119
The receive-bridges has as a main button ``I need new bridges`` and as a smaller option Start again. I would swap both, the usual way is that people go ahead and try these new bridges.kwadronautkwadronauthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40352Use unreliable and unordered WebRTC data channels2024-03-21T20:15:25ZDavid Fifielddcf@torproject.orgUse unreliable and unordered WebRTC data channels@shelikhoo:
Actually here are some observation from me related to https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40243:
Snowflake is currently using network resource in a so suboptimal way I ...@shelikhoo:
Actually here are some observation from me related to https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40243:
Snowflake is currently using network resource in a so suboptimal way I think it would make sense to also consider make protocol level change on how kcp is interacting with webrtc before considering to add forward error correction. This would be in the form of enabling unreliable mode of webrtc and make necessary change to get it to work.
Right now, kcp packets are sent in webrtc data channel in a reliable way that deliver all packets in order and retransmit any lost message repeatedly. However, kcp also retransmit its packet itself, which as a result, queue all those retransmitted packets somewhere, like in webrtc's buffer.
This means lost packets are required to be retransmitted more than once in different protocol, and retransmit & timeout get compounded. More retransmit result in more lost packets and more retransmission, which eventually lead to [connection melt down](https://openvpn.net/faq/what-is-tcp-meltdown/) <- please read.
back pressure like the one introduced in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/144 only move the problem, and block kcp's send in unexpected way, as kcp don't expect send to block as it is usually over udp.
See also: https://lists.torproject.org/pipermail/anti-censorship-team/2023-March/000286.html
(@dcf split this issue off from #40251 to separate the analysis of speed in China from the proposed remedy.)shelikhooshelikhoohttps://gitlab.torproject.org/tpo/web/community/-/issues/344[Onion Services] Replace mailing list tor-onions link to the Tor Forum Onion ...2024-03-27T22:03:10ZGus[Onion Services] Replace mailing list tor-onions link to the Tor Forum Onion Services categoryHere: https://community.torproject.org/onion-services/
_"Are you interested in learning more about onion services? Join our tor-onions mailing list to speak with other onion service operators. "_
We should consider changing the mailing...Here: https://community.torproject.org/onion-services/
_"Are you interested in learning more about onion services? Join our tor-onions mailing list to speak with other onion service operators. "_
We should consider changing the mailing list link to the Tor Forum: https://forum.torproject.org/c/support/onion-services/16.
(cc @rhatto)Silvio RhattoSilvio Rhatto2024-06-17https://gitlab.torproject.org/tpo/core/arti/-/issues/1342Use d-a for our ad-hoc BinaryHeap entry implementations2024-03-25T10:30:18Zgabi-250Use d-a for our ad-hoc BinaryHeap entry implementationsWe have a lot of types meant for use in a [std BinaryHeap](https://doc.rust-lang.org/std/collections/struct.BinaryHeap.html) to make it behave as a min-heap instead of max-heap. These types all have formulaic `Ord`/`ParialOrd`/`Eq`/`Part...We have a lot of types meant for use in a [std BinaryHeap](https://doc.rust-lang.org/std/collections/struct.BinaryHeap.html) to make it behave as a min-heap instead of max-heap. These types all have formulaic `Ord`/`ParialOrd`/`Eq`/`PartialEq` impls
```rust
impl Ord for ReuploadTimer {
fn cmp(&self, other: &Self) -> Ordering {
// Reversed, because we want the earlier
// `ReuploadTimer` to be "greater".
self.when.cmp(&other.when).reverse()
}
}
impl PartialOrd for ReuploadTimer {
fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
Some(self.cmp(other))
}
}
impl PartialEq for ReuploadTimer {
fn eq(&self, other: &Self) -> bool {
self.when == other.when
}
}
impl Eq for ReuploadTimer {}
```
```rust
impl<TT: Ord, RD> Ord for RefetchEntry<TT, RD> {
fn cmp(&self, other: &Self) -> Ordering {
self.when.cmp(&other.when).reverse()
// We don't care about the ordering of BridgeConfig or retry_delay.
// Different BridgeConfig with the same fetch time will be fetched in "some order".
}
}
impl<TT: Ord, RD> PartialOrd for RefetchEntry<TT, RD> {
fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
Some(self.cmp(other))
}
}
impl<TT: Ord, RD> PartialEq for RefetchEntry<TT, RD> {
fn eq(&self, other: &Self) -> bool {
self.cmp(other) == Ordering::Equal
}
}
impl<TT: Ord, RD> Eq for RefetchEntry<TT, RD> {}
```
```rust
impl PartialEq for SleepEntry {
fn eq(&self, other: &Self) -> bool {
self.when == other.when
}
}
impl Eq for SleepEntry {}
impl PartialOrd for SleepEntry {
fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
Some(self.cmp(other))
}
}
impl Ord for SleepEntry {
fn cmp(&self, other: &Self) -> Ordering {
self.when.cmp(&other.when).reverse()
}
}
```
```rust
impl<TT: Ord, RD> Ord for RefetchEntry<TT, RD> {
fn cmp(&self, other: &Self) -> Ordering {
self.when.cmp(&other.when).reverse()
// We don't care about the ordering of BridgeConfig or retry_delay.
// Different BridgeConfig with the same fetch time will be fetched in "some order".
}
}
impl<TT: Ord, RD> PartialOrd for RefetchEntry<TT, RD> {
fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
Some(self.cmp(other))
}
}
impl<TT: Ord, RD> PartialEq for RefetchEntry<TT, RD> {
fn eq(&self, other: &Self) -> bool {
self.cmp(other) == Ordering::Equal
}
}
impl<TT: Ord, RD> Eq for RefetchEntry<TT, RD> {}
```
And I'm about to add another such type!
ISTM these could all be auto-generated (probably with d-a).gabi-250gabi-250https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/36Webtunnel does not support proxy in Tor Browser2024-03-25T11:15:40ZValdikSSWebtunnel does not support proxy in Tor BrowserTor Browser 13.0.12.
If configured with upstream Socks5 proxy, Webtunnel bridge does not send any requests via proxy (and at all).Tor Browser 13.0.12.
If configured with upstream Socks5 proxy, Webtunnel bridge does not send any requests via proxy (and at all).shelikhooshelikhoohttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/148Switch to Material Design 32024-03-21T17:21:08ZcybertaSwitch to Material Design 3The latest designs in Figma are based on Material Design 3.
However the actual theme in our App uses Material Design 2.
This ticket is meant to track updating to M3, which will cause a couple of visual bugs that need to be fixed.
- [...The latest designs in Figma are based on Material Design 3.
However the actual theme in our App uses Material Design 2.
This ticket is meant to track updating to M3, which will cause a couple of visual bugs that need to be fixed.
- [ ] update color scheme using the extended M3 color naming
- [ ] update the Base theme
- [ ] update to com.google.android.material:material:1.12.0 as soon as it becomes stable (that includes some design changes of the progress indicatorVPN pre-alpha 07https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40111metrics.tpo not producing 'userstats-bridge-country' and 'userstats-bridge-co...2024-03-27T09:41:41ZHirometrics.tpo not producing 'userstats-bridge-country' and 'userstats-bridge-combined' graphs since Mar 15@gus noticed we are not producing graphs for 'userstats-bridge-country' and 'userstats-bridge-combined' since Mar 15th. The data is in the db, but the csv served by R are not being written.@gus noticed we are not producing graphs for 'userstats-bridge-country' and 'userstats-bridge-combined' since Mar 15th. The data is in the db, but the csv served by R are not being written.HiroHirohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/35"Managed proxy at '/usr/local/sbin/webtunnel-server' failed the configuration...2024-03-25T11:21:06ZGus"Managed proxy at '/usr/local/sbin/webtunnel-server' failed the configuration protocol and will be destroyed."A bridge operator reported that their WebTunnel bridge stopped to work and found this message in their logs:"Managed proxy at '/usr/local/sbin/webtunnel-server' failed the configuration protocol and will be destroyed".
After restarting ...A bridge operator reported that their WebTunnel bridge stopped to work and found this message in their logs:"Managed proxy at '/usr/local/sbin/webtunnel-server' failed the configuration protocol and will be destroyed".
After restarting Tor, the bridge went back, but today it stopped again. Any ideas on why the webtunnel-server has crashed? Which logs they should provide for further analysis?shelikhooshelikhoohttps://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/85Fix tests for server status2024-03-26T09:57:52ZHiroFix tests for server statusThere are a few fields in the server status class that are not being tested.
Leaving here a few comments for reference:
https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/merge_requests/51#note_2998894
https:/...There are a few fields in the server status class that are not being tested.
Leaving here a few comments for reference:
https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/merge_requests/51#note_2998894
https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/merge_requests/51#note_2998067https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42471Add merge requst CI for checking our fixups2024-03-25T13:39:42ZhenryAdd merge requst CI for checking our fixupsOne of the things that is easy to get wrong during a merge request is making sure all of your changes target the correct commit with a `fixup!`.
We could add a merge request CI to provide some checking.
How should we determine what is ...One of the things that is easy to get wrong during a merge request is making sure all of your changes target the correct commit with a `fixup!`.
We could add a merge request CI to provide some checking.
How should we determine what is an ok target? My initial thoughts would be:
+ If the commit edits, deletes or renames an existing non-mozilla file, then it should target the commit that last touched it.
+ Note, if this commit is also a `!fixup` we strip them to get to the "first" target in this chain.
+ This should work with renames.
+ If the commit adds a new file to a non-mozilla directory, then it should target the commit that last touched the directory.
+ This should capture adding new assets.
+ The directory would be the closest ancestor that existed before the commit. E.g. if we have existing `dirA/dirB` and we add `dirA/dirB/dirC/file`, it would be `dirA/dirB`. This would allow you to add a new directory.
+ If the commit edits a mozilla file for the *first time*, there is no restriction from this file.
+ In this case, I can't think of a way to determine what a correct or incorrect target would be.
+ Maybe we could generate a warning instead? Not sure yet what gitlab allows, or whether we would need a bot account.
+ In this case the commit could be a non-fixup.
+ If the commit edits a mozilla file, that has been edited before, then it should target *one* of the commits that also edits it.
+ Possible false passes: if we have two existing commits that target the same file, but for different reasons, then it would not determine which of these is correct. E.g. `browser/base/content/appmenu-viewcache.inc.xhtml`.
+ Possible false failures: if we are editing a file for some other purpose.
+ If the commits adds a new file to a mozilla directory, then it should target *one* of the commits that also edits it, or be a non-fixup.
+ Similar consequences to the previous case.
Anyone have any suggestions to alter these conditions?
Are there any merge requests where you would not want this to run?
/cc @pierov @ma1 @clairehurst @dan @richard