The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-19T00:06:04Zhttps://gitlab.torproject.org/tpo/web/donate-static/-/issues/111Meta ticket: donate page frontend rewrite MVP2024-03-19T00:06:04Zal smithMeta ticket: donate page frontend rewrite MVPIn our work to redesign & rewrite donate.torproject.org, we identified must-have features for a MVP. Below is the estimated timeline, MVP features that we need to track and prioritize, and ideas for post-MVP features.
# Estimations/time...In our work to redesign & rewrite donate.torproject.org, we identified must-have features for a MVP. Below is the estimated timeline, MVP features that we need to track and prioritize, and ideas for post-MVP features.
# Estimations/timeline
* may-june - front-end design (ux team)
# MVP for frontend
- [ ] Form that donates through stripe
- [ ] Form that donates through paypal
- [ ] List wallet addresses - django setup, yes
- [ ] A link to BTCPay (non-integrated) - django setup, yes
- [ ] Noscript error - django setup, yes
- [ ] Better CRM integration (that meets Fundraising's specs)
- [ ] CMSable/lektorable content [e.g., ability to make new/standalone pages] (within reason)
- [ ] Donation amount array
- [ ] Recurring donations across both Stripe & Paypal
- [ ] Swag display & logic (+ ability to decline swag)
- [ ] CAPTCHA
- [ ] Simple YEC Ticker
- [ ] Simple order summary
- [ ] Redirect to existing thank you page? maybe? or a simple version for the MVP
- [ ] Newsletter signup
# Post-MVP
- Accessible CAPTCHA
- More groovy YEC ticker
- Floating basket thing
- Better thank you page
- Ability to track donations made directly through paypal (not through donate.tpo) and report them to civi ([tpo/anti-censorship/pluggable-transports/snowflake-webext#79](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/79#note_2898912))
# Post-post-MVP
- Full BTCPay API integration (all bells & whistles)
- Can we connect the ShipStation API? Dynamically disable perks?
ccing @mathieu, @kez, @mattlav - here's that meta ticket I promised. :smile:Redesign donate.torproject.orgstephenstephen2023-11-06https://gitlab.torproject.org/tpo/tpa/team/-/issues/41009TPA-RFC-45: long term mail architecture plans2024-02-13T15:21:27ZanarcatTPA-RFC-45: long term mail architecture plansIn TPA-RFC-44 (#40981), we made a pretty stab at deploying urgent fixes to ensure better deliverability across servers and services. It seems we have mostly recovered from the dramatic gmail delivery failures.
But we are still likely to...In TPA-RFC-44 (#40981), we made a pretty stab at deploying urgent fixes to ensure better deliverability across servers and services. It seems we have mostly recovered from the dramatic gmail delivery failures.
But we are still likely to have delivery problems because we forward mail a lot. In fact, we *only* forward mail still: we don't offer people mailboxes, in any shape or form.
There are also clunky things in the way email is setup: all mail routes through eugeni, except not all mail. Some of that mail gets signed by eugeni, but then those keys are not under the right host.
TPA-RFC-44 featured a long term, ambitious plan to fix all of those problems and more. Review this plan to come up with something that may work for 2023 and the forseeable future.
This may include outsourcing, but should include cost estimates, in any case.
Once this is adopted, if this is like TPA-RFC-44 and it blows up in N more tickets, create a milestone for the RFC so we can do better time tracking.
Minimal task list:
1. [ ] Deploy a new, sender-rewriting, mail exchanger (#40987)
2. [ ] split long-term parts of TPA-RFC-44 *out* of it into a new proposal (yes, editing the standard, omg)
3. [ ] update service/email.md to link to TPA-RFC-45 when done
and probably many more...improve mail servicesanarcatanarcat2023-10-18https://gitlab.torproject.org/tpo/tpa/team/-/issues/32558TPA-RFC-47: clarify what happens to email when we retire a user2023-09-20T17:53:29ZanarcatTPA-RFC-47: clarify what happens to email when we retire a userAs part of improving the offboarding process (legacy/trac#32519), we should especially look at how email works.
Right now, when we [retire a user](https://help.torproject.org/tsa/howto/retire-a-user/), their account is first "locked" wh...As part of improving the offboarding process (legacy/trac#32519), we should especially look at how email works.
Right now, when we [retire a user](https://help.torproject.org/tsa/howto/retire-a-user/), their account is first "locked" which means their access to various services is disabled. But their email still works for 186 days (~6 months). After that date, in theory, their email aliases start completely dropping email (needs to be onfirmed).
It's unclear if that's the right policy to follow. Some people feel that an email alias should stay around forever, as it is an inalienable human right.
Others feel that certain administrative roles should be forwarded when a person leave. If, say, "Alice" (fictive name) was doing fundraising but was using `alice@torproject.org` for that work. When they leave, should we forward `alice@` to `fundraising@torproject.org`?
But then what if Alice was using their work email for private correspondance either? Maybe the fundraising team shouldn't be able to see *those* communications.
One proposal could be that the default policy is this:
1. email @torproject.org is "function" email and is destined only for torproject.org related work
2. when a person leave their position, that email gets deactivated after a 6 months delay
3. in extreme cases, some forward may be *temporarily* enabled to reset accesses or re-establish contacts with a provider or third-party
It is also possible that there could be *two* policies, one for TPI employees and one for other TPO people.anarcatanarcat2023-10-18https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/76Onionprobe Triage2023-08-09T00:36:41ZSilvio RhattoOnionprobe TriageI did some brainstorming on fixes and improvements that needs to be evaluated and broken into separate issues:
* [ ] TLS:
* [ ] TLS fingerprinting?
* [ ] TLS anti-fingerprinting?
* [ ] X.509:
* [ ] Option to collect/save TLS certi...I did some brainstorming on fixes and improvements that needs to be evaluated and broken into separate issues:
* [ ] TLS:
* [ ] TLS fingerprinting?
* [ ] TLS anti-fingerprinting?
* [ ] X.509:
* [ ] Option to collect/save TLS certificates.
* [ ] Report if cert is self-signed or not.
* [ ] Test if cert is CA-validated.
* [ ] Test if cert name or SAN has a sauteed onion.
* [ ] SNI test: whether a different certificate is retrieved if a dummy
hostname is provided.
* [ ] Probes:
* [ ] Create a `probes` folder and base class.
* [ ] HTTP, TLS, Certificates, Onion-Location etc as probes.
* [ ] Probes can declare it's dependencies and can be enabled/disabled by global or per-endpoint config.
* [ ] Probes declare their own metrics, which are evaluated upon startup.
* [ ] In the future: support for more service discovery probes.
* [ ] Add support for pluggable probes (Roadmap: Future).
* [ ] HTTP probe:
* [ ] Get all HTTP headers.
* [ ] CI/CD:
* [ ] Schedule regular jobs for pages, slides, debian, configs, python.
* [ ] Debian: check/report lintian errors.
* [ ] Tests:
* [ ] Tor's GitLab Onion Service.
* [ ] Sample Onion Services with many errors (descriptors not
available, self-signed/expired/mismatched certs, misc status codes etc).
* [ ] Test with different locales?
* [ ] Command line tests:
./onionprobe -e bbcnewsd73hkzno2ini43t4gblxvycyac5aw4gnv7t2rccijh7745uqd.onion
./onionprobe -e www.bbcnewsd73hkzno2ini43t4gblxvycyac5aw4gnv7t2rccijh7745uqd.onion
./onionprobe -e www.bbcnewsd73hkzno2ini43t4gblxvycyac5aw4gnv7t2rccijh7745uqd.onion:443
./onionprobe -e https://bbcnewsd73hkzno2ini43t4gblxvycyac5aw4gnv7t2rccijh7745uqd.onion
./onionprobe -e https://www.bbcnewsd73hkzno2ini43t4gblxvycyac5aw4gnv7t2rccijh7745uqd.onion
./onionprobe -e https://www.bbcnewsd73hkzno2ini43t4gblxvycyac5aw4gnv7t2rccijh7745uqd.onion:443
./onionprobe -e https://www.bbcnewsd73hkzno2ini43t4gblxvycyac5aw4gnv7t2rccijh7745uqd.onion:443/
./onionprobe -e https://www.bbcnewsd73hkzno2ini43t4gblxvycyac5aw4gnv7t2rccijh7745uqd.onion:443/index.html
* [ ] Command line:
* [ ] If no .onion is provided, connect to the site using Tor, look for
Onion-Location and then test the service.
* [ ] Support for multiple configuration files (merging endpoints and
options; options found in later configs overrides the previous ones).
* [ ] Logging:
* [ ] Stack tracing on errors when log level is `debug` using the `traceback` module.
* [ ] Add more debug messages.
* [ ] Add a `silent` log level.
* [ ] Docs:
* [ ] Developing:
* [ ] Procedure when adding new options.2023-09-30https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41476Update Android to API Level 332022-11-30T15:56:05ZrichardUpdate Android to API Level 33Per https://support.google.com/googleplay/android-developer/answer/11926878 API level 33 will be rqeuired by November 1 2023.Per https://support.google.com/googleplay/android-developer/answer/11926878 API level 33 will be rqeuired by November 1 2023.2023-09-15https://gitlab.torproject.org/tpo/web/community/-/issues/287[Training] Draft trainer's guides for community portal2024-03-06T13:44:06Zraya[Training] Draft trainer's guides for community portalSince the [training page](/tpo/web/community/-/blob/main/community.torproject.org/training/resources) is going to be [revamped](https://gitlab.torproject.org/tpo/web/community/-/issues/265) to include a trainer's guide for each material ...Since the [training page](/tpo/web/community/-/blob/main/community.torproject.org/training/resources) is going to be [revamped](https://gitlab.torproject.org/tpo/web/community/-/issues/265) to include a trainer's guide for each material created and maintained by the Tor Project, I will be drafting the training guide for:
- [ ] All About Tor
- [ ] Introduction to Onion Services
- [ ] The Tor network
- [ ] Running Tor bridges
### Training guide structure
- Maintained by
- Last updated
- Estimated time
- Long description
- Learning objectives
- Sample slides: list of formats and languages
- Topic tags
- Suggested activities
- Collecting user feedbackrayaraya2023-09-11https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/4Add new calendar that accommodate time before 8 PM UTC2023-08-04T00:17:51ZharletaAdd new calendar that accommodate time before 8 PM UTChttps://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/3#note_2928598https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/3#note_2928598harletaharleta2023-08-07https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/68Verify no outgoing telemetry connections in Mullvad Browser2023-10-02T09:10:01ZrichardVerify no outgoing telemetry connections in Mullvad BrowserWe landed some patches to disable more telemetry in 12.0.3/12.5a3. Before the first release at end of March/start of April we should verify no mystery outgoing connections happen in idle Mullvad Browser.
The expected connections are:
-...We landed some patches to disable more telemetry in 12.0.3/12.5a3. Before the first release at end of March/start of April we should verify no mystery outgoing connections happen in idle Mullvad Browser.
The expected connections are:
- Remote Settings cert revocation list to some Mozilla domain
- Update ping to Mullvad domain (tbd)Pier Angelo VendramePier Angelo Vendrame2023-03-17https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/61Update s28 plugin for v2.6.02022-01-25T21:42:58ZCecylia BocovichUpdate s28 plugin for v2.6.0More details soon. Due date tentative.More details soon. Due date tentative.Sponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)2023-01-21https://gitlab.torproject.org/tpo/core/arti/-/issues/618BridgeDescManager should use SharedMutArc internally2023-01-24T17:28:59ZIan Jacksoniwj@torproject.orgBridgeDescManager should use SharedMutArc internallyBut SharedMutArc needs to be changed first to not contain `Option`.
See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/820#note_2850187But SharedMutArc needs to be changed first to not contain `Option`.
See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/820#note_2850187Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.org2022-12-31https://gitlab.torproject.org/tpo/core/arti/-/issues/617BridgeDescManager should use sleep_wallclock2023-10-10T16:14:55ZIan Jacksoniwj@torproject.orgBridgeDescManager should use sleep_wallclockSee https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/820#note_2850268 et prec.See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/820#note_2850268 et prec.Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.org2022-12-31https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/60Update s28 plugin for v2.5.02022-01-25T21:43:13ZCecylia BocovichUpdate s28 plugin for v2.5.0More details soon. Due date tentative.More details soon. Due date tentative.Sponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)2022-10-01https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/59Update s28 plugin for v2.4.02022-01-25T21:41:04ZCecylia BocovichUpdate s28 plugin for v2.4.0More details soon. Due date tentativeMore details soon. Due date tentativeSponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)2022-08-20https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/82Discussion about the possibility of adding PT support to V2Ray to serve the r...2022-06-30T00:00:49ZshelikhooDiscussion about the possibility of adding PT support to V2Ray to serve the role of HTTPT# Adding Tor PT Support to V2Ray itself
The first option is to add PT support directly to V2Ray. In this way, the PT related code will be maintained directly by V2Fly. If a new protocol is added, it can be used as a PT automatically.
It...# Adding Tor PT Support to V2Ray itself
The first option is to add PT support directly to V2Ray. In this way, the PT related code will be maintained directly by V2Fly. If a new protocol is added, it can be used as a PT automatically.
It would be more difficult to add generalized PT support to V2Ray than add a Tor Specific PT support to HTTPT. However, if we can do that correctly, a significant amount of protocols(including future ones) can be supported at no additional cost.
## Teaching PT protocol to V2Ray
Currently, V2Ray does not understands PT protocol. As per the V2Ray convention, the support for PT will be split into components and be made reusable.
In order to add Tor PT protocol support, following Tor specific code will need to be supported in addition to general-purpose PT client support.
* ExtOR protocol
* Socks5-Tor protocol
* PT IPC(environment variable to option mapping)
## Design interactions between Tor and V2Ray
Tor can only transfer 256 characters of information in client connection. However, a V2Ray full configuration file is about 2K - 50 KB long, so there is no way of transferring all the information necessary in the connection parameter itself. So we would need to transfer only the info needed.
Here are some of the candidates:
* Outbound name (Cannot customize connection detail)
* Config file name + Outbound name (Requires external file)
* Outbound Config JSON Content (complex config may be longer than 256 characters)
* Connection specification link(flat option to option config) (requires active maintenance to keep link and settings in sync)
If we just modify HTTPT to work with Tor, it can simply use a Connection specification link, like all other PTs.
## Additional Optional Features lacking
* uTLS support is not currently in V2Ray
# Adding Tor PT Support as a separate program
We can create a separate program that reuses V2Ray's code to create a PT like https://github.com/shadowsocks/v2ray-plugin.
It is easier to add Tor PT support if that part of the code does not need to be subject to ordinary quality control and architecture of V2Ray.
It is worth noting that in this case, this program will require active maintenance. And this program will not be super beneficial parties other Tor communities, so the maintenance cost will not be shared by others.
## Conflict of Interest
@shelikhoo volunteer as the organization representative of Project V(V2Fly) and maintainer of V2Ray outside day job.2022-06-23https://gitlab.torproject.org/tpo/core/fallback-scripts/-/issues/40001Rebuild the fallback list in 20212021-11-15T16:46:19ZDavid Gouletdgoulet@torproject.orgRebuild the fallback list in 2021Ticket to track all changes needed to the existing list rebuilt in https://gitlab.torproject.org/tpo/core/fallback-scripts/-/issues/30971
If we drop below 25% reachability, the list will be re-generated. Until then, we will run this unt...Ticket to track all changes needed to the existing list rebuilt in https://gitlab.torproject.org/tpo/core/fallback-scripts/-/issues/30971
If we drop below 25% reachability, the list will be re-generated. Until then, we will run this until mid-2021.2021-06-01https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42490Install svg from branding theme to browser/chrome/icons/default2024-03-28T10:14:53ZboklmInstall svg from branding theme to browser/chrome/icons/defaultIn
https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/943#note_3013584,
@PieroV mentioned that we have svg files (added in commits `Bug 2176:
Rebrand Firefox to TorBrowser` and `MB 1: Mullvad Browser brandi...In
https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/943#note_3013584,
@PieroV mentioned that we have svg files (added in commits `Bug 2176:
Rebrand Firefox to TorBrowser` and `MB 1: Mullvad Browser branding`),
but we currently don't install them to `browser/chrome/icons/default`.
If we do that we can then update the debian package to link them from
`/usr/share/icons/hicolor/scalable/apps`.https://gitlab.torproject.org/tpo/applications/vpn/-/issues/151reconnect/new circuit when changing bridge type or on/off2024-03-28T10:49:31Zkwadronautreconnect/new circuit when changing bridge type or on/offIs there a need to reconnect/move to a new circuit when the bridge settings are changed: bridge on/off or type (obfs4 or snowflake for now).Is there a need to reconnect/move to a new circuit when the bridge settings are changed: bridge on/off or type (obfs4 or snowflake for now).Sponsor 101 - Tor VPN Client for Androidhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42489Lox module notifications2024-03-28T10:07:16ZhenryLox module notificationsCurrently the Lox module does not give out notifications for when its internals change, so:
+ `TorSetting` is not notified when the bridges change. So it is only set to the new value when restarting Tor Browser.
+ "about:preferences" is...Currently the Lox module does not give out notifications for when its internals change, so:
+ `TorSetting` is not notified when the bridges change. So it is only set to the new value when restarting Tor Browser.
+ "about:preferences" is not notified when the invites change or when there is a blockage or upgrade event.henryhenryhttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/150Version 0.5.0 crashes when being run with ARMv8.5 MTE (memory tagging)2024-03-28T09:54:40Zfid02Version 0.5.0 crashes when being run with ARMv8.5 MTE (memory tagging)When running Tor VPN with ARMv8.5 [memory tagging](https://developer.android.com/ndk/guides/arm-mte) enabled, after tapping on the Connect button the app will crash within 3 seconds, and will produce the attached error.
[Error_in_Tor_VPN...When running Tor VPN with ARMv8.5 [memory tagging](https://developer.android.com/ndk/guides/arm-mte) enabled, after tapping on the Connect button the app will crash within 3 seconds, and will produce the attached error.
[Error_in_Tor_VPN_d259276bb201.txt](/uploads/3a2f447b299ee4805da463ec37ae87f3/Error_in_Tor_VPN_d259276bb201.txt)
You will currently only be able to reproduce this in production on a Google Pixel 8 or Google Pixel 8 Pro device, running GrapheneOS with memory tagging enabled for the Tor VPN Android app.
Please note that this is not a bug with GrapheneOS, it is a memory corruption bug which is exposed by GrapheneOS. Android will be eventually deploying memory tagging by default, so this will need to be resolved before that point, to avoid the app being broken for users with an MTE-capable device.
Steps to reproduce:
1. Install Tor VPN version 0.5.0 from the Gitlab package archive
2. Open Tor VPN and dismiss the dialog shown upon first run
3. Tap on Connect
Not being experienced in debugging native code, I do not know if this is a memory corruption within little-t tor or within the Tor VPN app itself.
version 0.5.0
org.torproject.vpn
versionCode 5
Installed from the Gitlab package archivehttps://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues/97Password Reset / Change Missing2024-03-28T09:43:49ZAnonymous420Password Reset / Change MissingThere is no way to change a password, or recover an account once you lose your password.There is no way to change a password, or recover an account once you lose your password.