The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-09-30T13:45:56Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26932Soft assert in HS3 with vanguards ([warn] Invalid signature for service descr...2021-09-30T13:45:56ZGeorge KadianakisSoft assert in HS3 with vanguards ([warn] Invalid signature for service descriptor signing key: expired)I recently got the following soft assert on my HSv3 with latest master:
```
Jul 22 09:05:41.000 [warn] Invalid signature for service descriptor signing key: expired
Jul 22 09:05:41.000 [warn] tor_bug_occurred_(): Bug: src/feature/hs/hs_...I recently got the following soft assert on my HSv3 with latest master:
```
Jul 22 09:05:41.000 [warn] Invalid signature for service descriptor signing key: expired
Jul 22 09:05:41.000 [warn] tor_bug_occurred_(): Bug: src/feature/hs/hs_descriptor.c:2367: hs_desc_encode_descriptor: Non-fatal assertion !(ret < 0) failed. (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: Non-fatal assertion !(ret < 0) failed in hs_desc_encode_descriptor at src/feature/hs/hs_descriptor.c:2367. Stack trace: (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(log_backtrace_impl+0x47) [0x7f9979f5b437] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(tor_bug_occurred_+0xbe) [0x7f9979f56d0e] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(hs_desc_encode_descriptor+0xb2) [0x7f9979e5dba2] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(hs_service_run_scheduled_events+0x1a75) [0x7f9979e64ac5] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(+0x51fb1) [0x7f9979dc4fb1] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(+0x593b1) [0x7f9979dcc3b1] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f99793f63dc] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(do_main_loop+0x203) [0x7f9979dc8e13] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(tor_run_main+0x2a5) [0x7f9979dca325] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(tor_main+0x3a) [0x7f9979dc364a] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(main+0x19) [0x7f9979dc33b9] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f99785e92b1] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
Jul 22 09:05:41.000 [warn] Bug: ./tor/src/app/tor(_start+0x2a) [0x7f9979dc340a] (on Tor 0.3.5.0-alpha-dev e2b744ce38edb890)
```
I'm suspecting it might have to do with the legacy/trac#25552 fix because the code changed there is relevant to this bug, altho I don't see how it can cause this bug.
Based on the logs, it seems like my HSv3 kept that descriptor around for about 56 hours when the descriptor signing key cert lifetime is 54 hours (see `HS_DESC_CERT_LIFETIME`).Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26703Lower log level of "Scheduler type KIST has been enabled"2020-06-27T13:52:57ZpastlyLower log level of "Scheduler type KIST has been enabled"I like seeing it, but that doesn't mean everyone should have to see it. Tor doesn't log about EWMA vs RR.I like seeing it, but that doesn't mean everyone should have to see it. Tor doesn't log about EWMA vs RR.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26447Add check-includes to check-local?2020-06-27T13:53:08ZNick MathewsonAdd check-includes to check-local?We now have a handy tool that lets us check our includes for modularity violations. We could make it part of "make check", and have our CI enforce it for us!We now have a handy tool that lets us check our includes for modularity violations. We could make it part of "make check", and have our CI enforce it for us!Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26223Allow longer bandwidth lines in bandwidth files2020-06-27T13:53:20ZteorAllow longer bandwidth lines in bandwidth filesBandwidth files have a line limit of 510 characters (512 - newline and NUL).
We should make sure this limit is high enough for future bandwidth files.
We can do this by finding out the current length of sbws and torflow lines, multiply...Bandwidth files have a line limit of 510 characters (512 - newline and NUL).
We should make sure this limit is high enough for future bandwidth files.
We can do this by finding out the current length of sbws and torflow lines, multiplying it by 4x, then rounding up to the nearest power of two.
We can use the examples in the spec if we need to:
https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt
Maybe we should wait until sbws has added all the new fields?Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24312Update DirCache Warning2020-06-27T13:54:56ZcypherpunksUpdate DirCache WarningWhen DirCache is disabled tor 0.3.1.x says:
```
[warn] DirCache is disabled and we are configured as a relay. This may disqualify us from becoming a guard in the future.
```
Since TorBrowser ships tor 0.3.1.x we can consider this as gr...When DirCache is disabled tor 0.3.1.x says:
```
[warn] DirCache is disabled and we are configured as a relay. This may disqualify us from becoming a guard in the future.
```
Since TorBrowser ships tor 0.3.1.x we can consider this as granted (not in the future), right?Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19979Use OpenSSL 1.1.0 HKDF in Tor when available.2021-09-16T14:33:30ZNick MathewsonUse OpenSSL 1.1.0 HKDF in Tor when available.OpenSSL 1.1.0 now includes HKDF support. We should consider using their implementation instead of ours when it's available.OpenSSL 1.1.0 now includes HKDF support. We should consider using their implementation instead of ours when it's available.Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/19566SR: Use BUG() instead of tor_assert() when we can2020-06-27T13:58:37ZDavid Gouletdgoulet@torproject.orgSR: Use BUG() instead of tor_assert() when we canExample:
```
tor_assert(sr_state_get_phase() == SR_PHASE_REVEAL);
```
Should be replaced by:
```
if (BUG(sr_state_get_phase() != SR_PHASE_REVEAL))
return;
```
The idea is to not kill the dirauth if this happens but still scream very...Example:
```
tor_assert(sr_state_get_phase() == SR_PHASE_REVEAL);
```
Should be replaced by:
```
if (BUG(sr_state_get_phase() != SR_PHASE_REVEAL))
return;
```
The idea is to not kill the dirauth if this happens but still scream very loudly. Few other places in the SR subsystem can be found.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/15518Tor considers routers in the same IPv6 /16 to be "in the same subnet"2020-06-27T14:01:27ZIsis LovecruftTor considers routers in the same IPv6 /16 to be "in the same subnet"When `EnforceDistinctSubnets` is enabled, tor uses:
```
/** Return true iff router1 and router2 have similar enough network addresses ...When `EnforceDistinctSubnets` is enabled, tor uses:
```
/** Return true iff router1 and router2 have similar enough network addresses
* that we should treat them as being in the same family */
static INLINE int
addrs_in_same_network_family(const tor_addr_t *a1,
const tor_addr_t *a2)
{
return 0 == tor_addr_compare_masked(a1, a2, 16, CMP_SEMANTIC);
}
```
to determine if an address is in the same family. For an example IPv6 address, `2001:1234::0:1`, its /16 representation is `2001::/16`, meaning that `2001:ffff::` would be in the same family. A `\16` for IPv6 is _huge_, particularly considering that [only one-eighth of all IPv6 space is currently allocated for use on the internet](https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml) (`2000::/3`). For the path selection code, using `/16` essentially means that no two IPv6 routers in the same country (or possibly even continent) will be in the same path, and might possibly provide extremely increased chance of selection to routers in weird/rare IPv6 subnets.
For a related ticket, see legacy/trac#15517 governing how BridgeDB's version of `EnforceDistinctSubnets` will work for IPv6. (In that ticket, I proposed using IPv6 `/32`s, since that is the [minimum ARIN IPv6 subnet allocation for a LIR](https://www.arin.net/resources/request/ipv6_initial_assign.html).Tor: 0.3.5.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/13221Misleading error messages about bind_ipv4_only and bind_ipv6_only?2020-06-27T14:02:28ZRoger DingledineMisleading error messages about bind_ipv4_only and bind_ipv6_only?```
if (bind_ipv4_only && tor_addr_family(&addr) == AF_INET6) {
log_warn(LD_CONFIG, "Could not interpret %sPort address as IPv6",
portname);
goto err;
}
```
Is this warn mixed up? Same with t...```
if (bind_ipv4_only && tor_addr_family(&addr) == AF_INET6) {
log_warn(LD_CONFIG, "Could not interpret %sPort address as IPv6",
portname);
goto err;
}
```
Is this warn mixed up? Same with the one below it.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8415Use event_set_mem_functions2022-04-29T21:02:58ZNick MathewsonUse event_set_mem_functionsWe should use event_set_mem_functions so that Libevent also uses our memory allocation functions, as we do for openssl when we call CRYPTO_set_mem_ex_functions.We should use event_set_mem_functions so that Libevent also uses our memory allocation functions, as we do for openssl when we call CRYPTO_set_mem_ex_functions.Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/3569Refactor socks parsing2021-09-16T14:36:24ZNick MathewsonRefactor socks parsingThe function parse_socks and its interactions with the functions that call it have grown nigh-unmaintainably complex. Let's replace it with a simple, more linear function. Key points:
* State should be kept explicitly. Let's forget...The function parse_socks and its interactions with the functions that call it have grown nigh-unmaintainably complex. Let's replace it with a simple, more linear function. Key points:
* State should be kept explicitly. Let's forget this "if the socks version is set, we've parsed this much, ..." business.
* The function should dispatch first on state, next on anything else.
* We should think of a much better interface; the functions that call parse_socks have grown way too tricky.Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/arti/-/issues/33Support RESOLVE and RESOLVE_PTR commands2021-07-27T18:03:30ZNick MathewsonSupport RESOLVE and RESOLVE_PTR commandsThese two commands are socks extensions. Arti parses them, but doesn't actually implement them. Further, there is backend support for sending RELAY_RESOLVE commands. All this will need is some connecting together.These two commands are socks extensions. Arti parses them, but doesn't actually implement them. Further, there is backend support for sending RELAY_RESOLVE commands. All this will need is some connecting together.Arti 0.1.0 release: Okay for experimental embeddinghttps://gitlab.torproject.org/tpo/core/arti/-/issues/154Consider `pem-rfc7468` instead of current pem implementation in tor-netdoc2022-06-24T13:14:20ZNick MathewsonConsider `pem-rfc7468` instead of current pem implementation in tor-netdocThe new `pem-rfc7468` crate is likely a better implementation of PEM-style encoding/decoding than our current implementation; we should probably use it instead.
The file to modify will be `tor-netdoc/src/parse/tokenize.rs`.The new `pem-rfc7468` crate is likely a better implementation of PEM-style encoding/decoding than our current implementation; we should probably use it instead.
The file to modify will be `tor-netdoc/src/parse/tokenize.rs`.Arti 1.0.0: Ready for production usearturomf94arturomf94https://gitlab.torproject.org/tpo/core/arti/-/issues/95Have more experienced Rust programmers read our code2022-02-24T21:07:53ZNick MathewsonHave more experienced Rust programmers read our codeArti is my first production project in Rust; none of us at Tor currently have done a Rust project of this size before. Before we can say that Arti is production ready, we should seek some experienced Rust programmers and ask them to loo...Arti is my first production project in Rust; none of us at Tor currently have done a Rust project of this size before. Before we can say that Arti is production ready, we should seek some experienced Rust programmers and ask them to look through our code for general quality issues.
If you're reading this because you're new to Arti and you don't know so much about Tor: no need to worry! Just poke around in the codebase, find a random file, and start asking yourself: does this look like good rust? What about the other things that use it? Is there a way to make it better?Arti 1.0.0: Ready for production usehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41049QR codes in connection settings aren't recognized by some readers in dark theme2022-07-27T15:30:51ZWofWcawofwca@protonmail.comQR codes in connection settings aren't recognized by some readers in dark themeSome readers don't recognize QR codes with inverted colors. You may call it a "you" problem, but still.
Here's the responsible code:
* https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/b2ffba38205d148463a9471e866e5e9dc8...Some readers don't recognize QR codes with inverted colors. You may call it a "you" problem, but still.
Here's the responsible code:
* https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/b2ffba38205d148463a9471e866e5e9dc8d37673/browser/components/torpreferences/content/bridgeQrDialog.jsm#L30-31
* https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/b2ffba38205d148463a9471e866e5e9dc8d37673/browser/components/torpreferences/content/connectionPane.js#L605-606
Simply hard-coding black and white (or keeping the default ones) regardless of theme wouldn't help because the image is drawn directly on top of dark/light background, depending on color theme, which makes it unreadable if the background is dark. Although we could add a padding element with white background.
Or we could just wait until all readers start recognizing inverted QRs.
Similar issue in another project: https://github.com/bennyguitar/BTCDonationViewController/issues/1#issuecomment-39025558
If you agree that we should hard-code black and white, then I'd like to implement it.Tor Browser 12.0WofWcawofwca@protonmail.comWofWcawofwca@protonmail.comhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40638Visit our website link after build-to-build upgrade in Nightly channel points...2022-10-27T22:48:08ZrichardVisit our website link after build-to-build upgrade in Nightly channel points to old v2 onionAfter upgrade nightly builds have the following copy on about:tor:
----
### Tor Browser has been updated.
For the most up-to-date information about this release, [visit our website](http://f4amtbsowhix7rrf.onion/).
----
We need to u...After upgrade nightly builds have the following copy on about:tor:
----
### Tor Browser has been updated.
For the most up-to-date information about this release, [visit our website](http://f4amtbsowhix7rrf.onion/).
----
We need to upgrade this to the new v3 onionSponsor 131 - Phase 3 - Major ESR 102 MigrationPier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41279TorConnect.jsm module added in the TorSettings commit but not added to moz.bu...2022-09-06T15:58:53ZrichardTorConnect.jsm module added in the TorSettings commit but not added to moz.build until the TorConnect commitSeems like we have some leftover stuff from when these two commits were more intertwined. A cursory look suggests the `TorConnect.jsm` module implementation should be moved from the TorSettings commit ( 4c501c79aed3cb7096997355ced2869cb3...Seems like we have some leftover stuff from when these two commits were more intertwined. A cursory look suggests the `TorConnect.jsm` module implementation should be moved from the TorSettings commit ( 4c501c79aed3cb7096997355ced2869cb342d6e3 ) to the TorConnect commit ( 777c84f5211c153beb3506c362ec5a37be0d9650 ).
@pierov please close this if I'm wrong here and we do actually need the TorConnect module this early in the history
@henry otherwise, the MR for this would be a pair of fixup! commits ( see https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---fixupamendrewordltcommitgt for details ), one removing module from the TorSettings commit, and one adding it in the TorConnect commit.Sponsor 131 - Phase 3 - Major ESR 102 Migrationhenryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40611Audit license and copyright info2023-08-25T23:13:34ZrichardAudit license and copyright infoHTTPS-Everywhere has been removed from Desktop, so we should stop including their copyright and any licensing information we have bundled. We also need to update the base-browser target to not include unneeded licensing (tor, PTs, etc)HTTPS-Everywhere has been removed from Desktop, so we should stop including their copyright and any licensing information we have bundled. We also need to update the base-browser target to not include unneeded licensing (tor, PTs, etc)Sponsor 131 - Phase 3 - Major ESR 102 Migrationhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40599Windows 32bit installer is missing many languages from the NSIS file2022-10-04T19:01:53ZDavid Fifielddcf@torproject.orgWindows 32bit installer is missing many languages from the NSIS fileThe installer file lists 56 languages,
* https://github.com/MarkCSmith/tbb-windows-installer/blob/00133b8741eb8ca34fc8153d344c7c54a5e3fae9/torbrowser.nsi#L51
but the installer only shows 26.
It looks like these are the 30 languages tha...The installer file lists 56 languages,
* https://github.com/MarkCSmith/tbb-windows-installer/blob/00133b8741eb8ca34fc8153d344c7c54a5e3fae9/torbrowser.nsi#L51
but the installer only shows 26.
It looks like these are the 30 languages that are missing, notably including TBB official languages Arabic, Farsi, Korean, Polish, Russian, Turkish, and Chinese.
```
!insertmacro MUI_LANGUAGE "SimpChinese"
!insertmacro MUI_LANGUAGE "TradChinese"
!insertmacro MUI_LANGUAGE "Japanese"
!insertmacro MUI_LANGUAGE "Korean"
!insertmacro MUI_LANGUAGE "Greek"
!insertmacro MUI_LANGUAGE "Russian"
!insertmacro MUI_LANGUAGE "Polish"
!insertmacro MUI_LANGUAGE "Ukrainian"
!insertmacro MUI_LANGUAGE "Czech"
!insertmacro MUI_LANGUAGE "Slovak"
!insertmacro MUI_LANGUAGE "Croatian"
!insertmacro MUI_LANGUAGE "Bulgarian"
!insertmacro MUI_LANGUAGE "Hungarian"
!insertmacro MUI_LANGUAGE "Thai"
!insertmacro MUI_LANGUAGE "Romanian"
!insertmacro MUI_LANGUAGE "Latvian"
!insertmacro MUI_LANGUAGE "Macedonian"
!insertmacro MUI_LANGUAGE "Estonian"
!insertmacro MUI_LANGUAGE "Turkish"
!insertmacro MUI_LANGUAGE "Lithuanian"
!insertmacro MUI_LANGUAGE "Slovenian"
!insertmacro MUI_LANGUAGE "Serbian"
!insertmacro MUI_LANGUAGE "SerbianLatin"
!insertmacro MUI_LANGUAGE "Arabic"
!insertmacro MUI_LANGUAGE "Farsi"
!insertmacro MUI_LANGUAGE "Hebrew"
!insertmacro MUI_LANGUAGE "Mongolian"
!insertmacro MUI_LANGUAGE "Albanian"
!insertmacro MUI_LANGUAGE "Belarusian"
!insertmacro MUI_LANGUAGE "Bosnian"
```Sponsor 131 - Phase 3 - Major ESR 102 Migrationhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41104Visit our website link after build-to-build upgrade in Nightly channel points...2022-10-18T12:22:22ZrichardVisit our website link after build-to-build upgrade in Nightly channel points to old v2 onionAfter upgrade nightly builds have the following copy on about:tor:
----
### Tor Browser has been updated.
For the most up-to-date information about this release, [visit our website](http://f4amtbsowhix7rrf.onion/).
----
We need to u...After upgrade nightly builds have the following copy on about:tor:
----
### Tor Browser has been updated.
For the most up-to-date information about this release, [visit our website](http://f4amtbsowhix7rrf.onion/).
----
We need to upgrade this to the new v3 onionSponsor 131 - Phase 3 - Major ESR 102 MigrationPier Angelo VendramePier Angelo Vendrame