The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-19T10:57:10Zhttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/141Wrong colors connect button2024-03-19T10:57:10ZkwadronautWrong colors connect buttonFirst 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 06cybertacybertahttps://gitlab.torproject.org/tpo/core/arti/-/issues/1260Discrepancy `hs` for keys, `hss` for non-key data2024-02-01T15:57:44ZIan Jacksoniwj@torproject.orgDiscrepancy `hs` for keys, `hss` for non-key dataAfter #1183, and when we use !1935, we'll have `hss` for "storage" and `hs` for keys - see below.
We should make these consistent. I think we should change `hs` to `hss` in `KeySpecifier` impls.
MUST because this will be an incompatib...After #1183, and when we use !1935, we'll have `hss` for "storage" and `hs` for keys - see below.
We should make these consistent. I think we should change `hs` to `hss` in `KeySpecifier` impls.
MUST because this will be an incompatible change.
```
/home/rustcargo/.local/share/arti/hss
/home/rustcargo/.local/share/arti/hss/ztest
/home/rustcargo/.local/share/arti/hss/ztest/iptpub.json
/home/rustcargo/.local/share/arti/hss/ztest/ipts.json
/home/rustcargo/.local/share/arti/hss/ztest/iptreplay
/home/rustcargo/.local/share/arti/hss/ztest/iptreplay/8515aa9a4e0d242d8a9b2115f7c4e7eb3a7abc0a34bc46197d4dbc993b0a8ce3.bin
/home/rustcargo/.local/share/arti/hss/ztest/iptreplay/0625d5fabb9b1a7665d6a8c9ee05c745ec7380c5f9dbba3de4cb7aee5d55d398.bin
/home/rustcargo/.local/share/arti/hss/ztest/iptreplay/965e288fd6720de8bffd4509571e52846e5130658fde99447bd54aae5268a478.bin
/home/rustcargo/.local/share/arti/hss/ztest.lock
/home/rustcargo/.local/share/arti/keystore
/home/rustcargo/.local/share/arti/keystore/hs
/home/rustcargo/.local/share/arti/keystore/hs/ztest
/home/rustcargo/.local/share/arti/keystore/hs/ztest/KS_hs_blind_id+19751_1440_43200.ed25519_expanded_private
/home/rustcargo/.local/share/arti/keystore/hs/ztest/KS_hs_desc_sign+19751_1440_43200.ed25519_private
/home/rustcargo/.local/share/arti/keystore/hs/ztest/KS_hs_blind_id+19752_1440_43200.ed25519_expanded_private
/home/rustcargo/.local/share/arti/keystore/hs/ztest/KP_hs_id.ed25519_public
/home/rustcargo/.local/share/arti/keystore/hs/ztest/KS_hs_id.ed25519_expanded_private
/home/rustcargo/.local/share/arti/keystore/hs/ztest/ipts
/home/rustcargo/.local/share/arti/keystore/hs/ztest/ipts/k_hss_ntor+8515aa9a4e0d242d8a9b2115f7c4e7eb3a7abc0a34bc46197d4dbc993b0a8ce3.x25519_private
/home/rustcargo/.local/share/arti/keystore/hs/ztest/ipts/k_sid+8515aa9a4e0d242d8a9b2115f7c4e7eb3a7abc0a34bc46197d4dbc993b0a8ce3.ed25519_private
/home/rustcargo/.local/share/arti/keystore/hs/ztest/ipts/k_hss_ntor+0625d5fabb9b1a7665d6a8c9ee05c745ec7380c5f9dbba3de4cb7aee5d55d398.x25519_private
/home/rustcargo/.local/share/arti/keystore/hs/ztest/ipts/k_hss_ntor+965e288fd6720de8bffd4509571e52846e5130658fde99447bd54aae5268a478.x25519_private
/home/rustcargo/.local/share/arti/keystore/hs/ztest/ipts/k_sid+965e288fd6720de8bffd4509571e52846e5130658fde99447bd54aae5268a478.ed25519_private
/home/rustcargo/.local/share/arti/keystore/hs/ztest/ipts/k_sid+0625d5fabb9b1a7665d6a8c9ee05c745ec7380c5f9dbba3de4cb7aee5d55d398.ed25519_private
```Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1259BackoffSchedule improvements2024-03-07T21:07:02Zgabi-250BackoffSchedule improvementsWe might want to:
* rename `BackoffSchedule::timeout` to `BackoffSchedule::overall_timeout` for clarity
* introduce a `BackoffSchedule::single_attempt_timeout() -> Option<Duration>` function for controlling the timeout for each att...We might want to:
* rename `BackoffSchedule::timeout` to `BackoffSchedule::overall_timeout` for clarity
* introduce a `BackoffSchedule::single_attempt_timeout() -> Option<Duration>` function for controlling the timeout for each attempt. See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1911#note_2988170
For context, see the discussion on !1911gabi-250gabi-250https://gitlab.torproject.org/tpo/community/policies/-/issues/17Write proposal to restrict contact information field to email address (and ma...2024-03-27T09:39:44ZGeorg KoppenWrite proposal to restrict contact information field to email address (and make it mandatory)We should write a proposal to make sure `ContactInfo` is really just an email address. We could add a second step where we want to enforce it actually. Tor's man page says:
```
ContactInfo email_address
Administrative c...We should write a proposal to make sure `ContactInfo` is really just an email address. We could add a second step where we want to enforce it actually. Tor's man page says:
```
ContactInfo email_address
Administrative contact information for this relay or bridge. This line
can be used to contact you if your relay or bridge is misconfigured or
something else goes wrong. Note that we archive and publish all
descriptors containing these lines and that Google indexes them, so
spammers might also collect them. You may want to obscure the fact that
it’s an email address and/or generate a new address for this purpose.
ContactInfo must be set to a working address if you run more than one
relay or bridge. (Really, everybody running a relay or bridge should
set it.)
```
which is already pretty close to what I plan to propose. This is related to https://gitlab.torproject.org/tpo/core/arti/-/issues/870.
@gus is not done with the meta proposal yet, so I wait for that. Additionally, I am not sure yet how to split this up properly for some potentially needed tor-spec proposal.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40012Domain fronting requests don't work on some older Android versions2024-03-12T00:09:26ZPier Angelo VendrameDomain fronting requests don't work on some older Android versionsTor Browser for Android supports old versions of Android (API21, i.e., Android Lollipop).
While 13.5a3 doesn't work there because I used some NIO API that requires API26+, I've opened a MR to fix this (tpo/applications/tor-browser!894)....Tor Browser for Android supports old versions of Android (API21, i.e., Android Lollipop).
While 13.5a3 doesn't work there because I used some NIO API that requires API26+, I've opened a MR to fix this (tpo/applications/tor-browser!894).
While checking if things worked, I noticed that domain fronting requests don't (I don't get the special countries list).
As written in that MR, I tried to enable logging (I added `"-enableLogging", "-logLevel", "DEBUG", "-unsafeLogging"` as arguments), but I could get only these messages:
```
2024/01/22 10:20:23 [NOTICE]: obfs4proxy-0.0.14 - launched
2024/01/22 10:20:23 [INFO]: libObfs4proxy.so - initializing client transport listeners
2024/01/22 10:20:23 [INFO]: meek_lite - registered listener: 127.0.0.1:55852
2024/01/22 10:20:23 [INFO]: libObfs4proxy.so - accepting connections
2024/01/22 10:20:23 [WARN]: meek_lite(bridges.torproject.org:443) - closed connection: readfrom tcp 127.0.0.1:55852->127.0.0.1:48836: io: read/write on closed pipe
```
I think there might be some problems with some HTTPS certificate (at least letsencrypt had this problem a few years ago, indeed cohosh mentioned snowflake#40087. Fastly isn't using letsencrypt, but maybe they have a similar problem).
I can open bridges.torproject.org both in TBA and in the system browser, but I can't open https://moat.torproject.org.global.prod.fastly.net/ because it has a wrong certificate.
I don't think I'm using the latest version of Lyrebird, because in the last one the log file should be called lyrebird.log (I submitted a patch for that, unless I missed the log filename), but I can try to build one from a nightly build.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/applications/rbm/-/issues/40067Use --no-verbose wget option when not running in a terminal2024-01-29T17:32:23ZboklmUse --no-verbose wget option when not running in a terminalIn !53, @Mynacol reported that when a build is done in a CI, the logs
are filled with wget outputs, and using the `--no-verbose` option is
fixing that.
However seeing the download progress is still useful when doing
interactive builds, ...In !53, @Mynacol reported that when a build is done in a CI, the logs
are filled with wget outputs, and using the `--no-verbose` option is
fixing that.
However seeing the download progress is still useful when doing
interactive builds, so I think we add the `--no-verbose` option only
when we are not in a TTY.boklmboklmhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41486Tor theme for LimeSurvey2024-02-01T22:42:52ZsajolidaTor theme for LimeSurveyAs part of tpo/ux/research#130, I created a Tor theme for LimeSurvey that has a Tor color scheme and prints better on paper.
You can see the theme in action on https://survey.potager.org/index.php/457772.
I stored it in a Git repositor...As part of tpo/ux/research#130, I created a Tor theme for LimeSurvey that has a Tor color scheme and prints better on paper.
You can see the theme in action on https://survey.potager.org/index.php/457772.
I stored it in a Git repository for now: https://gitlab.com/sajolida/fruity-twentythree-tor.
I'm wondering what's the best way of deploying it, also keeping future maintenance in mind.
LimeSurvey has a fancy theme editor that allows editing the CSS from a web interface:
![image](/uploads/d60aee1163b46772c6477e8d78e5104d/image.png)
This should be enough for future tweaks.
But I think that the first deployment needs a full clone of the Git repo (or copy of its files) because I'm also uploading fonts, adding more CSS files (`theme_tor.css`), and editing the config.yml, which is not available from the theme editor.
Also, right now my LimeSurvey account doesn't seem to have access to the theme editor. I don't really mind because I already have a prototyping setup to continue working on the theme, but then sysadmins would have to synchronize your LimeSurvey with my Git repo from time to time. This would also prevent breaking live surveys when doing experiments on the theme.
On the long term, maybe Tor could host this Git repo and automatically sync LimeSurvey in production whenever it's main branch is updated.
Cc: @donutsJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/core/torspec/-/issues/252Assign mnemonic names to subprotocol versions2024-02-14T14:49:16ZNick MathewsonAssign mnemonic names to subprotocol versionsWe've talked about this a bit: it would be handy in our specs, and handy in implementations too.
The idea here is that that in in our documentation, in addition to opaque names like "DirCache=2" or "FlowCtrl=2", we would say something...We've talked about this a bit: it would be handy in our specs, and handy in implementations too.
The idea here is that that in in our documentation, in addition to opaque names like "DirCache=2" or "FlowCtrl=2", we would say something like "DIRCACHE_CONSENSUS_DIFFS" or "FLOWCTRL_CONGESTION_CTRL".Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/135Figure out UX for (possibly repeated) connection failures2024-03-06T20:13:28ZetaFigure out UX for (possibly repeated) connection failuresThe onionmasq layer exposes an event every time we fail to connect to something via Tor. Currently, we don't really surface these to the user in any interesting way. But should we?
I think this is something I raised ages ago and wanted ...The onionmasq layer exposes an event every time we fail to connect to something via Tor. Currently, we don't really surface these to the user in any interesting way. But should we?
I think this is something I raised ages ago and wanted @donuts to have a small think about from a UX perspective: we definitely don't want to push a notification every time this happens, because failing to connect to things is probably a normal occurrence for many apps (and/or they'll just retry such failed connections themselves, etc). But if the same thing is **repetitively** failing, the user might appreciate a proactive heads-up of some kind, so they can know it's to do with the way the VPN is configured (maybe exit policy, some censorship-related problem, or some isolation settings, etc.).
We also maybe want to design some sort of page where users can go to see recently failed connections? I'm not actually sure what the best UX for this would be, but I think it'd be nice to surface this information in some way!https://gitlab.torproject.org/tpo/network-health/metrics/networkstatusapi/-/issues/35add more metadata about relays: #1 DNSSEC validation, #2 DNS server2024-01-18T14:51:30Zcypherpunksadd more metadata about relays: #1 DNSSEC validation, #2 DNS serverIt would be great to show relay operators more information about what they could improve on their relay configuration. In the area of exits and DNS this could be:
- DNSSEC
- do not use Google, Cloudflare, Quad9,.. DNS server
To support...It would be great to show relay operators more information about what they could improve on their relay configuration. In the area of exits and DNS this could be:
- DNSSEC
- do not use Google, Cloudflare, Quad9,.. DNS server
To support this we would first need two new onionoo fields before adding indicators to Relay Search. Both fields are only relevant for exit relays.
dnssec_validation: boolean
True if the exit relay does validate
dns_resolver: string
PTR record for the IP address used to resolve a hostname via this exit.
To collect the data you could run exitmap's dnssec and dnsenum modules once every ~12 hours.
https://github.com/NullHypothesis/exitmap/blob/master/src/modules/dnssec.py
https://github.com/NullHypothesis/tor-dns/blob/master/code/resolvers-of-exit-relays/dnsenum.py
context:
https://twitter.com/nusenu_/status/983302939258138626https://gitlab.torproject.org/tpo/team/-/issues/247Onboarding Bella: Community team2024-02-20T12:54:25Zbellabella@torproject.orgOnboarding Bella: Community teamOnboarding with @gus to the Community team:
- [x] Roles and expectations
- [x] Schedule weekly meetings
- [x] Schedule introduction to other team members
- [x] Be added to relevant team meetings
- [ ] Create account for Bella at forum....Onboarding with @gus to the Community team:
- [x] Roles and expectations
- [x] Schedule weekly meetings
- [x] Schedule introduction to other team members
- [x] Be added to relevant team meetings
- [ ] Create account for Bella at forum.torproject.org
- [x] Team overview: team's structure, relevant documentations.
- [x] Understand the closest priorities/deadlines against the timeline
- [x] Map out 2024 deliverable priorities
- [ ] Review the Community team board together
- [x] Deep dive into projects contextsbellabella@torproject.orgbellabella@torproject.org2024-01-31https://gitlab.torproject.org/tpo/tpa/team/-/issues/41473consider enforcing 2FA across gitlab2024-02-07T15:55:26Zanarcatconsider enforcing 2FA across gitlabIn #41470, we investigated the impact of an [authentication bypass in GitLab](https://about.gitlab.com/releases/2024/01/11/critical-security-release-gitlab-16-7-2-released/#account-takeover-via-password-reset-without-user-interactions) (...In #41470, we investigated the impact of an [authentication bypass in GitLab](https://about.gitlab.com/releases/2024/01/11/critical-security-release-gitlab-16-7-2-released/#account-takeover-via-password-reset-without-user-interactions) ([CVE-2023-7028](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-7028)). One of the key takeaways is that 2FA renders the attack mostly moot. This makes this group (tpo/tpa) immune to it, but not all users benefit from this.
We should consider enforcing 2FA more broadly here. One likely first target would be tpo/web, which has only a handful of users without 2FA (one of which was @gitolite-merge-bot, which was removed access in #41469). But we could broaden this to all of tpo.
Thoughts, @gaba, @lavamind ?Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org2024-02-05https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40322Local LAN access through snowflake2024-02-27T11:30:44Zdreamboat301Local LAN access through snowflakeHi
I'm a little bit late to the party. I've read a report from the 37C3 about the success helping people from Iran and other countries avoiding traffic blocks.
So I installed a snowflake instance in proxmox and I was overwhelmed with t...Hi
I'm a little bit late to the party. I've read a report from the 37C3 about the success helping people from Iran and other countries avoiding traffic blocks.
So I installed a snowflake instance in proxmox and I was overwhelmed with traffic. Mostly from Iran and roughly 25 GB a day. I love it that I could be of help!
But I believe there is an issue with it.
I put the instance in its own VLAN and configured the firewall to block any VLAN traffic to and from this network.
A few times a day I get an alert in my firewall claiming that this machine wants to connect to other VLANs. First I thought it might answer broadcast messages. But the IPs it requests don't exist. E.g. 192.168.1.5 is nowhere to be seen. But these are only the visable connections. Because of the nature of Unifi I can't block access to 192.168.1.1 because it is the same as 192.168.x.1 of any VLAN. So I shut down the instance to avoid people of maybe hacking my network. There were also connections to 10.x.x.x networks.
How can this be possible, that people can access my local LAN? I thought that I'm just a bridge to the Tor network and forwarding any traffic to it. Including local LAN addresses (or blocking it).
I've done a few tests. If I access in Tor Browser the IP 192.168.1.1 it gets blocked right away. Thats fine. I created a subdomain of a domain I own and added 192.168.1.1 as an A record. Suddendly I'm able to get through. Somewhere it is blocked anyway but it looks like that it is not fully blocked.
I'm just a home user. Please have patience with me when you direct me to do something.https://gitlab.torproject.org/tpo/community/policies/-/issues/16Write a proposal for acceptable/unacceptable sustainability/incentivization o...2024-03-13T14:33:03ZGeorg KoppenWrite a proposal for acceptable/unacceptable sustainability/incentivization of relay operationsFollowing the ATOR incident we should write a proposal about what we expect from schemes claiming to enhance the sustainability of relay operations by providing (a bunch of) incentives. For some recent blog post around this topic, see: h...Following the ATOR incident we should write a proposal about what we expect from schemes claiming to enhance the sustainability of relay operations by providing (a bunch of) incentives. For some recent blog post around this topic, see: https://blog.torproject.org/tor-network-community-health-update/GusGushttps://gitlab.torproject.org/tpo/core/arti/-/issues/1222Add central documentation for our filesystem layout2024-02-01T15:43:34ZNick MathewsonAdd central documentation for our filesystem layoutSomewhere in doc/dev, we should document all the files that we create or look at.
This will include:
* `tor-keymgr` stuff, possibly by reference
* All state files
* All onion-service-related files
* All cache files
* All locks...Somewhere in doc/dev, we should document all the files that we create or look at.
This will include:
* `tor-keymgr` stuff, possibly by reference
* All state files
* All onion-service-related files
* All cache files
* All locks
* All configuration files
This should replace `crates/tor-hsservice/src/state_dir.md` (cc @diziet)https://gitlab.torproject.org/tpo/applications/torbrowser-launcher/-/issues/13Add script to tag new release2024-01-15T08:42:29ZboklmAdd script to tag new releaseWe can add a script to run the `git tag` command to sign a new release.We can add a script to run the `git tag` command to sign a new release.boklmboklmhttps://gitlab.torproject.org/tpo/team/-/issues/243Setup weekly meetings with team leads2024-01-29T21:02:09Zbellabella@torproject.orgSetup weekly meetings with team leads- Schedule weekly meetings with @gus, @donuts and @richard
- Introductions, roles and expections, preferred forms of communication.- Schedule weekly meetings with @gus, @donuts and @richard
- Introductions, roles and expections, preferred forms of communication.bellabella@torproject.orgbellabella@torproject.org2024-01-18https://gitlab.torproject.org/tpo/onion-services/onionspray/-/issues/13Rename/rebrand the EOTK fork?2024-01-23T00:46:29ZSilvio RhattoRename/rebrand the EOTK fork?# Tasks
* [x] Discuss whether this fork should be renamed or rebranded.
* [x] If so, determine the new name.
* [x] If so, proceed doing the rename (replace strings in the scripts, configs and docs etc):
* [x] Rename the GitLab project...# Tasks
* [x] Discuss whether this fork should be renamed or rebranded.
* [x] If so, determine the new name.
* [x] If so, proceed doing the rename (replace strings in the scripts, configs and docs etc):
* [x] Rename the GitLab project.
* [x] Rename the script.
* [x] Symlink the script to keep the old name available.
* [x] Rename EOTK uppercase, then all lowercase occurences in the docs.
* [x] Then try to do the same in configs, templates and scripts.
* [x] Assume regressions might happen, and inform users to report problems.
* [x] Update the ChangeLog, reporting this as a breaking change.
* [x] If so, test the software to ensure the rename won´t add bugs.
* [x] In any case, the [original upstream project](https://github.com/alecmuffett/eotk) should get credit.
* [x] Add the software in the list of [maintained products](https://gitlab.torproject.org/tpo/team/-/wikis/Products).
# Time estimation
* Complexity: very small (0.5 day)
* Uncertainty: low (x1.1)
* [Reference](https://jacobian.org/2021/may/25/my-estimation-technique/) (adapted)Onionspray 1.6.0Silvio RhattoSilvio Rhatto2024-01-31https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/311 webtunnel bridge instead of two!2024-02-27T19:09:02Zcypherpunks1 webtunnel bridge instead of two!You should give at least two bridges for conflux to work.You should give at least two bridges for conflux to work.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/applications/torbrowser-launcher/-/issues/10Update share/torbrowser-launcher/tor-browser-developers.asc with updated key2024-01-08T12:55:59ZboklmUpdate share/torbrowser-launcher/tor-browser-developers.asc with updated keyThe Tor Browser gpg signing key has been updated with new expiration
date. So we should update it in
`share/torbrowser-launcher/tor-browser-developers.asc`.The Tor Browser gpg signing key has been updated with new expiration
date. So we should update it in
`share/torbrowser-launcher/tor-browser-developers.asc`.boklmboklm