The Tor Project issues
https://gitlab.torproject.org/groups/tpo/-/issues
2024-03-07T16:19:06Z
https://gitlab.torproject.org/tpo/tpa/team/-/issues/41547
wiki-replica broken
2024-03-07T16:19:06Z
anarcat
wiki-replica broken
Today i've noticed the wiki replica is broken: it seems the "push" mirroring has not worked since at least two weeks ago, with the last commit synced being wiki-replica@acd13d0c.
I'm not sure what's going on. I tried recreating the `wik...
Today i've noticed the wiki replica is broken: it seems the "push" mirroring has not worked since at least two weeks ago, with the last commit synced being wiki-replica@acd13d0c.
I'm not sure what's going on. I tried recreating the `wiki-replica` access token in the [team project settings](https://gitlab.torproject.org/tpo/tpa/team/-/settings/access_tokens) and recreate the mirror but the latter fails to save with the error:
> Remote mirrors url is blocked: Requests to localhost are not allowed
According to [this documentation](https://docs.gitlab.com/ee/security/webhooks.html#allowlist-for-local-requests), this is because the "Allow requests to the local network from webhooks and integrations" setting in the [admin interface](https://gitlab.torproject.org/admin/application_settings/network#js-outbound-settings) is unchecked, and it was, but even after checking the box, the hook still won't save.
So I don't know what's going on. For now, I manually pushed my changes to the wiki.
anarcat
anarcat
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40335
No release for version 2.9.0
2024-02-27T16:41:36Z
Poncho
No release for version 2.9.0
Hi there
Some time ago, you've tagged version 2.9.0
It's available under https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/tags
But there is no corresponding release under https://gitlab.torproject.org/...
Hi there
Some time ago, you've tagged version 2.9.0
It's available under https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/tags
But there is no corresponding release under https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/releases and the release job was skipped https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/jobs/471273
Not sure whether this is all on purpose or if something went wrong. Therefore, opening this issue.
Cecylia Bocovich
Cecylia Bocovich
https://gitlab.torproject.org/tpo/core/arti/-/issues/1277
Make VanguardMgr accessible to CircMgr
2024-03-19T15:07:31Z
gabi-250
Make VanguardMgr accessible to CircMgr
`CircMgr::launch_hs_unmanaged` will need to be able to launch circuits that use vanguards, so `CircMgr` will need a handle to `VanguardMgr`.
Depends on #1275
`CircMgr::launch_hs_unmanaged` will need to be able to launch circuits that use vanguards, so `CircMgr` will need a handle to `VanguardMgr`.
Depends on #1275
Arti: Guard discovery research
gabi-250
gabi-250
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42397
Change RFP-spoofed Timezone from UTC to a real-world, less discriminable one
2024-03-06T08:57:54Z
Thorin
Change RFP-spoofed Timezone from UTC to a real-world, less discriminable one
See:
- https://github.com/mullvad/mullvad-browser/issues/96
- https://bugzilla.mozilla.org/show_bug.cgi?id=1835987
Since `UTC` is rare (if not non-existent outside of RFP?) it looks as if this is being used as a blocker in some anti-bot...
See:
- https://github.com/mullvad/mullvad-browser/issues/96
- https://bugzilla.mozilla.org/show_bug.cgi?id=1835987
Since `UTC` is rare (if not non-existent outside of RFP?) it looks as if this is being used as a blocker in some anti-bot scripts etc, and while TB and RFP are not trying to hide, it's not ideal to use non-common values for compat reasons - not that this is compat. `UTC` is unique (with `Factory` which is just as rare if even used) as a stable all-year-round, all-years measurement for other dates (which usually also have DTS) to be compared to. That is, only `UTC` is _always_ offset as `0` (which makes sense). This made it easy and simple for users to calculate their real time on sites - e.g. sporting event times
Using an amazing tool I found on the internet, tests reveal that there are 13 real-world TZs being used that are identical since 1912, and only off by 16.3333 minutes prior to that
- https://arkenfox.github.io/TZP/tests/timezones.html
- turn on RFP so the diffs are 0's
- type in `1911, 1912`, run `combine years`
item 1
```
<snip> UTC <snip>
a54eb173
1911: 0, 0
1912: 0, 0
```
item 10
```
Africa/Abidjan, Africa/Accra, Africa/Bamako, Africa/Banjul, Africa/Conakry, Africa/Dakar, Africa/Freetown, Africa/Lome, Africa/Nouakchott, Africa/Ouagadougou, Africa/Timbuktu, Atlantic/Reykjavik, Atlantic/St_Helena
1911: -16.133333333333333, -16.133333333333333
1912: 0, 0
```
If we cover all years, these are still the only differences between these 13 and UTC - i.e pre-1912. PS: I cheated and modified the code to only use those 14 TZs and all years from 0 to 2500 :smile:
So in theory, we could use one of these (or if we were sneaky we could randomize it per eTLD+1 per session/identity), and users use-cases of recent and future dates (calendars, web email, looking up event times for sports or concerts etc) will still look and behave like UTC. Dates prior to 1912 are unlikely to need or even use conversion to the user's timezone (e.g. history articles etc). And this should stop the anti-bot discrimination
I wonder if we patch that here in MB first? What would users think when they see non-UTC being reported? Will we be flooded with bug reports? Note there are no entropy issues as all users would still look the same. One consideration is timeZoneNames, but that would be equivalency of locale (which we set same as language)
cc @ruihildt @tom @richard to check my logic and proposed solution
ma1
ma1
https://gitlab.torproject.org/tpo/core/arti/-/issues/1264
libc crate error when building 1.1.13 for alpinelinux
2024-02-14T09:14:20Z
omni
libc crate error when building 1.1.13 for alpinelinux
Trying to upgrade the `arti` aport on alpinelinux, the builds fail on our CI pipelines with:
```
error[E0412]: cannot find type `__rlimit_resource_t` in crate `libc`
--> crates/tor-hsservice/src/replay.rs:529:35
|
529 | ...
Trying to upgrade the `arti` aport on alpinelinux, the builds fail on our CI pipelines with:
```
error[E0412]: cannot find type `__rlimit_resource_t` in crate `libc`
--> crates/tor-hsservice/src/replay.rs:529:35
|
529 | const RLIM: libc::__rlimit_resource_t = libc::RLIMIT_FSIZE;
| ^^^^^^^^^^^^^^^^^^^ not found in `libc`
For more information about this error, try `rustc --explain E0412`.
error: could not compile `tor-hsservice` (lib test) due to previous error
```
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60285
Ian Jackson
iwj@torproject.org
Ian Jackson
iwj@torproject.org
https://gitlab.torproject.org/tpo/applications/vpn/-/issues/141
Wrong colors connect button
2024-03-19T10:57:10Z
kwadronaut
Wrong colors connect button
First start through the quick settings, the connect word on the button doesn't have the right colors.
![image](/uploads/b06015a3539cc114ea316f066b2bf33a/image.png)![Screen_recording_20240202_120508](/uploads/99eef0ba1a5313a40cfbae023ae3...
First start through the quick settings, the connect word on the button doesn't have the right colors.
![image](/uploads/b06015a3539cc114ea316f066b2bf33a/image.png)![Screen_recording_20240202_120508](/uploads/99eef0ba1a5313a40cfbae023ae3d4ac/Screen_recording_20240202_120508.mp4)
VPN pre-alpha 06
cyberta
cyberta
https://gitlab.torproject.org/tpo/anti-censorship/bridge-port-scan/-/issues/7
Build process needs updating
2024-02-07T13:11:37Z
Kez
Build process needs updating
The web team's lektor site build process has changed a bit since this repo was last updated, and the repo no longer builds with the instructions provided (the build instructions seem a bit incomplete even without these build changes). So...
The web team's lektor site build process has changed a bit since this repo was last updated, and the repo no longer builds with the instructions provided (the build instructions seem a bit incomplete even without these build changes). So the build process needs to be updated, and more thoroughly documented.
https://gitlab.torproject.org/tpo/applications/rbm/-/issues/40069
Make stdout and stderr utf8
2024-02-08T06:46:40Z
boklm
Make stdout and stderr utf8
It seems stdout and stderr are not in utf8, so commands such as `rbm/rbm
showconf browser build --target torbrowser-windows-x86_64 --target
nightly --target testbuild` in tor-browser-build will not show correctly
the character `©` (used...
It seems stdout and stderr are not in utf8, so commands such as `rbm/rbm
showconf browser build --target torbrowser-windows-x86_64 --target
nightly --target testbuild` in tor-browser-build will not show correctly
the character `©` (used in `projects/browser/windows-installer.nsi`)
correctly when the terminal is in utf8.
/cc @PieroV
boklm
boklm
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42370
Missing Tor Browser for Android store icon for F-droid
2024-01-19T16:32:55Z
clairehurst
Missing Tor Browser for Android store icon for F-droid
<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
The listing on F-droid doesn't have an icon for Tor Browser for Android for both stable and alpha (see screenshot belo...
<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Summarize the bug encountered concisely.**
The listing on F-droid doesn't have an icon for Tor Browser for Android for both stable and alpha (see screenshot below)
### Environment
**Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc.**
**Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.**
F-droid Basic, Calyxos 5.2.0, Android 14, pixel4a
### Relevant logs and/or screenshots
![Screenshot_20240116-122120](/uploads/324de075c1bfb2a67a0f773e03e3e104/Screenshot_20240116-122120.png){width=25%}
clairehurst
clairehurst
https://gitlab.torproject.org/tpo/core/arti/-/issues/1212
reorder code in ipt_mgr.rs
2024-03-05T15:11:44Z
Ian Jackson
iwj@torproject.org
reorder code in ipt_mgr.rs
```
// TODO HSS: Combine this block with the other impl IptManager<R, M>
// We probably want to make sure this whole file is in a sensible order.
impl<R: Runtime, M: Mockable<R>> IptManager<R, M> {
```
Code changes have resulted in a fi...
```
// TODO HSS: Combine this block with the other impl IptManager<R, M>
// We probably want to make sure this whole file is in a sensible order.
impl<R: Runtime, M: Mockable<R>> IptManager<R, M> {
```
Code changes have resulted in a file that is not necessarily in a logical order. Let's not do that movement right now before I go away.
Arti: Onion service support
Ian Jackson
iwj@torproject.org
Ian Jackson
iwj@torproject.org
https://gitlab.torproject.org/tpo/core/arti/-/issues/1207
replaylog partial write bug
2024-01-25T15:40:14Z
Ian Jackson
iwj@torproject.org
replaylog partial write bug
In `ReplayLog::check_inner`
```
// TODO HSS if write_all fails, it might have written part of the data;
// in that case, we must truncate the file to resynchronise.
// We should probably set a note to...
In `ReplayLog::check_inner`
```
// TODO HSS if write_all fails, it might have written part of the data;
// in that case, we must truncate the file to resynchronise.
// We should probably set a note to truncate just before we call write_all
// and clear it again afterwards.
```
Arti: Onion service support
Ian Jackson
iwj@torproject.org
Ian Jackson
iwj@torproject.org
https://gitlab.torproject.org/tpo/core/arti/-/issues/1205
code duplication between FsStateMgr and state_dir (!1853)
2024-01-24T19:03:05Z
Ian Jackson
iwj@torproject.org
code duplication between FsStateMgr and state_dir (!1853)
Hi, @nickm, you asked me to write a ticket about state_dir vs tor_persist::FsStageMgr.
I think the situation is like this:
Background, contents of the state_dir structs: `state_dir::InstanceStateHandle` will have a `CheckedDir` for the...
Hi, @nickm, you asked me to write a ticket about state_dir vs tor_persist::FsStageMgr.
I think the situation is like this:
Background, contents of the state_dir structs: `state_dir::InstanceStateHandle` will have a `CheckedDir` for the instance-specific state directory, and a lock guard (the lock guard is in the sketch `state_dir.rs`; the `CheckedDir` isn't but one couldn't implement it wihtout). `state_dir::StorageHandle` needs to contain a representation of the path, maybe a mistrust, and another clone of the lock guard, in order to implement the store/load/delete methods.
The actual implementation of the store/load/delete methods needs to be quite similar to those in `tor_persist/src/fs.rs`. (`FsStateMgr::load` and `store`)
But `state_dir` can't call that code because it's entangled with `FsStateMgr` which has its own locking arrangements. (I'm pretty sure `state_dir` doesn't want to try to reuse `FsStateMgr`s locking arrangements, since state_dir has different semantics.)
Looking at the amount of code invovled, it's 40loc including all the generics etc., so maybe just c&p it is OK. It doesn't fill me with happiness.
The obvious answer is to move the implementation of `FsStageMgr::load` and `store` into free functions that take an `&CheckedDir` or a `&Path`, and rely on the caller to do any locking. Then state_dir could just call those.
I'm not sure we want to expose those as a public API of tor-persist though. Maybe instead, we should move state_dir to tor-persist before we implement it, rather than trying to keep it in tor-hsservice. That would make this trivial.
In terms of what I'd like from you: I think the actual code movement or whatever here is straightforward. What I think is needed is a decision about what approach to take.
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/tpo/core/arti/-/issues/1192
Pick a name for the subcomponents of an ArtiPathComponent
2024-02-07T14:48:50Z
gabi-250
Pick a name for the subcomponents of an ArtiPathComponent
#### Context
We need a name for the individual subcomponents (substrings) of non-leaf `ArtiPathComponent`s. These subcomponents (let's call them "slugs" for the purposes of this ticket) have the following properties:
* slugs can be co...
#### Context
We need a name for the individual subcomponents (substrings) of non-leaf `ArtiPathComponent`s. These subcomponents (let's call them "slugs" for the purposes of this ticket) have the following properties:
* slugs can be concatenated to build file names
* when concatenating slugs, they should be separated using `/`, `+`, or `.`. The first slug should not be empty
* slugs should not be concatenated without separators (for security reasons)
* their charset is: lowercase ASCII alphanumerics and underscore. We may extend this to allow additional characters in the future, but `/`, `+`, and `.` (the slug separators) will never be valid slug characters
* they may be empty, but most (all?) of our use cases don't allow empty slugs
`HsNickname`s, non-leaf `ArtiPathComponent`s are slugs, as are the non-leaf components that make up `KeySpecifier`. The leaf component of an `ArtiPath` consists of one or more slugs, concatenated using `+` (for example, some keys have a `TimePeriod` slug)
#### Some possible names
Here are some possible names for the slugs described here:
* Slug
* PathElement
* FnameElement
* NameElement
* IdElt
* PathSlug
* IdStr
* FsId
* FnameId
* PathBlob
* PathSlug
* PathChunk
* Name
* Nick
* ...something else?
#### Platform-specific restrictions
On Windows, the following slugs are forbidden:
* con
* prn
* aux
* nul
* com1, com2, com3, com4, com5, com6, com7, com8, com9, com0
* lpt1, lpt2, lpt3, lpt4, lpt5, lpt6, lpt7, lpt8, lpt9, lpt0
Arti: Onion service support
https://gitlab.torproject.org/tpo/core/arti/-/issues/1179
Upgrade from async-rustls to futures-rustls
2024-01-25T16:03:50Z
Nick Mathewson
Upgrade from async-rustls to futures-rustls
According to the async-rustls crate, it is now deprecated, and we should use futures-rustls instead.
According to the async-rustls crate, it is now deprecated, and we should use futures-rustls instead.
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42355
Fullscreen on Android doesn't hide system bars
2024-01-11T16:31:14Z
Pier Angelo Vendrame
Fullscreen on Android doesn't hide system bars
In Tor Browser 13.0.7, when you go on fullscreen on Android, system bars persist.
So, as a matter of fact, it isn't a real fullscreen.
STR:
1. Open a video (tried on Invidious instances, but also other sites)
2. Go to fullscreen
3. No...
In Tor Browser 13.0.7, when you go on fullscreen on Android, system bars persist.
So, as a matter of fact, it isn't a real fullscreen.
STR:
1. Open a video (tried on Invidious instances, but also other sites)
2. Go to fullscreen
3. Notice that the both the bar with clock/notifications and the "navigation" bar are still visible (I'm using gesture-based navigation, so I don't have a bar with buttons, but a bar with a horizontal line)
If you open the same site on Firefox (but without a custom config such as ours), fullscreen works as expected.
It might have started after the security backport.
Tested on my Pixel 4a, I've seen the problem both on 13.0.7 and on 13.5a3.
/cc @ma1
ma1
ma1
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/30
Best practices for update webtunnel in production
2024-02-23T14:58:41Z
Jacobo Nájera
Best practices for update webtunnel in production
Hi,
What do you recommend to update Webtunnel when you use docker-compose setup?
From my side, it doesn't work
- docker compose pull
- docker compose up --force-recreate --build -d
I'm using "force-recreate" because the latest webt...
Hi,
What do you recommend to update Webtunnel when you use docker-compose setup?
From my side, it doesn't work
- docker compose pull
- docker compose up --force-recreate --build -d
I'm using "force-recreate" because the latest webtunnel image is unchanged. But there is a new version of Tor. But it maintains Tor 0.4.7.13 version.
I also tried with it, but it doesn't work to update Tor version:
- docker compose down --volumes
- docker compose pull
- docker compose build
- docker compose up -d
Thanks, Jacobo
shelikhoo
shelikhoo
https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/259
"Your default search engine is not respectful of your privacy"
2024-03-27T20:34:29Z
two
"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/core/arti/-/issues/1167
Implement a new revision-counter algorithm
2024-01-23T17:22:20Z
gabi-250
Implement a new revision-counter algorithm
If we decide the answer to #1166 is that we should indeed continue including the next TP in the secondary ring, then this [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1828#note_2976777) will need to be addres...
If we decide the answer to #1166 is that we should indeed continue including the next TP in the secondary ring, then this [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1828#note_2976777) will need to be addressed.
@nickm suggests
```
Okay. What's the right way for us to avoid that? I see a few options:
Just don't upload before the start of the time period.
Adjust our zero so that it is the start of the previous time period (or something like that), and increment the other values accordingly. We might need to increase the maximum on our OPE.
Kludge our OPE so that we can encrypt -N through 0 and usually get results in the same area as our C code.
Option 1 would presumably make us less reliable. (How far in advance do we upload, though? And are we right to do so?)
Option 2 would make our OPE less compatible with the C OPE. I think that's okay, though.
Option 3 would take some design, but I think I could figure something out.
```
Arti: Onion service support
https://gitlab.torproject.org/tpo/core/arti/-/issues/1161
"Missing previous key" warnings on restarting onion service
2024-02-22T14:52:08Z
Nick Mathewson
"Missing previous key" warnings on restarting onion service
Sometimes (but not always) when I restart an onion service, I get a bunch of warnings like this:
```
2023-12-13T13:25:58Z ERROR tor_hsservice::ipt_mgr: HS service hewwo missing previous key ArtiPath("hs/hewwo/ipts/k_hss_ntor+398509d88033...
Sometimes (but not always) when I restart an onion service, I get a bunch of warnings like this:
```
2023-12-13T13:25:58Z ERROR tor_hsservice::ipt_mgr: HS service hewwo missing previous key ArtiPath("hs/hewwo/ipts/k_hss_ntor+398509d88033d16af8ef891fd3970d6f189e4a215ea6b40ebab6ea080c29dad4"), regenerating
2023-12-13T13:25:58Z ERROR tor_hsservice::ipt_mgr: HS service hewwo missing previous key ArtiPath("hs/hewwo/ipts/k_sid+398509d88033d16af8ef891fd3970d6f189e4a215ea6b40ebab6ea080c29dad4"), regenerating
2023-12-13T13:25:58Z ERROR tor_hsservice::ipt_mgr: HS service hewwo missing previous key ArtiPath("hs/hewwo/ipts/k_hss_ntor+44b23ce9420e67a94dd88c5529832adcaee6f8af227382e6d41daf643ca5ee82"), regenerating
2023-12-13T13:25:58Z ERROR tor_hsservice::ipt_mgr: HS service hewwo missing previous key ArtiPath("hs/hewwo/ipts/k_sid+44b23ce9420e67a94dd88c5529832adcaee6f8af227382e6d41daf643ca5ee82"), regenerating
2023-12-13T13:25:58Z ERROR tor_hsservice::ipt_mgr: HS service hewwo missing previous key ArtiPath("hs/hewwo/ipts/k_hss_ntor+3c8775e01e11ed6f6ea72a8057f425253d4584d7ff52c0487fbf88ffa32b18d3"), regenerating
2023-12-13T13:25:58Z ERROR tor_hsservice::ipt_mgr: HS service hewwo missing previous key ArtiPath("hs/hewwo/ipts/k_sid+3c8775e01e11ed6f6ea72a8057f425253d4584d7ff52c0487fbf88ffa32b18d3"), regenerating
```
There are two problems here:
First, these should not be at `ERROR`: We should only use ERROR for fatal problems.
Second, they really shouldn't be happening.
@diziet @gabi-250 Any idea what's up here?
Ian Jackson
iwj@torproject.org
Ian Jackson
iwj@torproject.org
https://gitlab.torproject.org/tpo/tpa/status-site/-/issues/39
consider embedding cstate in our common web headers
2023-12-12T15:04:53Z
anarcat
consider embedding cstate in our common web headers
Since cstate 5.5.2, we can embed it in other websites magically:
https://github.com/cstate/html-embed
There are two UIs, the dot indicator ([example](https://cstate-embed.pages.dev/dot-indicator)) and a [popup](https://cstate-embed.pag...
Since cstate 5.5.2, we can embed it in other websites magically:
https://github.com/cstate/html-embed
There are two UIs, the dot indicator ([example](https://cstate-embed.pages.dev/dot-indicator)) and a [popup](https://cstate-embed.pages.dev/dialog).
I'm not super sure where it would be best to fit this, we don't seem to link to the status page from the main frontpage for starters... maybe it could go in the bottom footer, next to "Contact"?
Maybe the "dot" UI could be used in the common footer, and a popup could be added on support.tpo?
@donuts @kez @lavamind opinions?