The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-02-29T19:10:43Zhttps://gitlab.torproject.org/tpo/onion-services/onionspray/-/issues/16Codebase cleanup2024-02-29T19:10:43ZSilvio RhattoCodebase cleanup# Tasks
* [ ] Cleanup the codebase, removing old/unused code.
# Time estimation
* Complexity: small (1 day)
* Uncertainty: low (x1.1)
* [Reference](https://jacobian.org/2021/may/25/my-estimation-technique/) (adapted)# Tasks
* [ ] Cleanup the codebase, removing old/unused code.
# Time estimation
* Complexity: small (1 day)
* Uncertainty: low (x1.1)
* [Reference](https://jacobian.org/2021/may/25/my-estimation-technique/) (adapted)Onionspray 1.7.0Silvio RhattoSilvio Rhatto2024-06-27https://gitlab.torproject.org/tpo/onion-services/onionspray/-/issues/12Upstream pull requests triage2024-02-29T19:10:43ZSilvio RhattoUpstream pull requests triage# Tasks
* [x] Triage [upstream pull requests](https://github.com/alecmuffett/eotk/pulls).
* [ ] Import those relevant to be incorporated (as just tickets and optionally merge requests).
* [ ] Add a comment to upstream merge requests poi...# Tasks
* [x] Triage [upstream pull requests](https://github.com/alecmuffett/eotk/pulls).
* [ ] Import those relevant to be incorporated (as just tickets and optionally merge requests).
* [ ] Add a comment to upstream merge requests pointing to the imported tickets/merge requests. If just a ticket was important, ask the contributor whether they're interesting in doing a rebase and submitting as an Onionspray patch.
# 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.7.0Silvio RhattoSilvio Rhatto2024-06-27https://gitlab.torproject.org/tpo/onion-services/onionspray/-/issues/11Upstream issue triage2024-02-29T19:10:43ZSilvio RhattoUpstream issue triage# Tasks
* [ ] Triage [upstream issues](https://github.com/alecmuffett/eotk/issues).
* [ ] Importing here those relevant to be implemented/fixed (as tickets).
* [ ] Add a comment to upstream issues pointing to the imported ones.
# Time ...# Tasks
* [ ] Triage [upstream issues](https://github.com/alecmuffett/eotk/issues).
* [ ] Importing here those relevant to be implemented/fixed (as tickets).
* [ ] Add a comment to upstream issues pointing to the imported ones.
# 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.7.0Silvio RhattoSilvio Rhatto2024-06-27https://gitlab.torproject.org/tpo/tpa/team/-/issues/41219migrate TPA's gitolite repositories to GitLab2024-03-28T20:24:38Zanarcatmigrate TPA's gitolite repositories to GitLabWe have decided to retire Gitolite in #41180, give the good example and migrate our repos to GitLab. This is the table established in TPA-RFC-36:
| Repository | data | Problem ...We have decided to retire Gitolite in #41180, give the good example and migrate our repos to GitLab. This is the table established in TPA-RFC-36:
| Repository | data | Problem | Fate |
|-------------------------------|--------------------------------------|-------------------------------------|----------------------------------|
| `account-keyring` | OpenPGP keyrings | hooks into the static mirror system | convert to GitLab CI |
| `buildbot-conf` | old buildbot config? | obsolete | archive |
| `dip` | GitLab ansible playbooks? | duplicate of `services/gitlab/dip`? | archive? |
| `dns/auto-dns` | DNS zones source used by LDAP server | security | check OpenPGP signatures |
| `dns/dns-helpers` | DNSSEC generator used on DNS master | security | check OpenPGP signatures |
| `dns/domains` | DNS zones source used by LDAP server | security | check OpenPGP signatures |
| `dns/mini-nag` | monitoring on DNS primary | security | check OpenPGP signatures |
| `letsencrypt-domains` | TLS certificates generation | security | move to Puppet? |
| `puppet/puppet-ganeti` | puppet-ganeti fork | misplaced | destroy |
| `services/gettor` | ansible playbook for gettor | obsolete | archive |
| `services/gitlab/dip-configs` | GitLab ansible playbooks? | obsolete | archive |
| `services/gitlab/dip` | GitLab ansible playbooks? | duplicate of `dip`? | archive? |
| `services/gitlab/ldapsync` | LDAP to GitLab script, unused | obsolete | archive |
| `static-builds` | Jenkins static sites build scripts | obsolete | archive |
| `tor-jenkins` | Jenkins build scripts | obsolete | archive |
| `tor-nagios` | Icinga configuration | confidentiality? | abolish? see also [TPA-RFC-33][] |
| `tor-passwords` | password manager | confidentiality | migrate? |
| `tor-virt` | libvirt VM configuration | obsolete | destroy |
| `trac/TracAccountManager` | Trac tools | obsolete | archive |
| `trac/trac-email` | Trac tools | obsolete | archive |
| `tsa-misc` | miscellaneous scripts | none | migrate |
| `userdir-ldap-cgi` | fork of DSA's repository | none | migrate |
| `userdir-ldap` | fork of DSA's repository | none | migrate |
Update: we don't have the free cycles to do the right thing here and we're instead going to move to GitLab only the repositories that do not require special handling, that is: repositories that are `archive` or `migrate`. Everything else will be moved to special servers while we figure out what to do with that legacy stuff.
- [x] `account-keyring` (destroy, only use the copy on `alberti`)
- [ ] `buildbot-conf` (archive)
- [ ] `dip` (archive?)
- [x] `dns/auto-dns` (migrate to `nevii`)
- [x] `dns/dns-helpers` (migrate to `nevii`)
- [x] `dns/domains` (migrate to `nevii`)
- [x] `dns/mini-nag` (migrate to `nevii`)
- [x] `letsencrypt-domains` (migrate to `nevii`)
- [x] `puppet/puppet-ganeti` (destroy)
- [ ] `services/gettor` (archive)
- [ ] `services/gitlab/dip-configs` (archive)
- [ ] `services/gitlab/dip` (archive?)
- [ ] `services/gitlab/ldapsync` (archive)
- [ ] `static-builds` (archive)
- [ ] `tor-jenkins` (archive)
- [x] `tor-nagios` (move to `nagios`, see also [TPA-RFC-33][], #40755)
- [x] `tor-passwords` (move to `pauli`)
- [x] `tor-virt` (destroy)
- [ ] `trac/TracAccountManager` (archive)
- [ ] `trac/trac-email` (archive)
- [x] `tsa-misc` (migrate, renamed to `fabric-tasks`)
- [x] `userdir-ldap-cgi` (migrate)
- [x] `userdir-ldap` (migrate)
[TPA-RFC-33]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-33-monitoring
The repositories that were migrated to pauli, nevii or nagios need special configuration to get notifications working again. it would also be pretty awesome if they could push to a mirror on GitLab. Finally, they need docs. So extras in the checklist for those repos:
- [ ] IRC notifications
- [ ] email notifications
- [ ] documentation updates (particularly howto/tls, howto/dns is barely documented...)
- [ ] GitLab mirror (optional)legacy Git infrastructure retirement (TPA-RFC-36)anarcatanarcat2024-01-17https://gitlab.torproject.org/tpo/tpa/team/-/issues/41218retire vineale2024-03-26T20:51:39Zanarcatretire vinealeOnce all lagacy Git repositories have been migrated to GitLab (#41215) and the redirections moved to the static mirror system (#41216), retire `vineale`.Once all lagacy Git repositories have been migrated to GitLab (#41215) and the redirections moved to the static mirror system (#41216), retire `vineale`.legacy Git infrastructure retirement (TPA-RFC-36)2024-06-08https://gitlab.torproject.org/tpo/tpa/team/-/issues/41217retire cupani2024-03-26T20:48:47Zanarcatretire cupaniOnce all lagacy Git repositories have been migrated to GitLab (#41215), retire cupani.Once all lagacy Git repositories have been migrated to GitLab (#41215), retire cupani.legacy Git infrastructure retirement (TPA-RFC-36)anarcatanarcat2024-04-24https://gitlab.torproject.org/tpo/tpa/team/-/issues/41216move legacy git redirections to the static mirror infrastructure2024-03-27T15:29:01Zanarcatmove legacy git redirections to the static mirror infrastructureOnce all lagacy Git repositories have been migrated to GitLab (#41215), the redirections can be moved from gitweb (`vineale`) to the static mirror system.Once all lagacy Git repositories have been migrated to GitLab (#41215), the redirections can be moved from gitweb (`vineale`) to the static mirror system.legacy Git infrastructure retirement (TPA-RFC-36)2024-03-08https://gitlab.torproject.org/tpo/tpa/team/-/issues/41215forcibly migrate remaining Gitolite repositories to GitLab2024-03-26T20:51:17Zanarcatforcibly migrate remaining Gitolite repositories to GitLabAs part of the Gitolite retirement procedure (TPA-RFC-36, #41180), migrate remaining repositories from Gitolite to GitLab.
The goal is to complete this from within 12 months of the announcement, or 3 months from the original due date of...As part of the Gitolite retirement procedure (TPA-RFC-36, #41180), migrate remaining repositories from Gitolite to GitLab.
The goal is to complete this from within 12 months of the announcement, or 3 months from the original due date of this ticket, that is, before 2024-06-08, at which point the servers are supposed to be retired.
The actual list of repositories to migrate should probably be added here and users warned about the impeding change one last time. An inventory will have previously been made in #41214.
In TPA-RFC-36, the following was established:
> ## Per-repository particularities
>
> This section documents the fate of some repositories we are aware
> of. If you can think of specific changes that need to happen to
> repositories that are unusual, please do report them to TPA so they
> can be included in this proposal.
>
> ### idle repositories
>
> Repositories that did not have any new commit in the last two years
> are considered "idled" and should be migrated or archived to GitLab by
> their owners. Failing that, TPA will *archive* the repositories in the
> GitLab `legacy/` namespace before final deadline.
>
> ### user repositories
>
> There are 358 repositories under the `user/` namespace, owned by 70
> distinct users.
>
> Those repositories must be migrated to their corresponding user on the
> GitLab side.
>
> If the Gitolite user does not have a matching user on GitLab, their
> repositories will be moved under the `legacy/gitolite/user/` namespace
> in GitLab, owned by the GitLab admin doing the migration.
>
> ### "mirror" and "extern" repositories
>
> Those repositories will be migrated to, and archived in, GitLab within
> a month of the adoption of this proposal.
>
> ### Applications team repositories
>
> [See tpo/tpa/team#41181.]
So, as a task list, per repos:
- [ ] 5 `mirror` or `extern` (migrate and archive)
- [ ] 12 TPA (see #41219)
- [x] 49 migrated
- [ ] 87 `Attic` (migrate and archive)
- [ ] 97 `Other` (migrate, archive "idle" repositories)
- [ ] 288 `user` (migrate and archive)
See https://gitlab.torproject.org/tpo/tpa/team/-/issues/41214#note_2983291 for how those numbers were established.legacy Git infrastructure retirement (TPA-RFC-36)2024-03-08https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/98Investigate push-signing and transparency logs as mitigation for repository a...2024-03-27T15:21:35ZNick MathewsonInvestigate push-signing and transparency logs as mitigation for repository attacksFor background see:
* https://people.kernel.org/monsieuricon/signed-git-pushes
* https://korg.docs.kernel.org/gitolite/transparency-log.html
The idea here would be that some repositories (eg tor.git) could require signed _pushes_. Th...For background see:
* https://people.kernel.org/monsieuricon/signed-git-pushes
* https://korg.docs.kernel.org/gitolite/transparency-log.html
The idea here would be that some repositories (eg tor.git) could require signed _pushes_. Then we could archive these signed pushes in an append-only log, for auditing.
There are subproblems that would need to be solved for this to work:
* Only allow signed pushes on certain repositories (would require a per-repository gitolite hook).
* Allow signed pushes (requires setting certain options in gitconfig, see `certNonceSeed`, `certNonceSlop`, and `advertisePushOptions`)
* Make an append-only log of these signed pushes (possibly using trillian, possibly using some simpler transparency-log tool).
* Make a tool to audit this log and make sure that it's consistent and that it generates the current state of the repository.
* Decide what to do about key management.
And possibly:
* Make a tool that can be used at pull time to check the latest branch against the log.
There are also some sub-sub problems:
* Can we disable the merge button on target repositories?legacy Git infrastructure retirement (TPA-RFC-36)https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/82Create an Onionprobe release on new tags2024-03-27T21:44:40ZSilvio RhattoCreate an Onionprobe release on new tagsCreate a [GitLab release](https://docs.gitlab.com/ee/user/project/releases/) automatically [when a tag is pushed to the repo](https://docs.gitlab.com/ee/user/project/releases/release_cicd_examples.html#create-a-release-when-a-git-tag-is-...Create a [GitLab release](https://docs.gitlab.com/ee/user/project/releases/) automatically [when a tag is pushed to the repo](https://docs.gitlab.com/ee/user/project/releases/release_cicd_examples.html#create-a-release-when-a-git-tag-is-created).Onionprobe 1.2.0Silvio RhattoSilvio Rhatto2024-05-16https://gitlab.torproject.org/tpo/onion-services/oniongroove/-/issues/5Vendorize Onion MkDocs2024-03-27T21:47:27ZSilvio RhattoVendorize Onion MkDocsVendorize [Onion MkDocs](https://gitlab.torproject.org/rhatto/onion-mkdocs), so it's easier to retrieve updates.Vendorize [Onion MkDocs](https://gitlab.torproject.org/rhatto/onion-mkdocs), so it's easier to retrieve updates.Oniongroove 0.1.0Silvio RhattoSilvio Rhatto2024-05-16https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/80Enhanced Grafana dashboard2024-03-27T21:45:05ZSilvio RhattoEnhanced Grafana dashboardEnhance the sample [exportable](https://grafana.com/docs/grafana/latest/dashboards/export-import/) Grafana Dashboard for Onion Services monitoring, including:
* [ ] Lists of expiring X.509 certificates (next days/weeks/month/quarter; cu...Enhance the sample [exportable](https://grafana.com/docs/grafana/latest/dashboards/export-import/) Grafana Dashboard for Onion Services monitoring, including:
* [ ] Lists of expiring X.509 certificates (next days/weeks/month/quarter; current quarter; etc).
* [ ] Enhanced metrics from tpo/onion-services/onionprobe#78.Onionprobe 1.2.0Silvio RhattoSilvio Rhatto2024-05-16https://gitlab.torproject.org/tpo/onion-services/oniongroove/-/issues/4Oniongroove 0.1.0 release planning2024-03-27T21:47:14ZSilvio RhattoOniongroove 0.1.0 release planningPlan the [0.0.1 release](https://gitlab.torproject.org/tpo/onion-services/oniongroove/-/milestones/1).Plan the [0.0.1 release](https://gitlab.torproject.org/tpo/onion-services/oniongroove/-/milestones/1).Oniongroove 0.1.0Silvio RhattoSilvio Rhatto2024-05-16https://gitlab.torproject.org/tpo/onion-services/oniongroove/-/issues/3Oniongroove prototype2024-03-28T12:56:29ZSilvio RhattoOniongroove prototypeWrite an early prototype/proof of concept for Oniongroove.Write an early prototype/proof of concept for Oniongroove.Oniongroove 0.1.0Silvio RhattoSilvio Rhatto2024-05-16https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/78Enhanced metrics for Onion Service descriptors2024-03-27T21:44:54ZSilvio RhattoEnhanced metrics for Onion Service descriptorsImplement additional metrics for Onion Service descriptors.
That need:
* A better way to parse descriptors would enable many other metrics.
* Some patches sent upstream to Stem.
Some fields that could get measurements:
* From the out...Implement additional metrics for Onion Service descriptors.
That need:
* A better way to parse descriptors would enable many other metrics.
* Some patches sent upstream to Stem.
Some fields that could get measurements:
* From the outer descriptor wrapper:
* [ ] "descriptor-lifetime".
* [ ] "revision-counter".
* From the first layer of encryption:
* [ ] "[caa-critical](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/343-rend-caa.txt)".
* From the second layer of encryption:
* [ ] "single-onion-service".
* [ ] "pow-params": an indirect way to measure DoS for PoW-enabled
services (by measuring the PoW settings in the descriptor),
which depends on tpo/core/tor#40634 to be implemented.
* [ ] "[caa](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/343-rend-caa.txt)".
Other measurements:
* [ ] Metrics for the descriptor and inner layer sizes.Onionprobe 1.2.0Silvio RhattoSilvio Rhatto2024-05-16https://gitlab.torproject.org/tpo/onion-services/oniongroove/-/issues/2Oniongroove threat model2024-03-27T21:47:21ZSilvio RhattoOniongroove threat modelWrite initial version of [Oniongroove](https://gitlab.torproject.org/rhatto/oniongroove) threat model, including:
* [ ] Consider the scenario where someone run more than a single Onionbalance
"frontend" with the same address but w...Write initial version of [Oniongroove](https://gitlab.torproject.org/rhatto/oniongroove) threat model, including:
* [ ] Consider the scenario where someone run more than a single Onionbalance
"frontend" with the same address but with different backends and uploading
descriptors at different times. Would this:
* Impact the Tor network negativelly?
* Improve load balancing?
* Be an acceptable frontend failover?Oniongroove 0.1.0Silvio RhattoSilvio Rhatto2024-05-16https://gitlab.torproject.org/tpo/onion-services/oniongroove/-/issues/1Oniongroove deployment research2024-03-27T21:47:32ZSilvio RhattoOniongroove deployment researchResearch on all relevant deployment technologies (DevOps) for Onion Services: build a first matrix of technologies, recipes and strategies, incorporating it into the specs (onion-support#40).Research on all relevant deployment technologies (DevOps) for Onion Services: build a first matrix of technologies, recipes and strategies, incorporating it into the specs (onion-support#40).Oniongroove 0.1.0Silvio RhattoSilvio Rhatto2024-05-16https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/64Exit codes should reflect reality2024-03-27T21:44:24ZgeorgExit codes should reflect realityIt seems, onionprobe exits with `0` aka success in any case, while it should probably exit with `> 0` if things go wrong:
```
~ onionprobe -e test.onion; echo $? ...It seems, onionprobe exits with `0` aka success in any case, while it should probably exit with `> 0` if things go wrong:
```
~ onionprobe -e test.onion; echo $?
2022-07-23 12:52:30,170 INFO: Starting Onionprobe version 1.0.0...
2022-07-23 12:52:30,170 INFO: Initializing Tor process...
2022-07-23 12:52:32,145 INFO: Onionprobe is initialized. Hit Ctrl-C to interrupt it.
2022-07-23 12:52:32,145 INFO: Processing test.onion...
2022-07-23 12:52:32,145 ERROR: Invalid onion service address set for test.onion: test.onion
2022-07-23 12:52:32,146 INFO: Error while receiving a control message (SocketClosed): received exception "read of closed file"
2022-07-23 12:52:32,146 INFO: Error while receiving a control message (SocketClosed): received exception "peek of closed file"
2022-07-23 12:52:32,146 INFO: Error while receiving a control message (SocketClosed): received exception "peek of closed file"
2022-07-23 12:52:32,146 INFO: Error while receiving a control message (SocketClosed): received exception "peek of closed file"
2022-07-23 12:52:32,146 INFO: Error while receiving a control message (SocketClosed): received exception "peek of closed file"
2022-07-23 12:52:32,146 INFO: Error while receiving a control message (SocketClosed): received exception "peek of closed file"
0
```Onionprobe 1.2.0Silvio RhattoSilvio Rhatto2024-05-16https://gitlab.torproject.org/tpo/applications/vpn/-/issues/152improve bridge selection UX2024-03-28T13:48:16Zcybertaimprove bridge selection UXthere are a couple of issues with the current implementation
* after the bridge bot was selected, any manual selection for built-in bridges need to be unset in the UI
* only request obfs4 bridges from bridgeDB (wrapped in the circumventi...there are a couple of issues with the current implementation
* after the bridge bot was selected, any manual selection for built-in bridges need to be unset in the UI
* only request obfs4 bridges from bridgeDB (wrapped in the circumvention API) instead of snowflake + obfs4VPN pre-alpha 07https://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 07