The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-01-24T10:19:03Zhttps://gitlab.torproject.org/tpo/network-health/metrics/metrics-sql-tables/-/issues/10Rename `contacts` to `contact` in our `server_status` table2024-01-24T10:19:03ZGeorg KoppenRename `contacts` to `contact` in our `server_status` tableThere are not several contacts to a router but just a single one. Let's use `contact` instead in our table.There are not several contacts to a router but just a single one. Let's use `contact` instead in our table.https://gitlab.torproject.org/tpo/network-health/metrics/metrics-sql-tables/-/issues/9Add `exit_policy_summary` and `exit_policy_v6_summary` entries to `server_sta...2024-01-24T10:17:10ZGeorg KoppenAdd `exit_policy_summary` and `exit_policy_v6_summary` entries to `server_status` tableFor our server status and our NetworkStatus API we miss `exit_policy_summary` and `exit_policy_v6_summary`.For our server status and our NetworkStatus API we miss `exit_policy_summary` and `exit_policy_v6_summary`.https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/77Assemble `dir_address` in a router status if available2024-01-24T09:53:03ZGeorg KoppenAssemble `dir_address` in a router status if availableRequires https://gitlab.torproject.org/tpo/network-health/metrics/metrics-sql-tables/-/issues/8.Requires https://gitlab.torproject.org/tpo/network-health/metrics/metrics-sql-tables/-/issues/8.https://gitlab.torproject.org/tpo/network-health/metrics/metrics-sql-tables/-/issues/8Add a `dir_address` column for `server_status` table2024-01-23T12:30:30ZGeorg KoppenAdd a `dir_address` column for `server_status` table`dir_port`s are still a thing, e.g. for directory authorities: `"DirPort" is its current directory port, or "0" for "none".`. Thus, we should add a `dir_address` column to our `server_status` table, so that we can provide the same output...`dir_port`s are still a thing, e.g. for directory authorities: `"DirPort" is its current directory port, or "0" for "none".`. Thus, we should add a `dir_address` column to our `server_status` table, so that we can provide the same output as Onionoo currently does. Either an IP address + port or it's omitted.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40012Domain fronting requests don't work on some older Android versions2024-03-12T00:09:26ZPier Angelo VendrameDomain fronting requests don't work on some older Android versionsTor Browser for Android supports old versions of Android (API21, i.e., Android Lollipop).
While 13.5a3 doesn't work there because I used some NIO API that requires API26+, I've opened a MR to fix this (tpo/applications/tor-browser!894)....Tor Browser for Android supports old versions of Android (API21, i.e., Android Lollipop).
While 13.5a3 doesn't work there because I used some NIO API that requires API26+, I've opened a MR to fix this (tpo/applications/tor-browser!894).
While checking if things worked, I noticed that domain fronting requests don't (I don't get the special countries list).
As written in that MR, I tried to enable logging (I added `"-enableLogging", "-logLevel", "DEBUG", "-unsafeLogging"` as arguments), but I could get only these messages:
```
2024/01/22 10:20:23 [NOTICE]: obfs4proxy-0.0.14 - launched
2024/01/22 10:20:23 [INFO]: libObfs4proxy.so - initializing client transport listeners
2024/01/22 10:20:23 [INFO]: meek_lite - registered listener: 127.0.0.1:55852
2024/01/22 10:20:23 [INFO]: libObfs4proxy.so - accepting connections
2024/01/22 10:20:23 [WARN]: meek_lite(bridges.torproject.org:443) - closed connection: readfrom tcp 127.0.0.1:55852->127.0.0.1:48836: io: read/write on closed pipe
```
I think there might be some problems with some HTTPS certificate (at least letsencrypt had this problem a few years ago, indeed cohosh mentioned snowflake#40087. Fastly isn't using letsencrypt, but maybe they have a similar problem).
I can open bridges.torproject.org both in TBA and in the system browser, but I can't open https://moat.torproject.org.global.prod.fastly.net/ because it has a wrong certificate.
I don't think I'm using the latest version of Lyrebird, because in the last one the log file should be called lyrebird.log (I submitted a patch for that, unless I missed the log filename), but I can try to build one from a nightly build.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/community/support/-/issues/40136Post a warning on the forum about the upcoming Win & macOS EOLs2024-02-15T14:41:01ZGusPost a warning on the forum about the upcoming Win & macOS EOLsTor Browser 14.0 (2024-Q4), based on Firefox ESR 128, will drop support for Windows 7, 8, & 8.1, and macOS 10.12, 10.13 & 10.14.
We should announce it on the Tor forum and Tor social channels.
* [ ] Draft a text to the forum
* [ ] Inf...Tor Browser 14.0 (2024-Q4), based on Firefox ESR 128, will drop support for Windows 7, 8, & 8.1, and macOS 10.12, 10.13 & 10.14.
We should announce it on the Tor forum and Tor social channels.
* [ ] Draft a text to the forum
* [ ] Inform Comms team about this
(cc @ebanam @nina @richard)https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/148Wrong domain of GitLab's mail server certificate2024-02-08T16:05:24ZMynacolWrong domain of GitLab's mail server certificateI wanted to reply to a GitLab issue by mail, but my mail server refused to send it, as the TLS certificate could not be verified. My mail server is configured to strictly verify the respective certificates.
The mail was headed to `[...]...I wanted to reply to a GitLab issue by mail, but my mail server refused to send it, as the TLS certificate could not be verified. My mail server is configured to strictly verify the respective certificates.
The mail was headed to `[...]@gitlab.torproject.org`. My mail server queried the MX record of gitlab.torproject.org, but only got a CNAME response, which leads to gitlab-02.torproject.org that points to the right IP addresses. Now my mail server expected a TLS certificate for gitlab.torproject.org, but your postfix provided a certificate for gitlab-02.torproject.org, which my mail server regarded as invalid.
The easiest way to fix this is to add a MX record to gitlab.torproject.org pointing at gitlab-02.torproject.org. That could even help with mail deliverability.
Alternatively, you can provide a certificate for gitlab.torproject.org from your mail server just like on the website.
Maybe the test page on [internet.nl](https://internet.nl/mail/gitlab.torproject.org/1127446/) helps you too.improve mail servicesJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41482Automate renewal of self-signed LDAP cert2024-01-19T17:07:36ZKezAutomate renewal of self-signed LDAP certIn #41479 I renewed the self-signed LDAP cert for two years (730 days). That means that next time we renew it will be right after the holidays in 2026. It's not too much of a pain since it's only every 2 years, but it would be nice to no...In #41479 I renewed the self-signed LDAP cert for two years (730 days). That means that next time we renew it will be right after the holidays in 2026. It's not too much of a pain since it's only every 2 years, but it would be nice to not have to renew it right after we come back from our holiday break.
We could either automate the procedure entirely, or I could renew it again in a month or so so that the current cert will expire in February 2026. @anarcat any preferences or suggestions?Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/76extra_info_descriptor table default or wrong values2024-01-24T10:15:16Zjugaextra_info_descriptor table default or wrong valuesWorking on tpo/network-health/team#313, i thought to include whether a relay is overloaded in the grafana panels, so i tried this query:
```
select overload_ratelimits_version, overload_ratelimits_timestamp, overload_ratelimits_ratelimit...Working on tpo/network-health/team#313, i thought to include whether a relay is overloaded in the grafana panels, so i tried this query:
```
select overload_ratelimits_version, overload_ratelimits_timestamp, overload_ratelimits_ratelimit, overload_ratelimits_burstlimit , overload_ratelimits_read_count, overload_ratelimits_write_count, overload_fd_exhausted_version, overload_fd_exhausted_timestamp
from extra_info_descriptor
where fingerprint='0E13738FADDE15FC896E7CDB998C694F89F4E4B2';
```
which returns many rows as:
```
overload_ratelimits_version | overload_ratelimits_timestamp | overload_ratelimits_ratelimit | overload_ratelimits_burstlimit | overload_ratelimits_read_count | overload_ratelimits_write_count | overload_fd_exhausted_version | overload_fd_exhausted_timestamp
-----------------------------+-------------------------------+-------------------------------+--------------------------------+--------------------------------+---------------------------------+-------------------------------+---------------------------------
0 | 1969-12-31 23:59:59.999 | -1 | -1 | -1 | -1 | 0 | 1969-12-31 23:59:59.999
```
Maybe we could allow all these values to be NULL if the relay isn't overloaded?
I then tried to filter overload_ratelimits_read_count and overload_ratelimits_write_count without `-1` values and had to treat them as strings for that:
```
select count (*)
from extra_info_descriptor
where overload_ratelimits_write_count!='-1' and overload_ratelimits_read_count!='-1';
count
--------
169536
```
So maybe there's a bug here?
Maybe this was introduced by #47 (which i reviewed, ahem ;))
On a different issue, i think it'd be very helpful to add a VictoriaMetric metric to know whether a relay is overloaded.https://gitlab.torproject.org/tpo/core/arti/-/issues/1252OnionServicePrefs2024-01-23T16:54:08Zgabi-250OnionServicePrefsThe following discussion from !1887 should be addressed:
- [ ] @nickm started a [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1887#note_2984621): (+5 comments)
> Here's a thought. What would you think ...The following discussion from !1887 should be addressed:
- [ ] @nickm started a [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1887#note_2984621): (+5 comments)
> Here's a thought. What would you think about adding a new `prefs` argument to OnionService here? It could, for example, include information about whether we should construct the keys if they are not already found.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/75Include fallback dir update script logic into descriptorParser2024-01-18T08:19:59ZHiroInclude fallback dir update script logic into descriptorParserWe have an ant task for the website that runs a python script and update the fallback dirs list on the website. We should have that logic in descriptorParser and add the flag to the appropriate relays.We have an ant task for the website that runs a python script and update the fallback dirs list on the website. We should have that logic in descriptorParser and add the flag to the appropriate relays.https://gitlab.torproject.org/tpo/core/arti/-/issues/1250Add CLI tests for `arti hss`2024-01-17T13:57:38Zgabi-250Add CLI tests for `arti hss`Arti: Onion service supporthttps://gitlab.torproject.org/tpo/web/donate-neo/-/issues/15Promote common styles, assets and components to lego successor2024-01-16T22:12:42ZdonutsPromote common styles, assets and components to lego successorDescription TBD.Description TBD.https://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/1222Add central documentation for our filesystem layout2024-02-01T15:43:34ZNick MathewsonAdd central documentation for our filesystem layoutSomewhere in doc/dev, we should document all the files that we create or look at.
This will include:
* `tor-keymgr` stuff, possibly by reference
* All state files
* All onion-service-related files
* All cache files
* All locks...Somewhere in doc/dev, we should document all the files that we create or look at.
This will include:
* `tor-keymgr` stuff, possibly by reference
* All state files
* All onion-service-related files
* All cache files
* All locks
* All configuration files
This should replace `crates/tor-hsservice/src/state_dir.md` (cc @diziet)https://gitlab.torproject.org/tpo/core/arti/-/issues/1220Implement the `arti hss` subcommand2024-02-21T17:04:15Zgabi-250Implement the `arti hss` subcommandWe need to implement roughly what is described in !1730We need to implement roughly what is described in !1730Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1218Consider moving logging out of publisher reactor2024-01-30T17:34:35Zgabi-250Consider moving logging out of publisher reactor```rust
netidr_event = netdir_events.next().fuse() => {
// The consensus changed. Grab a new NetDir.
let netdir = match self.dir_provider.netdir(Timeliness::Timely) {
Ok(y) ...```rust
netidr_event = netdir_events.next().fuse() => {
// The consensus changed. Grab a new NetDir.
let netdir = match self.dir_provider.netdir(Timeliness::Timely) {
Ok(y) => y,
Err(e) => {
error_report!(e, "HS service {}: netdir unavailable. Retrying...", self.imm.nickname);
// Hopefully a netdir will appear in the future.
// in the meantime, suspend operations.
//
// TODO HSS there is a bug here: we stop reading on our inputs
// including eg publish_status_rx, but it is our job to log some of
// these things. While we are waiting for a netdir, all those messages
// are "stuck"; they'll appear later, with misleading timestamps.
//
// Probably this should be fixed by moving the logging
// out of the reactor, where it won't be blocked.
wait_for_netdir(self.dir_provider.as_ref(), Timeliness::Timely)
.await?
}
};
self.handle_consensus_change(netdir).await?;
}
```Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1217Consider adding a keystore watcher2024-01-11T18:45:15Zgabi-250Consider adding a keystore watcherSometimes we want to react to keystore changes. For example, if the identity of the service is rotated through some external means (e.g. via the `arti hss` command), the descriptor publisher needs to create and publish a new descriptor (...Sometimes we want to react to keystore changes. For example, if the identity of the service is rotated through some external means (e.g. via the `arti hss` command), the descriptor publisher needs to create and publish a new descriptor (using the newly generated keys).
* do we want the ability to "watch" keystores? What would the implementation for this look like? Should the `Keystore` trait have a function that returns the receiving end of an e.g. `postage::watch` channel? Will the channel return a `()` indicating something changed (without specifying what), or should it return the list of affected `KeyPath`s (or the corresponding `KeyPathPattern`s)?
* implementing this for FS-based keystores is fairly easy, but what about the HSM-based ones?Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/1216Improve descriptor publisher documentation2024-02-01T13:08:27Zgabi-250Improve descriptor publisher documentationArti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1213ipt manager should have more unit tests2024-01-23T15:59:20ZIan Jacksoniwj@torproject.orgipt manager should have more unit testsThere are some unit tests but they don't test all the exciting things that can happen. See the TODOs in the codebase tagged with this ticket.There are some unit tests but they don't test all the exciting things that can happen. See the TODOs in the codebase tagged with this ticket.Arti: Onion service supportIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.org