The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-09-08T15:18:27Zhttps://gitlab.torproject.org/tpo/core/arti/-/issues/54Start using sementic versioning2021-09-08T15:18:27ZNick MathewsonStart using sementic versioningWe should start using semver on arti, once we have a package we're willing to declare has a supported API.We should start using semver on arti, once we have a package we're willing to declare has a supported API.Arti 0.0.1 release: basic anonymityhttps://gitlab.torproject.org/tpo/core/arti/-/issues/52Add a test framework for the path selection algorithm2021-09-08T15:15:27ZLunarAdd a test framework for the path selection algorithm`DirPathBuilder.pick_path` and `ExitPathBuilder.pick_path` currently lack tests. Ideally, we would want to add some way to test these methods against various network topology and check the selected paths.
What I thought of, so far:
- mo...`DirPathBuilder.pick_path` and `ExitPathBuilder.pick_path` currently lack tests. Ideally, we would want to add some way to test these methods against various network topology and check the selected paths.
What I thought of, so far:
- mock DirInfo and most of the objects it references,
- create a consensus document from a human readable description of the network and then parse it into a DirInfo,
- instantiate a full DirInfo using code to help us do that.
The [testing category on crates.io](https://crates.io/categories/development-tools::testing) is worth investigating.
Anyway, this issue is mostly for collecting ideas for now, so if you have any, or even a suggestion of what should be done exactly, let's hear it. :)Arti 0.0.1 release: basic anonymityhttps://gitlab.torproject.org/tpo/core/arti/-/issues/51Circmgr needs a background job that removes too-dirty circuits2021-08-19T15:43:34ZNick MathewsonCircmgr needs a background job that removes too-dirty circuitsRight now circmgr only removes prunes its circuits when it's asked for one. Instead, this should happen on a timer, so we don't keep dirty circuits open indefinitely until nobody wants a circuit.Right now circmgr only removes prunes its circuits when it's asked for one. Instead, this should happen on a timer, so we don't keep dirty circuits open indefinitely until nobody wants a circuit.Arti 0.0.1 release: basic anonymityhttps://gitlab.torproject.org/tpo/core/arti/-/issues/43Make sure that a circuit doesn't use relays in the same family2021-08-05T19:18:35ZNick MathewsonMake sure that a circuit doesn't use relays in the same familyMoved from #28.
To do this:
- [x] Start by implementing a "same-family?" predicate in tor-netdir, probably as a method for the Relay type.
- [x] Then use this predicate in tor-circmgr/path/exitpath.rs.
- [x] Implement something...Moved from #28.
To do this:
- [x] Start by implementing a "same-family?" predicate in tor-netdir, probably as a method for the Relay type.
- [x] Then use this predicate in tor-circmgr/path/exitpath.rs.
- [x] Implement something like the `EnforceDistinctSubnets` feature from C tor.Arti 0.0.1 release: basic anonymityhttps://gitlab.torproject.org/tpo/web/support/-/issues/251Train moderators for the Tor's forum2021-09-04T17:02:27ZGabagaba@torproject.orgTrain moderators for the Tor's forumTrain the group of moderators for the forum.Train the group of moderators for the forum.Launch support's Forum and Blog migrationhttps://gitlab.torproject.org/tpo/web/support/-/issues/249Recruit community moderators2021-09-04T17:01:57ZGabagaba@torproject.orgRecruit community moderatorsWe need to get a small group of volunteers to moderate the forum. This ticket will track the call for moderators.We need to get a small group of volunteers to moderate the forum. This ticket will track the call for moderators.Launch support's Forum and Blog migration2021-09-30https://gitlab.torproject.org/tpo/community/l10n/-/issues/40050trigger website builds when translations change2021-11-16T16:40:09Zanarcattrigger website builds when translations changei have made the mirror of the translation repository between gitolite and gitweb (tpo/tpa/team#40497) which was necessary to have translated websites build correctly when translations get updated.
but that's not enough: we also need som...i have made the mirror of the translation repository between gitolite and gitweb (tpo/tpa/team#40497) which was necessary to have translated websites build correctly when translations get updated.
but that's not enough: we also need some GitLab CI logic here to trigger the right build when the right branch gets pushed. i don't quite know how to do this, because i'm not sure what the logic is.
@emmapeel could you clarify the spec here? is that some workflow thing like what we used to have in the gitlab-ci.yml? something like this:
```
workflow:
rules:
- if: $CI_PROJECT_NAME == "support"
variables:
TRANSLATION_BRANCH: "support-portal"
- if: $CI_PROJECT_NAME == "manual"
variables:
TRANSLATION_BRANCH: "tbmanual-contentspot"
- if: $CI_PROJECT_NAME == "community"
variables:
TRANSLATION_BRANCH: "communitytpo-contentspot"
- if: $CI_PROJECT_NAME == "tpo"
variables:
TRANSLATION_BRANCH: "tpo-web"
```
... but in reverse, that is a logic like: "if we are on branch support-portal, trigger the support build"? not sure how that would actually work in the yaml file... maybe with a variable?
something like this maybe?
```
workflow:
rules:
- if: $CI_COMMIT_REF_NAME == "support-portal"
variables:
TRIGGER_PROJECT: "tpo/web/support"
deploy:
stage: deploy
trigger: $TRIGGER_PROJECT
```
![image](/uploads/6455a5c40bc5f0e91a64205be331f71e/image.png)Retire Jenkinsemmapeelemmapeelhttps://gitlab.torproject.org/tpo/web/newsletter/-/issues/22newsletter.torproject.org: migrate from Jenkins to GitLab CI2021-11-04T01:46:42Zanarcatnewsletter.torproject.org: migrate from Jenkins to GitLab CI* [x] include ci-templates `lektor.yml` job
* [x] site builds and works in gitlab pages
* [x] [add the deploy-static job and SSH key to GitLab CI](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/static-shim#deploying-a-static-...* [x] include ci-templates `lektor.yml` job
* [x] site builds and works in gitlab pages
* [x] [add the deploy-static job and SSH key to GitLab CI](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/static-shim#deploying-a-static-site-from-gitlab-ci)
* [x] [deploy the SSH key and static site in Puppet](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/static-shim#adding-a-new-static-site-shim-in-puppet)
* [x] run the deploy-static job, make sure the site still works and was deployed properly (`curl -sI https://example.torproject.org/ | grep -i Last-Modified`)
* [x] [archive the repo on gitolite](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/gitlab/#how-to-migrate-a-git-repository-from-legacy-to-gitlab)
* [x] remove the old site on staticiforme
* [x] [fully retire the Jenkins jobs](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/jenkins#removing-a-job)
[gitolite project](https://gitweb.torproject.org/project/web/dev.git/)Retire Jenkinshttps://gitlab.torproject.org/tpo/web/team/-/issues/14protect branches on production websites2021-11-08T18:14:02Zanarcatprotect branches on production websitesi noticed i was able to push to the default branch on tb-manual on gitlab. now that we migrated to gitolite, we should protect those branches so that a proper review process is enforced before pushing.
/cc @emmapeel @kez @lavamindi noticed i was able to push to the default branch on tb-manual on gitlab. now that we migrated to gitolite, we should protect those branches so that a proper review process is enforced before pushing.
/cc @emmapeel @kez @lavamindRetire Jenkinshttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40502establish staging workflow for static sites in GitLab CI2021-11-03T19:52:30Zanarcatestablish staging workflow for static sites in GitLab CIin the rush migration surrounding #40501, we moved the main prod websites, but not the staging sites. figure out how those work in GitLab CI and migrate them.in the rush migration surrounding #40501, we moved the main prod websites, but not the staging sites. figure out how those work in GitLab CI and migrate them.Retire Jenkinshttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40465dev.torproject.org: migrate from Jenkins to GitLab CI2021-11-03T19:53:36Zanarcatdev.torproject.org: migrate from Jenkins to GitLab CIRetire Jenkinshttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40463newsletter.torproject.org: migrate from Jenkins to GitLab CI2021-11-03T19:53:01Zanarcatnewsletter.torproject.org: migrate from Jenkins to GitLab CIRetire Jenkinshttps://gitlab.torproject.org/tpo/core/tor/-/issues/40384move doxygen docs to GitLab CI or deprecate2021-08-30T17:59:27Zanarcatmove doxygen docs to GitLab CI or deprecatein tpo/tpa/team#40225, i was asked to "remove or disable Tor jenkins builders". while doing that, I noticed that doxgen docs are not currently build in a known location in GitLab CI:
https://src-ref.docs.torproject.org/tor/index.html
s...in tpo/tpa/team#40225, i was asked to "remove or disable Tor jenkins builders". while doing that, I noticed that doxgen docs are not currently build in a known location in GitLab CI:
https://src-ref.docs.torproject.org/tor/index.html
so retiring those would mean leaving that stale website in place for the foreseeable future.
could you move that to GitLab CI and GitLab pages? the following should get you started:
https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/gitlab/#publishing-gitlab-pages
if not, do let me know what's your blocker. i *believe* the resulting URL for core tor would be:
https://tpo.pages.torproject.net/core/tor/
once that is done we can retire the jenkins job, and then provide a redirect to the gitlab pages.
makes sense?Retire JenkinsAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40030update geoip db2022-02-14T18:16:28Zmeskiomeskio@torproject.orgupdate geoip dbBridgeDB uses maxminddb to get a mapping between IPs and countries, but this DB is not updated anymore. We should use the tor-geoipdb, which will be kept updated.
BridgeDB implements it's own [parser for the maxminddb](https://gitlab.to...BridgeDB uses maxminddb to get a mapping between IPs and countries, but this DB is not updated anymore. We should use the tor-geoipdb, which will be kept updated.
BridgeDB implements it's own [parser for the maxminddb](https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/blob/main/bridgedb/geo.py), we'll need to update it to the tor-geoipdb format.
For some context on the tor move away of maxminddb: https://gitlab.torproject.org/tpo/core/tor/-/issues/40224Sponsor 30 - Objective 2.455abhilash55abhilashhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40010Get more private bridges2021-08-03T16:34:46ZCecylia BocovichGet more private bridgesWe maintain a list of private bridges that we distribute to NGOs and individuals in places that block most of our other distribution methods. BridgeDB sets aside some bridges for private distribution in the "unallocated" or "reserved" po...We maintain a list of private bridges that we distribute to NGOs and individuals in places that block most of our other distribution methods. BridgeDB sets aside some bridges for private distribution in the "unallocated" or "reserved" pool.
At the end of March we are losing some private bridges that volunteers run so we need a few actions to get more private (stable if possible) bridges:
- [ ] Create and document a pipeline for distributing "unallocated" bridges as private bridges. We should document a pipeline for taking bridges the reserved this pool and getting them into the hands of users. (cohosh)
- [ ] Ask organizations to run obfs4 bridges (gus)
- [ ] Check with the donated hw we may get (gaba)Sponsor 30 - Objective 2.4https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31878Make BridgeDB and bridge authority more resilient2020-11-20T18:46:03ZPhilipp Winterphw@torproject.orgMake BridgeDB and bridge authority more resilientWe should explore options to decentralise BridgeDB and/or our bridge authority.We should explore options to decentralise BridgeDB and/or our bridge authority.Sponsor 30 - Objective 2.4https://gitlab.torproject.org/tpo/tpa/team/-/issues/40399update the budget for 2021-20222021-10-19T17:34:29Zanarcatupdate the budget for 2021-2022totally forgot about this, but we have a budget. it's currently in "Budget Sysadmin.xls" in the sysadmin share, but I think it should be folded inside the Tor VM spreadsheet to (a) get more visibility and (b) get some automatic calculati...totally forgot about this, but we have a budget. it's currently in "Budget Sysadmin.xls" in the sysadmin share, but I think it should be folded inside the Tor VM spreadsheet to (a) get more visibility and (b) get some automatic calculations done, because the latter spreadsheet already has the per-server cost.
we need to:
- [x] merge the budget and Tor VM Hosts.xlsx spreadsheets so that we have all numbers in one place
- [x] ask sue for up to date numbers on our "income" (how much money we have to spend), "expenses" (how much we're spending, particularly in Riseup and Hetzner, but basically eveyrthing)
- [x] update spreadsheet based on sue's numbers
- [x] ~~establish what our emergency buffer is~~ it's basically: just ask for approval
- [ ] plan for expansion in the next year (this needs coordination with the roadmap work, see tpo/tpa/team#40307 and others)establish the 2022 roadmapanarcatanarcathttps://gitlab.torproject.org/tpo/core/tor/-/issues/40430Modify default torrc text for PublishServerDescriptor2021-07-08T18:19:04ZCecylia BocovichModify default torrc text for PublishServerDescriptorIn the default torrc file, we see:
```
## By default, Tor will advertise your bridge to users through various
## mechanisms like https://bridges.torproject.org/. If you want to run
## a private bridge, for example because you'll give out...In the default torrc file, we see:
```
## By default, Tor will advertise your bridge to users through various
## mechanisms like https://bridges.torproject.org/. If you want to run
## a private bridge, for example because you'll give out your bridge
## address manually to your friends, uncomment this line:
#PublishServerDescriptor 0
```
However, we've noticed that some default Tor and Orbot bridges are not publishing their descriptors and therefore we aren't getting any metrics from them. This is exactly the use-case that `BridgeDistribution none` was meant to handle. In general, we recommend that people running private (or default) bridges that aren't meant for BridgeDB to configure their torrc file to have:
```
PublishServerDescriptor 1
BridgeDistribution none
```
See also the text in the torrc manpage for `PublishServerDescriptor`:
```
PublishServerDescriptor 0|1|v3|bridge,...
This option specifies which descriptors Tor will publish when acting as a relay. You
can choose multiple arguments, separated by commas.
If this option is set to 0, Tor will not publish its descriptors to any directories.
(This is useful if you’re testing out your server, or if you’re using a Tor controller
that handles directory publishing for you.) Otherwise, Tor will publish its descriptors
of all type(s) specified. The default is "1", which means "if running as a relay or
bridge, publish descriptors to the appropriate authorities". Other possibilities are
"v3", meaning "publish as if you’re a relay", and "bridge", meaning "publish as if
you’re a bridge".
```
I think we should change the default torrc text to match the manpage and say something to the effect of "if you want to, you can avoid publishing your descriptors, but we recommend that you do and that you set `BridgeDistribution none` if you don't want your bridge distributed over BridgeDB. That way we can collect metrics."Tor: 0.4.7.x-freezehttps://gitlab.torproject.org/tpo/tpa/team/-/issues/403072022 user survey2021-10-19T17:31:28Zanarcat2022 user surveyin #40061, we did a user survey, and that was a great tool to establish the 2021 roadmap (#40105). we should do that again, and sooner than later.
note also the data processing ticket (#40106)in #40061, we did a user survey, and that was a great tool to establish the 2021 roadmap (#40105). we should do that again, and sooner than later.
note also the data processing ticket (#40106)establish the 2022 roadmapanarcatanarcat2021-12-01https://gitlab.torproject.org/tpo/core/tor/-/issues/40352Nonauthoritative directory does not accept posted server descriptors2021-10-19T12:31:25ZTommaso GragnatoNonauthoritative directory does not accept posted server descriptors```[WARN] http status 400 ("Nonauthoritative directory does not accept posted server descriptors") response from dirserver 185.107.47.215:9001. Malformed rendezvous descriptor? [6 duplicates hidden]```
I suspect this is because [185.107...```[WARN] http status 400 ("Nonauthoritative directory does not accept posted server descriptors") response from dirserver 185.107.47.215:9001. Malformed rendezvous descriptor? [6 duplicates hidden]```
I suspect this is because [185.107.47.215](https://metrics.torproject.org/rs.html#details/45E9240AD4ECE01793A1977C1260503B2C2C861F) is running 0.4.6 alpha and does not understand descriptors for v2 onions. Hence the 400.
https://gitlab.torproject.org/tpo/core/tor/-/issues/40266#note_2724898
Should this be handled gracefully? What's the phase out plan?Tor: 0.4.7.x-freeze