The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-21T17:14:34Zhttps://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/48Compute and store uptime information2024-03-21T17:14:34ZHiroCompute and store uptime informationWe have a metrics in VM for uptime but I am not sure how we should process it. Maybe we should add an uptime field to the server_status table that results from processing the uptime timeseries.We have a metrics in VM for uptime but I am not sure how we should process it. Maybe we should add an uptime field to the server_status table that results from processing the uptime timeseries.HiroHirohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/21panic: assignment to entry in nil map2023-10-25T15:45:08Zcomputerscotpanic: assignment to entry in nil map```
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "VERSION 1"
Jul 04 13:31:06.000 [info] handle_proxy_line(): Got a line from managed proxy '/var/lib/torwebtunnel/webtunnel': (VERSION 1)
Jul 04 13:31:06.000 [d...```
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "VERSION 1"
Jul 04 13:31:06.000 [info] handle_proxy_line(): Got a line from managed proxy '/var/lib/torwebtunnel/webtunnel': (VERSION 1)
Jul 04 13:31:06.000 [debug] read_to_chunk(): Read 313 bytes. 313 on inbuf.
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "panic: assignment to entry in nil map"
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error: panic: assignment to entry in nil map
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: ""
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error:
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "goroutine 1 [running]:"
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error: goroutine 1 [running]:
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib.Args.Add(...)"
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error: gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib.Args.Add(...)
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: " /root/go/pkg/mod/gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib@v1.4.0/args.go:32"
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error: /root/go/pkg/mod/gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib@v1.4.0/args.go:32
Jul 04 13:31:06.000 [debug] process_read_lines(): Read line from process: "main.main()"
Jul 04 13:31:06.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/var/lib/torwebtunnel/webtunnel' reported via standard error: main.main()
```shelikhooshelikhoohttps://gitlab.torproject.org/tpo/core/arti/-/issues/948`onion-service-client` not in `default`?2023-07-07T19:28:06ZNick Mathewson`onion-service-client` not in `default`?I had thought that we put `onion-service-client` in `default` for `arti` and `arti-client`. But I don't see it there?
At this point we should fix our public-facing documentation (incl the blog post).
Reported by @jnewsome. cc @DizietI had thought that we put `onion-service-client` in `default` for `arti` and `arti-client`. But I don't see it there?
At this point we should fix our public-facing documentation (incl the blog post).
Reported by @jnewsome. cc @DizietIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/60geoip lookup API2023-07-17T20:22:04Zcybertageoip lookup APIIn order to show the assumed country of a tor relay based on its IPs onionmasq has to provide an API for GeoIP lookups. This task is a follow-up bit of https://gitlab.torproject.org/tpo/core/onionmasq/-/issues/38.In order to show the assumed country of a tor relay based on its IPs onionmasq has to provide an API for GeoIP lookups. This task is a follow-up bit of https://gitlab.torproject.org/tpo/core/onionmasq/-/issues/38.VPN pre-alpha 02etaetahttps://gitlab.torproject.org/tpo/core/arti/-/issues/947Can we speed up our (blocking) CI pipelines at all?2023-07-04T19:03:17ZNick MathewsonCan we speed up our (blocking) CI pipelines at all?Currently a successful pipeline takes around 23 to 50 minutes to complete. That's not so great in terms of interactive development.
Can any of our slower tests be made faster, or safely made "nightly only" or "main only" or something, ...Currently a successful pipeline takes around 23 to 50 minutes to complete. That's not so great in terms of interactive development.
Can any of our slower tests be made faster, or safely made "nightly only" or "main only" or something, so that we can get our MRs checked and merged faster?https://gitlab.torproject.org/tpo/core/arti/-/issues/946Somehow prevent or discourage people from creating a huge number of independe...2023-11-15T18:58:26ZNick MathewsonSomehow prevent or discourage people from creating a huge number of independent TorClientsThere's an antipattern in our API: it's possible and easy to create a huge number of separate `TorClient` instances that do not share internal state, which all try to bootstrap independently. This needlessly wastes resources.
It's poss...There's an antipattern in our API: it's possible and easy to create a huge number of separate `TorClient` instances that do not share internal state, which all try to bootstrap independently. This needlessly wastes resources.
It's possible that the confusion here is exacerbated by the fact that we would _prefer_ people to create a large number of `TorClient` instances that **do** share internal state, by creating one instance and `Clone`ing it.
Possible solutions include:
* Removing our "shared state" code (see #611), or making it off-by-default.
* Adding more documentation to discourage people from doing this.
* Somehow making it harder to do in the same process in the API.
* Creating a runtime warning if people do this.Arti: RPC Supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/940Client behaviour when HS descriptor contains too many IPTs2023-11-13T13:30:15ZIan Jacksoniwj@torproject.orgClient behaviour when HS descriptor contains too many IPTsSince !1332, when the descriptor has >NUM_INTRO_POINT_MAX IPTs, Arti discards the superfluous ones.
It isn't clear whether this is correct. Perhaps Arti ought to reject such a descriptor. (Apparently C Tor does.)
There is much debate...Since !1332, when the descriptor has >NUM_INTRO_POINT_MAX IPTs, Arti discards the superfluous ones.
It isn't clear whether this is correct. Perhaps Arti ought to reject such a descriptor. (Apparently C Tor does.)
There is much debate here: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1332#note_2917457
CC @dgoulet @nickmArti: Onion Service Securityhttps://gitlab.torproject.org/tpo/network-health/margot/-/issues/34Obtain unusable relays from netdir2023-08-09T16:21:58ZjugaObtain unusable relays from netdirso that we can use the new `rsa_id_unlisted` (https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1325/diffs?commit_id=cede3acadd2d80303367713e4f5b997bb53c6a25) method when we do not need all the microdescriptors but just know w...so that we can use the new `rsa_id_unlisted` (https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1325/diffs?commit_id=cede3acadd2d80303367713e4f5b997bb53c6a25) method when we do not need all the microdescriptors but just know whether a relay is in the consensus.jugajugahttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/168Change labelling of resources failing tests from `gone`2023-11-07T00:20:13ZonyinyangChange labelling of resources failing tests from `gone`After discussing with @meskio about how rdsys sends updates (every time there is a reconnect) and how often these will occur (possibly as often as every 10 minutes), we may need to reconsider the previous changes to indicate `gone` resou...After discussing with @meskio about how rdsys sends updates (every time there is a reconnect) and how often these will occur (possibly as often as every 10 minutes), we may need to reconsider the previous changes to indicate `gone` resources. Since `changed` and `gone` resources are not sent in full updates and are only sent in between full updates, it seems that it might make more sense to keep resources that changed or are failing tests in the list that will be sent as `new` bridges during a full update, since otherwise they might get missed. Then, instead of using the `gone` or `changed` label to decide what to do with these resources, determine what to do with them based on the `LastPassed` time or changed values (OID?). This should only require minor changes to rdsys as well as changes to the [lox-distributor](https://gitlab.torproject.org/tpo/anti-censorship/lox-rs/-/tree/main/crates/lox-distributor) to check the `lastPassed` field in resources to make sure that it isn't older than a specified amount of time and handle it as `gone` resources are currently handled if so.
@cohosh do you have any thoughts on this?onyinyangonyinyanghttps://gitlab.torproject.org/tpo/core/arti/-/issues/933Release-blocking TODO HS in tor-keymgr2023-07-06T15:36:14Zgabi-250Release-blocking TODO HS in tor-keymgrMRs to be merged:
- [x] !1321
- [x] !1312
- [x] !1262
- [x] !1337
`README.md`:
- [x] `TODO hs: write more comprehensive documentation when the API ...` (!1360)
`key_specifier.rs`:
- [x] `TODO hs: restrict the character set and synta...MRs to be merged:
- [x] !1321
- [x] !1312
- [x] !1262
- [x] !1337
`README.md`:
- [x] `TODO hs: write more comprehensive documentation when the API ...` (!1360)
`key_specifier.rs`:
- [x] `TODO hs: restrict the character set and syntax for values of this type` (!1262)
- [x] `#[allow(clippy::unnecessary_wraps)] // TODO hs: remove` (!1262)
`key_type.rs`:
- [x] `// TODO hs: this is subject to change`
- [x] `// TODO hs: this is subject to change` (!1334)
`keystore.rs`:
- [x] `TODO hs: the key_type argument here might seem redundant` (!1334)
- [x] `TODO hs: try to fold this trait into EncodableKey`. (!1334)
`mgr.rs`:
- [x] `TODO hs: we immediately return if one of the keystores is inaccessible.` (!1334)
- [x] `TODO hs: would it be useful for this API to return a Result<Option<K>> here (i.e. the old key)?` (!1334)
`ssh.rs`:
- [x] `// TODO hs: remove` (!1321)
- [x] `todo!() // TODO hs` (!1321)
- [x] `// TODO hs: implement` (!1321)gabi-250gabi-250https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/20Documentation about server file2023-10-25T15:46:06ZJacobo NájeraDocumentation about server fileI am trying to install a webtunnel server. I am not understand the following instruction in the documentation:
### Get Environment Ready
```
#copy server file to server
scp server root@$SERVER_ADDRESS:/var/lib/torwebtunnel/webtunnel
`...I am trying to install a webtunnel server. I am not understand the following instruction in the documentation:
### Get Environment Ready
```
#copy server file to server
scp server root@$SERVER_ADDRESS:/var/lib/torwebtunnel/webtunnel
```
Where is server file? whe i tried it:
ssh: connect to host ip port 22: Connection timed out
lost connection
Thanks, Jacoboshelikhooshelikhoohttps://gitlab.torproject.org/tpo/core/tor/-/issues/40816metrics: New circuit related metrics relay side2024-01-31T07:14:18ZDavid Gouletdgoulet@torproject.orgmetrics: New circuit related metrics relay sideThis is tied to sponsor 112 with https://gitlab.torproject.org/tpo/network-health/team/-/issues/299.
We need to implement these:
- Number of circuit collapsing as in DESTROY coming from the opposite direction.
- Circuit being closed du...This is tied to sponsor 112 with https://gitlab.torproject.org/tpo/network-health/team/-/issues/299.
We need to implement these:
- Number of circuit collapsing as in DESTROY coming from the opposite direction.
- Circuit being closed due to protocol violation.
- Anything around drop cells. A rate, what type, etc...
Basically, keep counters of those events and expose them on the `MetricsPort`.Tor: 0.4.9.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/927Allow ChanMgr to expire a specific channel immediately2023-06-27T14:04:55ZSaksham MittalAllow ChanMgr to expire a specific channel immediatelyFrom discussion on IRC, @nickm expressed desire for such a function:
`expire_channels() expires all channels that have been unused for too long; I am thinking instead about the possibility that the user wants a way to say "expire this on...From discussion on IRC, @nickm expressed desire for such a function:
`expire_channels() expires all channels that have been unused for too long; I am thinking instead about the possibility that the user wants a way to say "expire this one channel right now."`Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41859Font used for IPs in circuit display is illegible2023-10-10T16:03:27ZcypherpunksFont used for IPs in circuit display is illegibleThe font for IPs in the 'Tor Circuit' display is illegible and to small.
The old one ,TBB >12.5, was good!
Can i change it with a parameter, about:config; without changing the browser fingerprint? Display:1080p desktop monitor, OS=Window...The font for IPs in the 'Tor Circuit' display is illegible and to small.
The old one ,TBB >12.5, was good!
Can i change it with a parameter, about:config; without changing the browser fingerprint? Display:1080p desktop monitor, OS=Windows.
p.s.: I havn't had no difficulty finding the circuit display.henryhenryhttps://gitlab.torproject.org/tpo/core/arti/-/issues/925Non-fatal failures to bootstrap don't provide embedding code with any details2023-11-07T12:11:00ZetaNon-fatal failures to bootstrap don't provide embedding code with any detailsAnother weird bootstrapping failure in the wild on Android/onionmasq, this time after uncleanly shutting down an emulator and bringing it back up again:
```
06-26 16:49:11.361 2896 3087 I onionmasq: tor_dirmgr::bootstrap: 2: Looking f...Another weird bootstrapping failure in the wild on Android/onionmasq, this time after uncleanly shutting down an emulator and bringing it back up again:
```
06-26 16:49:11.361 2896 3087 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:49:11.592 2896 3090 I onionmasq: tor_proto::circuit::streammap: Actually got an end cell on a half-closed stream!
06-26 16:49:13.810 2896 3087 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:49:13.871 2896 3090 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:49:13.873 2896 3090 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 1s.
06-26 16:49:14.877 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 1: Looking for a consensus.
06-26 16:49:15.112 2896 3088 D onionmasq: onionmasq_mobile::scaffolding: AndroidScaffolding::protect() for fd 110
06-26 16:49:15.898 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:49:18.133 2896 3089 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:49:18.206 2896 3087 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:49:18.208 2896 3087 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 1.686s.
06-26 16:49:19.903 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 1: Looking for a consensus.
06-26 16:49:20.952 2896 3089 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:49:23.163 2896 3089 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:49:23.318 2896 3088 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:49:23.320 2896 3088 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 4.452s.
06-26 16:49:27.784 2896 3090 I onionmasq: tor_dirmgr::bootstrap: 1: Looking for a consensus.
06-26 16:49:28.870 2896 3090 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:49:30.992 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:49:31.031 2896 3089 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:49:31.031 2896 3089 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 9.12s.
06-26 16:49:40.171 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 1: Looking for a consensus.
06-26 16:49:41.212 2896 3090 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:49:43.037 2896 3090 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:49:43.070 2896 3090 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:49:43.071 2896 3090 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 23.464s.
06-26 16:50:06.541 2896 3087 I onionmasq: tor_dirmgr::bootstrap: 1: Looking for a consensus.
06-26 16:50:07.578 2896 3089 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:50:10.096 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:50:10.142 2896 3088 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:50:10.143 2896 3088 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 50.084s.
```
The principal complaint here is, as the error seems to have been nonfatal, there's no way for the calling code (onionmasq) to know what it is; the bootstrapping code simply loops forever without ever actually returning an error. In this case, it was evidently due to the state directory being corrupted after the unclean shutdown somehow, since clearing the cache instantly fixed it (which would be a bug in its own right, if I had any actual details of the problem).
Would it be possible to provide some mechanism to allow embedding code to have more control or insight into the bootstrap retry process? This is really quite a problem in the Tor VPN use case, since this failure just manifests itself to the user as an indefinite failure to make progress (it does at least set the 'stuck' flag, but we really would prefer the actual error object).
(Yes, I know I can configure it to give up after n attempts, etc -- but then the only error received is an overly generic `CantAdvanceState`).Arti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/923Intermittent test failure for state::test::expiry on main2023-06-26T18:32:30ZNick MathewsonIntermittent test failure for state::test::expiry on main```
--- STDOUT: tor-hsclient state::test::expiry ---
running 1 test
2023-06-26T12:57:12.964697Z TRACE expiry: tor_hsclient::state: HS conn get_or_launch: HsId(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaam2dqd.onion)...```
--- STDOUT: tor-hsclient state::test::expiry ---
running 1 test
2023-06-26T12:57:12.964697Z TRACE expiry: tor_hsclient::state: HS conn get_or_launch: HsId(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaam2dqd.onion) NarrowableIsolation("") HsClientSecretKeys(0x7fdb40005230)
2023-06-26T12:57:12.964841Z TRACE expiry: tor_hsclient::state: HS conn state: Closed { data: MockData, last_used: Instant { tv_sec: 82081, tv_nsec: 41813300 } }
2023-06-26T12:57:12.964882Z TRACE expiry: tor_hsclient::state: HS conn state: Working { barrier_recv: Receiver, error: Mutex { data: None, poisoned: false, .. } }
2023-06-26T12:57:12.964960Z TRACE expiry: tor_hsclient::state: HS conn state: Open { data: MockData, last_used: Instant { tv_sec: 82081, tv_nsec: 41813300 }, circuit_expiry_task: CircuitExpiryTask }
2023-06-26T12:57:12.992756Z TRACE expiry: tor_hsclient::state: HS conn get_or_launch: HsId(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaam2dqd.onion) NarrowableIsolation("") HsClientSecretKeys(0x7fdb40005230)
2023-06-26T12:57:12.992904Z TRACE expiry: tor_hsclient::state: HS conn state: Open { data: MockData, last_used: Instant { tv_sec: 82081, tv_nsec: 41813300 }, circuit_expiry_task: CircuitExpiryTask }
test state::test::expiry ... FAILED
failures:
failures:
state::test::expiry
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 5 filtered out; finished in 0.04s
--- STDERR: tor-hsclient state::test::expiry ---
thread 'state::test::expiry' panicked at 'assertion failed: `(left != right)`
left: `MockCirc { ok: Mutex { data: true, poisoned: false, .. } }`,
right: `MockCirc { ok: Mutex { data: true, poisoned: false, .. } }`', crates/tor-hsclient/src/state.rs:843:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
This happens intermittently for me on current main.Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/922Default value for "connect to onion services", and configuration2024-01-10T18:08:41ZIan Jacksoniwj@torproject.orgDefault value for "connect to onion services", and configurationWhen we release HS client support, should it be enabled by default right away?
Or should we wait for the planned additional security/privacy/assurance work?
If we want to disable it, are we going to disable it in the build by default, ...When we release HS client support, should it be enabled by default right away?
Or should we wait for the planned additional security/privacy/assurance work?
If we want to disable it, are we going to disable it in the build by default, or by changing the default for `StreamPrefsconnect_to_onion_services`?
There should probably be a config parameter, which should probably populate the stream pref default value? I'll see about making one of those.
CC @nickm @dgouletArti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/921Make sure panics go to logs, not just stderr.2023-07-06T13:09:55ZNick MathewsonMake sure panics go to logs, not just stderr.See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1292#note_2915263:
It looks like, when a spawned task panics, it makes the whole tokio task-handler thread panic, which in turn logs to stderr rather than to...See discussion at https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1292#note_2915263:
It looks like, when a spawned task panics, it makes the whole tokio task-handler thread panic, which in turn logs to stderr rather than to `tracing`. We should probably make sure that all panics are also logged to our `tracing` logs at level `error`; these are real bugs that shouldn't be forgotten.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/onion-services/onion-support/-/issues/213Privacy International onionsite is offline2023-08-30T15:17:02ZGusPrivacy International onionsite is offlineprivacyinternational.org onionsite is offline for a while, we should contact them and check what's up:
https://privacy2ws3ora5p4qpzptqr32qm54gf5ifyzvo5bhl7bb254c6nbiyd.onion/privacyinternational.org onionsite is offline for a while, we should contact them and check what's up:
https://privacy2ws3ora5p4qpzptqr32qm54gf5ifyzvo5bhl7bb254c6nbiyd.onion/GusGushttps://gitlab.torproject.org/tpo/team/-/issues/187Code Audit for Sponsor 1122024-03-20T11:59:38ZGabagaba@torproject.orgCode Audit for Sponsor 112- [ ] Create RFPT
- [ ] Send to DRL for approval
- [ ] Send to auditors
- [ ] Choose an auditor to start work- [ ] Create RFPT
- [ ] Send to DRL for approval
- [ ] Send to auditors
- [ ] Choose an auditor to start workGabagaba@torproject.orgGabagaba@torproject.org2024-06-01