The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-02-06T19:19:09Zhttps://gitlab.torproject.org/tpo/community/relays/-/issues/84Tor relay operator meetup (2024-01-27 at 1900 UTC)2024-02-06T19:19:09ZGusTor relay operator meetup (2024-01-27 at 1900 UTC)
* [x] Put together an agenda with the contribution of other teams and relay op community
* [x] BBB room - https://tor.meet.coop/gus-og0-x74-dzn
* [x] Publish the meetup invitation where our community hangout:
* [x] tor-relays mailing ...
* [x] Put together an agenda with the contribution of other teams and relay op community
* [x] BBB room - https://tor.meet.coop/gus-og0-x74-dzn
* [x] Publish the meetup invitation where our community hangout:
* [x] tor-relays mailing list: https://forum.torproject.org/t/tor-relays-next-tor-relay-operator-meetup-2024-01-27-19-00-utc/11159
* [x] Twitter
* [x] Mastodon
* [x] r/TOR
* [x] Facilitate the meetup (Saturday, January 27th @ 1900 UTC)
* [x] Send the meetup notes to the tor-relays mailing listGusGushttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41475Reset password on forum.torproject.org2024-01-18T15:07:53ZboyskaReset password on forum.torproject.orgHello!
I have an account named `boyska` on forum.torproject.org. Unfortunately, I lost my password + everything related to 2FA (private key + backup codes).
What this means is that I cannot reset my password over email, because that wil...Hello!
I have an account named `boyska` on forum.torproject.org. Unfortunately, I lost my password + everything related to 2FA (private key + backup codes).
What this means is that I cannot reset my password over email, because that will not only ask for a new password, but also 2FA authentication code (or backup codes).
Is there a way I will be able get back my access to that account?
I have already written a hundred times "I will do backups more often" on the blackboard, I swear!https://gitlab.torproject.org/tpo/tpa/prometheus-alerts/-/issues/14Send alert only once per hour for relays passing the nickname/contact info/fl...2024-01-17T15:44:04ZGeorg KoppenSend alert only once per hour for relays passing the nickname/contact info/flag thresholdsRight now those alerts do not have any `for` clause included which, if I understand the docs at https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/ correctly, triggers an alert in case the condition matches on any ...Right now those alerts do not have any `for` clause included which, if I understand the docs at https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/ correctly, triggers an alert in case the condition matches on any update. Having the alerts in question trigger a notification only once per hour seems to be the right thing to do given that we only get Onionoo updates once per hour anyway.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/team/-/issues/246SIDA request on more info2024-01-16T22:25:04ZGabagaba@torproject.orgSIDA request on more infoGabagaba@torproject.orgGabagaba@torproject.orghttps://gitlab.torproject.org/tpo/operations/team/-/issues/15SIDA request on more info2024-01-16T19:47:25ZGabagaba@torproject.orgSIDA request on more infoGabagaba@torproject.orgGabagaba@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/1247Rename OnionService/RunningOnionService2024-01-31T21:37:28Zgabi-250Rename OnionService/RunningOnionServiceWe need to pick better names for `OnionService` and/or `RunningOnionService` (the current naming is provisional, and comes from #1227)We need to pick better names for `OnionService` and/or `RunningOnionService` (the current naming is provisional, and comes from #1227)Arti: Onion service supportNick MathewsonNick Mathewsonhttps://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/core/arti/-/issues/1244Ensure that onion services are shut down when their handle is dropped.2024-01-29T20:52:10ZNick MathewsonEnsure that onion services are shut down when their handle is dropped.This is distinct from #1231 , though many of the notes there will apply.This is distinct from #1231 , though many of the notes there will apply.gabi-250gabi-250https://gitlab.torproject.org/tpo/team/-/issues/245Finish onboarding Bella2024-02-05T15:57:17ZGabagaba@torproject.orgFinish onboarding Bella- [x] Roles and expectations
- [x] Go over the rest of the projects (we only did sponsor 9 and 96)
- [x] 9
- [x] 96
- [x] 101
- [x] 112
- [x] 131
- [x] 144
- [x] 145
- [x] 149
- [x] 150
- [x] 152
- [x] Help her connec...- [x] Roles and expectations
- [x] Go over the rest of the projects (we only did sponsor 9 and 96)
- [x] 9
- [x] 96
- [x] 101
- [x] 112
- [x] 131
- [x] 144
- [x] 145
- [x] 149
- [x] 150
- [x] 152
- [x] Help her connect to irc.
- [x] Coordinate sync with bekeela, bella and me
- [x] Schedule the weekly syncs
- [x] Introduction metting with micah
- [ ] Review Labels
- [x] Add bella to the needed meetings in NC calendar.
- [x] Sync on all planning spreadsheet.
cc @bellaGabagaba@torproject.orgGabagaba@torproject.orghttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40074Onionperf conflux clients not producing metrics2024-01-25T14:22:51ZHiroOnionperf conflux clients not producing metricsIt seems something is failing on onionperf conflux clients
- op-hk8a-conflux
- op-de8a-conflux
- op-us8a-conflux
It seems this is happening since I have enlarged the disks.It seems something is failing on onionperf conflux clients
- op-hk8a-conflux
- op-de8a-conflux
- op-us8a-conflux
It seems this is happening since I have enlarged the disks.HiroHirohttps://gitlab.torproject.org/tpo/core/arti/-/issues/1242arti onion service fails after approx 12 hours2024-01-23T19:49:58ZStefani Banerianarti onion service fails after approx 12 hours### Summary
arti onion service start up fine, fails after approx 12 hours
### What is the current bug behavior?
configure onion service to simple nginx service, and ssh. initial connections work. after some hours, can no longer conne...### Summary
arti onion service start up fine, fails after approx 12 hours
### What is the current bug behavior?
configure onion service to simple nginx service, and ssh. initial connections work. after some hours, can no longer connect to onion services.
### What is the expected behavior?
onion services should be available without need to restart arti frequently
### Environment
- debian 12
- arti 1.1.12 git 7de5eb2e21
- rustc 1.75/cargo 1.75 features: onion-service, static
### Relevant logs and/or screenshots:
debug log
```
2024-01-12T13:18:08Z DEBUG tor_circmgr::mgr:circuit we're building sent error Channel { peer: OwnedChanTarget { addrs: [111.111.111.111:443], method: Direct([111.111.111.111:443]), ids: RelayIds { ed_identity: Some(Ed25519Identity { MMMMMMMMMMMMMMMMM }), rsa_identity: Some(RsaIdentity { $aaaaaaaaaaaaaaaaaaaaaaaaa }) } }, cause: Internal(Bug(BugRepr { message: "channel build task disappeared", location: Location { file: "/path/to/arti/crates/tor-chanmgr/src/mgr.rs", line: 229, col: 54 }, backtrace: Captured( 0: tor_error::internal::Bug::new_inner
1: tor_chanmgr::mgr::AbstractChanMgr<CF>::get_or_launch::{{closure}}
2: <tor_proto::circuit::ClientCirc as tor_circmgr::build::Buildable>::create_chantarget::{{closure}}
3: tor_circmgr::build::double_timeout::{{closure}}::{{closure}}
4: tokio::runtime::task::raw::poll
5: tokio::runtime::scheduler::multi_thread::worker::Context::run_task
6: tokio::runtime::task::raw::poll
7: tokio::runtime::task::UnownedTask<S>::run
8: std::sys_common::backtrace::__rust_begin_short_backtrace
9: core::ops::function::FnOnce::call_once{{vtable.shim}}
10: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/boxed.rs:2007:9
<alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/boxed.rs:2007:9
std::sys::unix::thread::Thread::new::thread_start
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys/unix/thread.rs:108:17
11: <unknown>
12: <unknown>
), source: None, kind: Internal })) }
```
### Possible fixes:
?gabi-250gabi-250https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40107metrics.torproject.org throws 503 Service Unavailable2024-01-15T08:34:19Ztrinity-1686ametrics.torproject.org throws 503 Service Unavailablemetrics.torproject.org is currently unavailable. Looks like it's been like that since around 2024-01-14T19:35:00Zmetrics.torproject.org is currently unavailable. Looks like it's been like that since around 2024-01-14T19:35:00ZGeorg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1227OnionService API questions2024-01-22T19:04:10Zgabi-250OnionService API questionsI think we will need to rethink the `OnionService` API a bit:
* we will need some way of stopping a running service (and presumably also the tasks spawned by `launch`). Even if we implemented `stop()`, restarting the stopped service w...I think we will need to rethink the `OnionService` API a bit:
* we will need some way of stopping a running service (and presumably also the tasks spawned by `launch`). Even if we implemented `stop()`, restarting the stopped service wouldn't be possible, because `launch()` consumes `unlaunched`
* the `onion_name()` function (that implements the `arti hss onion-name` command) needs to be moved to `OnionService`. Currently, to construct an `OnionService`, you need to provide some objects that aren't needed when building `OnionService` in the "unbootrapped", unlaunchable "CLI mode" (e.g. a `Runtime`, a `StateMgr`)
* @Diziet notes that one possibility would be to rewrite `OnionService` using the [typestate pattern](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1837#note_2977530)
cc @nickm @DizietArti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/tpa/team/-/issues/41470gitlab account takeover audit2024-01-22T16:13:39Zanarcatgitlab account takeover auditToday's GitLab release include a fix for a [full account takeover](https://about.gitlab.com/releases/2024/01/11/critical-security-release-gitlab-16-7-2-released/#account-takeover-via-password-reset-without-user-interactions) based on a f...Today's GitLab release include a fix for a [full account takeover](https://about.gitlab.com/releases/2024/01/11/critical-security-release-gitlab-16-7-2-released/#account-takeover-via-password-reset-without-user-interactions) based on a failed password reset mechanism.
This issue was introduced in GitLab 16.1, released on May 1, 2023. We need to verify whether this vulnerability was exploited on our server.anarcatanarcathttps://gitlab.torproject.org/tpo/team/-/issues/244SIDA: Review proposal for next year WITH the project's team2024-03-04T17:59:30ZGabagaba@torproject.orgSIDA: Review proposal for next year WITH the project's team@gus @raya @emmapeel @donuts We need to review the proposal we sent to SIDA for next year and send it BEFORE the end of January. I will send a mail to you all with the proposal.
cc @bella@gus @raya @emmapeel @donuts We need to review the proposal we sent to SIDA for next year and send it BEFORE the end of January. I will send a mail to you all with the proposal.
cc @bellabellabella@torproject.orgbellabella@torproject.org2024-02-29https://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/tpa/nextcloud/-/issues/25New folder 'Operations' for the operations team2024-01-17T16:07:35ZGabagaba@torproject.orgNew folder 'Operations' for the operations teamThe group 'fundraising' in nc got renamed as 'operations'. We want to create a folder for this team. It will be called 'Operations Team' and will include the 'Fundraising Team' and 'HR Team' folders.
Please create this new folder 'Oper...The group 'fundraising' in nc got renamed as 'operations'. We want to create a folder for this team. It will be called 'Operations Team' and will include the 'Fundraising Team' and 'HR Team' folders.
Please create this new folder 'Operations Team' and move the other folders into it.
Thanks!
cc @micah @lavamindJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/1209Reject inappropriate ipt_mgr configuration changes; Accept and implement the ...2024-02-21T14:59:44ZIan Jacksoniwj@torproject.orgReject inappropriate ipt_mgr configuration changes; Accept and implement the ones that we can.For example, changing the state_dir would result in terrible lossage. Some checks need to be added to the reconfigure logic.
MUST because unbounded lossage might result.
----
Expanding this ticket to note that there are also places w...For example, changing the state_dir would result in terrible lossage. Some checks need to be added to the reconfigure logic.
MUST because unbounded lossage might result.
----
Expanding this ticket to note that there are also places where we _could_ implement certain changes at runtime, but we do not. I will note those with `TODO #1209` as well. We can be flexible about what we implement now and what we forbid, but we should make sure that every change is either supported or forbidden.
—@nickmArti: Onion service supportIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41468Update torbrowser@torproject.org key in wkd2024-01-11T16:27:05ZboklmUpdate torbrowser@torproject.org key in wkdIt is possible to get the torbrowser gpg key with:
```
gpg --auto-key-locate nodefault,wkd --locate-keys torbrowser@torproject.org
```
The key that is returned by this needs to be updated for a new expiration date on the subkey. The up...It is possible to get the torbrowser gpg key with:
```
gpg --auto-key-locate nodefault,wkd --locate-keys torbrowser@torproject.org
```
The key that is returned by this needs to be updated for a new expiration date on the subkey. The updated key is:
https://people.torproject.org/~boklm/tmp/_torbrowser_extended_202401.asc
Updated key should be:
```
pub rsa4096 2014-12-15 [C] [expires: 2025-07-21]
EF6E286DDA85EA2A4BA7DE684E2C6E8793298290
uid [ unknown] Tor Browser Developers (signing key) <torbrowser@torproject.org>
sub rsa4096 2021-09-17 [S] [expires: 2024-08-23]
```anarcatanarcathttps://gitlab.torproject.org/tpo/core/arti/-/issues/1202Remove support for configurable keystore directory2024-02-21T15:22:18ZNick MathewsonRemove support for configurable keystore directoryWe eventually want to make our default keystore dependent on our state directory, not on ARTI_LOCAL_DATA. But the right ways to do so (see #1185) are a bit tricky and need more design. So until we have #1185 figured out, we should remo...We eventually want to make our default keystore dependent on our state directory, not on ARTI_LOCAL_DATA. But the right ways to do so (see #1185) are a bit tricky and need more design. So until we have #1185 figured out, we should remove the `keystore_dir` configuration option.Arti: Onion service supportgabi-250gabi-250