The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-01-29T19:17:37Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42025Purple elements (e.g. Tor buttons) need dark theme variants2024-01-29T19:17:37ZdonutsPurple elements (e.g. Tor buttons) need dark theme variantsThere are several components in the browser that use the Photon purple color scheme instead of Fx's default blue, including (but potentially not limited to):
- "Tor Browser" in the identity block
- "Connect" buttons
- ".onion" available...There are several components in the browser that use the Photon purple color scheme instead of Fx's default blue, including (but potentially not limited to):
- "Tor Browser" in the identity block
- "Connect" buttons
- ".onion" available buttons
- "Connected" status in the title bar
- "Connected" flag on bridge cards
- Connection status spinners
And in the new homepage being developed in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41333:
- Links
- Onionize toggle
Typically, these use the following values for light theme:
- default: purple-60 `#8000D7`
- hover: purple-70 `#6200A4`
- pressed: purple-80 `#440071`
- focus: purple-60 `#8000D7`
And were designed to use the following values for dark theme, however this never happened:
- default: purple-30 `#C069FF`
- hover: purple-40 `#AD3BFF`
- pressed: purple-50 `#9400FF`
- focus: purple-60 `#C069FF`
There are three issues here:
1. Semantic color tokens for dark theme were never created.
2. As @henry has rightfully pointed out, the previous design for dark theme went darker on interaction – which is unusual, and not accessible. However we were limited by a lack of having anything lighter than purple-30 in the browser.
3. The purples used are out of date (having originated from Photon), and have since been superseded by new purple color tokens documented in the [Acorn](https://acorn.firefox.com/latest/styles/color-MZHBVuZc) and [Protocol](https://protocol.mozilla.org/docs/fundamentals/color.html) styleguides.
In order to fix this, we'll need to update our existing purple color tokens to include lighter steps. This could be done by migrating to the new values documented in Acorn/Protocol, or by using a custom purple palette.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41482Bridge cards should inform users when a bridge isn't working2024-01-29T19:06:20ZGusBridge cards should inform users when a bridge isn't workingWhen a user requests a bridge using one of the bridge distributors (moat, telegram, connection assist), some of them may be blocked in their region. Users can see which bridge is failing on their Tor logs. Is it possible to display that ...When a user requests a bridge using one of the bridge distributors (moat, telegram, connection assist), some of them may be blocked in their region. Users can see which bridge is failing on their Tor logs. Is it possible to display that information on the bridge card so they don't need to check the logs?https://gitlab.torproject.org/tpo/web/donate-neo/-/issues/8Design high-fidelity mockups of new donate templates2024-01-29T19:01:55ZdonutsDesign high-fidelity mockups of new donate templatesDesign high-fidelity mockups that support our compatibility requirements for screen size & resolution:
> The donate portal should make use of the latest responsive design techniques with mainstream adoption among our target browsers (se...Design high-fidelity mockups that support our compatibility requirements for screen size & resolution:
> The donate portal should make use of the latest responsive design techniques with mainstream adoption among our target browsers (see 'Browser support') to provide user-friendly layouts that adapt to the user's screen size. At minimum, the donate portal should support screens of 320px wide, with no defined upper limit beyond the maximum width of the site's container.
>
> Text and other elements may be reduced in size at smaller screen sizes to reflect higher pixel densities and reduced viewing distances.
In addition, the new designs should align with our commitment to AA compliance with the WCAG 2.1 accessibility standard:
> The donate portal should strive to meet, at minimum, the [WCAG 2.1's success criteria for Level AA compliance](https://www.w3.org/TR/WCAG21/). Should it not be possible for a particular element to meet the criteria for AA compliance, an alternative should be provided or an exemption agreed with the Tor Project.
>
> At a glance, particular care should be taken to meet the following requirements as laid out in more detail in the [WCAG 2.1 technical specification](https://www.w3.org/WAI/standards-guidelines/wcag/glance/):
>
> **Perceivable**
> Provide text alternatives for non-text content.
> Provide captions and other alternatives for multimedia.
> Create content that can be presented in different ways, including by assistive technologies, without losing meaning.
> Make it easier for users to see and hear content.
>
> **Operable**
> Make all functionality available from a keyboard.
> Give users enough time to read and use content.
> Do not use content that causes seizures or physical reactions.
> Help users navigate and find content.
> Make it easier to use inputs other than keyboard.
>
> **Understandable**
> Make text readable and understandable.
> Make content appear and operate in predictable ways.
> Help users avoid and correct mistakes.
>
> **Robust**
> Maximize compatibility with current and future user tools.
**Todo list:**
- [x] Credit card template
- [x] PayPal template
- [x] Cryptocurrency template
- [x] Noscript template
- [x] Thank you page template
- [ ] ~~Supporter, Defender & Champion states~~ ← Removed from the scope for the MVP
- [ ] Campaign takeover example
- [ ] Active, inactive, focus and selected states
- [ ] Error states
On the following formats:
- [x] Desktop
- [ ] Mobile
**High-fidelity mockups**
- [Figma / Marble Style guide / Donate-dot](https://www.figma.com/file/nIpahk0b9VMaeEnubiO33g/Marble-style-guide?type=design&node-id=447%3A3457&mode=design&t=WtHoL3Xw8Yau9G4a-1)Redesign donate.torproject.orgdonutsdonutshttps://gitlab.torproject.org/tpo/core/arti/-/issues/1122Review descriptor publisher docs2024-01-29T14:58:49Zgabi-250Review descriptor publisher docsArti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1179Upgrade from async-rustls to futures-rustls2024-01-25T16:03:50ZNick MathewsonUpgrade from async-rustls to futures-rustlsAccording 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 MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1207replaylog partial write bug2024-01-25T15:40:14ZIan Jacksoniwj@torproject.orgreplaylog partial write bugIn `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 supportIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/80Makre sure we re-parse documents in case there are parsing errors2024-01-25T15:38:06ZGeorg KoppenMakre sure we re-parse documents in case there are parsing errorsOur download script is smart enough to re-download documents in case there were errors when fetching the latest ones, so we don't "lose" data in our DB:
```
download_url=https://collector.torproject.org/recent/$p/$u
log_file=$PAR...Our download script is smart enough to re-download documents in case there were errors when fetching the latest ones, so we don't "lose" data in our DB:
```
download_url=https://collector.torproject.org/recent/$p/$u
log_file=$PARSER_HOME/logs/downloads.log
if ! grep -q "$download_url" "$log_file"; then
status=$(wget --server-response ${download_url} 2>&1 | awk '/^ HTTP/{print $2}')
if [ "$status" = "200" ]; then
echo "$download_url" >> $log_file
fi
fi
```
However, we don't have a good solution for the missing data issue caused by a successful download yet parser errors. In that case the next download won't include the older documents for re-parsing (yet).https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41069Unify the `start-$browser-browser` and the `$browser` scripts2024-01-25T14:34:45ZPier Angelo VendrameUnify the `start-$browser-browser` and the `$browser` scriptsCurrently, we ship two scripts: one is `start-tor-browser`/`start-mullvad-browser`, the other one is `firefox`/`mullvadbrowser`.
The reason seems to be related to the updater (passing the directory with the `libstdc++6` we ship to `LD_LI...Currently, we ship two scripts: one is `start-tor-browser`/`start-mullvad-browser`, the other one is `firefox`/`mullvadbrowser`.
The reason seems to be related to the updater (passing the directory with the `libstdc++6` we ship to `LD_LIBRARY_PATH` when needed).
However, some users might be launching `firefox` instead of `start-tor-browser` (or even worse, the actual binary - `firefox.real`!).
This is a risk, because they're missing home isolation and especially the fontconfig settings.
Could we do something to unify these scripts instead?
The first course of action would be to test Tor/Mullvad Browser (and the updater) in an old system, to trigger the need to use our libstdc++.https://gitlab.torproject.org/tpo/tpa/team/-/issues/41501retire individual grants in RT2024-01-25T03:44:00Zanarcatretire individual grants in RTin https://gitlab.torproject.org/tpo/tpa/team/-/issues/41496#note_2988546, @lavamind suggested we have a policy to only grant "groups" access and grant users access to those groups, to facilitate permissions management and auditing.
let...in https://gitlab.torproject.org/tpo/tpa/team/-/issues/41496#note_2988546, @lavamind suggested we have a policy to only grant "groups" access and grant users access to those groups, to facilitate permissions management and auditing.
let's do that.
@lavamind do you want this? or maybe @kez?https://gitlab.torproject.org/tpo/community/l10n/-/issues/40126Improve Access Keys documentation: explain difference to shortcuts2024-01-24T21:11:50ZemmapeelImprove Access Keys documentation: explain difference to shortcutsWe already have some documentation about Access Keys: https://gitlab.torproject.org/tpo/community/l10n/-/wikis/Localization-for-translators#access-keys
But it needs to be improved.
We need to differentiate Access Keys, that are a way t...We already have some documentation about Access Keys: https://gitlab.torproject.org/tpo/community/l10n/-/wikis/Localization-for-translators#access-keys
But it needs to be improved.
We need to differentiate Access Keys, that are a way to navigate menus, from keyboard shortcuts.
One difference: Shortcuts are the same for all locales, Access Keys depend on the locale.
ref: https://hosted.weblate.org/translate/tor/tor-browser/tb-newidentityproperties/ru/?checksum=73b4988ed95a84d9#commentshttps://gitlab.torproject.org/tpo/community/l10n-for-markdown/-/issues/1Document how to integrate with the translation repository2024-01-24T21:11:33ZSilvio RhattoDocument how to integrate with the translation repositoryDocument how this project can be used in an integrated workflow with the [translations repository](https://gitlab.torproject.org/tpo/translation), in accordance with the [Localization for developers](https://gitlab.torproject.org/tpo/com...Document how this project can be used in an integrated workflow with the [translations repository](https://gitlab.torproject.org/tpo/translation), in accordance with the [Localization for developers](https://gitlab.torproject.org/tpo/community/l10n/-/wikis/Localization-for-developers) document.https://gitlab.torproject.org/tpo/community/policies/-/issues/13Delete the master branch2024-01-24T21:10:23ZSilvio RhattoDelete the master branchThis branch was [phased out](tpo/community/policies#12). Next step is to remove it from GitLab after a while, giving time to people update their refs.This branch was [phased out](tpo/community/policies#12). Next step is to remove it from GitLab after a while, giving time to people update their refs.https://gitlab.torproject.org/tpo/community/training/-/issues/124Index of presentations in the home slide deck2024-01-24T21:10:16ZSilvio RhattoIndex of presentations in the home slide deckBuild an index of presentations in the [home slides]:
* Listing the ones from the current year, and the outdated ones.
* Linking to all available assets for a given slide (ODP, PDF, HTML etc).
* To be built as part of the CI Pipeline.
...Build an index of presentations in the [home slides]:
* Listing the ones from the current year, and the outdated ones.
* Linking to all available assets for a given slide (ODP, PDF, HTML etc).
* To be built as part of the CI Pipeline.
[home slides]: https://tpo.pages.torproject.net/community/training/https://gitlab.torproject.org/tpo/team/-/issues/1972024: Engineering Roadmap at all hands meeting2024-01-24T19:28:10ZGabagaba@torproject.org2024: Engineering Roadmap at all hands meetingprepare presentationprepare presentationhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40907Starting tor with --DormantOnFirstStartup doesn't set GETINFO dormant to 12024-01-24T19:08:12ZCrazyChaozStarting tor with --DormantOnFirstStartup doesn't set GETINFO dormant to 1### Summary
Starting tor with --DormantOnFirstStartup 1 on a new DataDirectory doesn't set GETINFO dormant to 1
### Steps to reproduce:
1. start tor with ```tor --DormantOnFirstStartup 1 --DataDirectory some-empty-dir```
2. do a ```GE...### Summary
Starting tor with --DormantOnFirstStartup 1 on a new DataDirectory doesn't set GETINFO dormant to 1
### Steps to reproduce:
1. start tor with ```tor --DormantOnFirstStartup 1 --DataDirectory some-empty-dir```
2. do a ```GETINFO dormant```
### What is the current bug behavior?
GETINFO dormant returns 0, as if it weren't in dormant mode
### What is the expected behavior?
GETINFO dormant returns 1, as it is in dormant mode
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
- 0.4.6.10 and 0.4.5.10
- Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc.
- Pop!_OS 22.04 and Ubuntu 18.04.6
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.
- apt and ?Tor: 0.4.9.x-freezehttps://gitlab.torproject.org/tpo/core/arti/-/issues/1205code duplication between FsStateMgr and state_dir (!1853)2024-01-24T19:03:05ZIan Jacksoniwj@torproject.orgcode 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 MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1096Implement descriptor publisher status function2024-01-24T18:49:04Zgabi-250Implement descriptor publisher status functionWe need to implement `Publish::status()` (which returns the current status of the publisher) and add a function that returns a stream of status change events (this might be needed for #1083).We need to implement `Publish::status()` (which returns the current status of the publisher) and add a function that returns a stream of status change events (this might be needed for #1083).Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/135Refactor code from onbrisca to onbasca2024-01-24T11:55:05ZjugaRefactor code from onbrisca to onbascajugajugahttps://gitlab.torproject.org/tpo/network-health/margot/-/issues/43If a relay has no family we should omit it or put the relay's fingerprint in it2024-01-24T11:53:44ZGeorg KoppenIf a relay has no family we should omit it or put the relay's fingerprint in itCurrently, if a relay has no family declared we get something like:
```
[+] Nickname: hhrtQKEYrhnSTpg3QNJ
> Fingerprint: Rsa: $0262871FEE026971C86BD7264D6D0482CEE29671, Ed: UaK9ZRTwYyo7cEo5yJGjrex12+Ne8NRQe5GGnjN5/9g
> Flags: RelayFl...Currently, if a relay has no family declared we get something like:
```
[+] Nickname: hhrtQKEYrhnSTpg3QNJ
> Fingerprint: Rsa: $0262871FEE026971C86BD7264D6D0482CEE29671, Ed: UaK9ZRTwYyo7cEo5yJGjrex12+Ne8NRQe5GGnjN5/9g
> Flags: RelayFlags(RUNNING | VALID | V2DIR)
> Weight: Unmeasured(20)
> Version: 0.4.7.14
> ORPort(s): 208.115.225.74:443
> IPv4 Policy: reject 1-65535
> IPv6 Policy: reject 1-65535
> Family:
```
when doing the `margot find` command. `Family: ` is not super informative. Instead we could just omit the family entry altogether if there is no family configured. That would save space while conveying the same info. Less preferred we could put the relay's fingerprint in that field instead.jugajugahttps://gitlab.torproject.org/tpo/network-health/team/-/issues/311Gather baseline metrics for bandwidth lying detection2024-01-24T11:52:23ZGeorg KoppenGather baseline metrics for bandwidth lying detectionIn order to estimate how we are able to reduce bandwidth lying through the course of our Sponsor 112 project we need to get a baseline or the status quo first. This ticket is tracking that work.In order to estimate how we are able to reduce bandwidth lying through the course of our Sponsor 112 project we need to get a baseline or the status quo first. This ticket is tracking that work.jugajuga