The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-11-08T20:48:06Zhttps://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/issues/33070Update website traffic fingerprinting section in tor browser design doc2023-11-08T20:48:06ZGeorg KoppenUpdate website traffic fingerprinting section in tor browser design docThe website traffic fingerprinting section needs to get updated as there have been a bunch of more or less recent developments that are not accounted for in it. In particular our [recent blog post](https://blog.torproject.org/new-low-cos...The website traffic fingerprinting section needs to get updated as there have been a bunch of more or less recent developments that are not accounted for in it. In particular our [recent blog post](https://blog.torproject.org/new-low-cost-traffic-analysis-attacks-mitigations) about low cost attacks in this space could be a good starting point for getting the update going.https://gitlab.torproject.org/tpo/tpa/team/-/issues/41150Deal with spam on bad-relays@ mailing list2023-11-08T17:25:30ZGeorg KoppenDeal with spam on bad-relays@ mailing listWe lately got a lot of spam to bad-relays@. That's a private mailing list where folks should be able to send reports to, though. Is there a mailman option or something to get rid of that spam while still allowing to get legit submissions...We lately got a lot of spam to bad-relays@. That's a private mailing list where folks should be able to send reports to, though. Is there a mailman option or something to get rid of that spam while still allowing to get legit submissions as usual? Or do we have to admit defeat here and move on with the status quo? An example spam mail looks like this:
```
From - Tue May 2 06:57:07 2023
X-Account-Key: account19
X-UIDL: 98521d39b4fe4f6493c53a0097f19f0b
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-Path: <bad-relays-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on vireo.riseup.net
X-Spam-Level:
X-Spam-Pyzor: Reported 0 times.
X-Spam-Status: No, score=-2.3 required=9.0 shortcircuit=no autolearn=disabled
version=3.4.6
X-Spam-Report:
* 0.3 NOMATCH_NICK_FROM From address with no part of name
* 0.1 FROM_ADMIN Common in mailphishing
* 0.0 PSTOCK_PART multipart/mixed possibly PNG attachment
* 0.0 FORWARD_RELAY Appears to be relayed through list or forwarding
* 0.0 ENV_FROM_DIFF0 Envelope From differs from from (eg list)
* -0.0 SPF_HELO_PASS SPF: HELO matches SPF record
* -0.0 SPF_PASS SPF: sender matches SPF record
* -0.0 USER_IN_WELCOMELIST_TO User is listed in 'welcomelist_to'
* 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
* mail domains are different
* 0.0 ODD_PUNCTUATION2 BODY: general bad punctuation as in 419s
* 0.2 EXCITED_PLING BODY: Two adjacent sentences end with exclamation
* marks
* 0.1 PHISH_CGI URI: Common cracked phishing destination
* 0.5 HREF_PHISH6 URI: HTTP link to static consumer address
* 1.6 HTML_IMAGE_ONLY_12 BODY: HTML: images with 800-1200 bytes of
* words
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 0.7 MPART_ALT_DIFF BODY: HTML and text parts are different
* 0.1 HTML_LINK_NR_TOP RAW: Short HTML message with link near top
* 0.1 LINK_NR_TOP RAW: Short message with link near top
* 0.0 HREF_PHISH7 RAW: Very short text accidentally linked
* 0.1 SRC_HTTP RAW: Contains external (tracking) images?
* 0.0 CK_419SIZE typical 419 size - avoid matches in long text
* 0.1 CK_KARD_SIZE short, card virus size - avoid matches in long
* text
* -0.0 T_SCC_BODY_TEXT_LINE No description available.
* 0.8 KAM_INFOUSMEBIZ Prevalent use of
* .info|.us|.me|.me.uk|.biz|xyz|id|rocks|life domains in
* spam/malware
* -0.1 AM_TRUNCATED Compensate on large message for misfiring rules
* 0.0 KAM_DMARC_STATUS Test Rule for DKIM or SPF Failure with Strict
* Alignment
* 0.1 HTML_SHORT_LINK_IMG_1 HTML is very short with a linked image
* -6.0 USER_IN_WHITELIST_TO DEPRECATED: See USER_IN_WELCOMELIST_TO
* -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
* manager
* -0.2 TXREP TXREP: Score normalizing based on sender's reputation
Delivered-To: gk-tpo@riseup.net
Received: from mx1.riseup.net (mx1-pn.riseup.net [10.0.1.33])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
client-signature RSA-PSS (2048 bits) client-digest SHA256)
(Client CN "mx1.riseup.net", Issuer "R3" (not verified))
by vireo.riseup.net (Postfix) with ESMTPS id 4Q99z800Q5z47
for <gk-tpo@riseup.net>; Mon, 1 May 2023 18:02:27 +0000 (UTC)
Received: from eugeni.torproject.org (eugeni.torproject.org [49.12.57.136])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by mx1.riseup.net (Postfix) with ESMTPS id 4Q99z749XtzDqCn;
Mon, 1 May 2023 18:02:27 +0000 (UTC)
Received: from eugeni.torproject.org (localhost [IPv6:::1])
by eugeni.torproject.org (Postfix) with ESMTP id 1BC0EE0524;
Mon, 1 May 2023 18:02:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by eugeni.torproject.org (Postfix) with ESMTP id 498C5E0522
for <bad-relays@lists.torproject.org>; Mon, 1 May 2023 18:02:21 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at
Received: from eugeni.torproject.org ([127.0.0.1])
by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 8Njwl-0BuAvp for <bad-relays@lists.torproject.org>;
Mon, 1 May 2023 18:02:21 +0000 (UTC)
Received: from acrey.alcretemic.com (acrey.alcretemic.com [208.77.145.122])
by eugeni.torproject.org (Postfix) with ESMTP id 15AD0E051F
for <bad-relays@lists.torproject.org>; Mon, 1 May 2023 18:02:20 +0000 (UTC)
From: "Lidl" <Admin@acrey.alcretemic.com>
To: bad-relays@lists.torproject.org
MIME-Version: 1.0
Message-Id: <LYRIS-i.c-__Date@acrey.alcretemic.com>
Date: Mon, 01 May 2023 14:02:13 -0400
Subject: [bad-relays] =?utf-8?q?HERZLICHEN_GL=C3=9CCKWUNSCH!_Sie_sind_der?=
=?utf-8?q?_gl=C3=BCckliche_Online-Gewinner_eines_brandneuen_Gewinnspiels_?=
=?utf-8?q?Monsieur_Cuisine_Connect!?=
X-BeenThere: bad-relays@lists.torproject.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions about malicious and misconfigured Tor relays
<bad-relays.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/bad-relays>,
<mailto:bad-relays-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <https://lists.torproject.org/cgi-bin/mailman/private/bad-relays/>
List-Post: <mailto:bad-relays@lists.torproject.org>
List-Help: <mailto:bad-relays-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/bad-relays>,
<mailto:bad-relays-request@lists.torproject.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1827440705681709861=="
Errors-To: bad-relays-bounces@lists.torproject.org
Sender: "bad-relays" <bad-relays-bounces@lists.torproject.org>
--===============1827440705681709861==
Content-Type: multipart/alternative; boundary="----=NextPart-dec270cb1eea73e35b74ae24a6eced6c"
------=NextPart-dec270cb1eea73e35b74ae24a6eced6c
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
text message
------=NextPart-dec270cb1eea73e35b74ae24a6eced6c
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
PGh0bWw+DQo8Ym9keT4NCgk8Y2VudGVyPg0KCQk8YSBzdHlsZT0iZGlzcGxheTpub25lOyIgaHJl
Zj0iaHR0cDovLzIzLTIyNy0xNzQtNjYuc3RhdGljLmh2dmMudXMvNE8wMTA1OW5pYTBpcDU4di1u
ZGZrMnIxcXpoMjR6Mzg0cjRicTAwMDAxIiA+LjwvYT4NCgkJPGEgaHJlZj0iaHR0cDovLzIzLTIy
Ny0xNzQtNjYuc3RhdGljLmh2dmMudXMvMU8wMTA1OW5pYTBpcDU4di1uZGZrMnIxcXpoMjR6Mzg0
cjRicTAwMDAxIiA+DQoJCQk8aDI+QmVlaWxlbiBTaWUgc2ljaCEgRGllIEJlbG9obnVuZ2VuIHNp
bmQgc2Nob24gZGEhPC9oMj4NCgkJPC9hPg0KCQk8YnIgLz4NCgkJPGEgaHJlZj0iaHR0cDovLzIz
LTIyNy0xNzQtNjYuc3RhdGljLmh2dmMudXMvMU8wMTA1OW5pYTBpcDU4di1uZGZrMnIxcXpoMjR6
Mzg0cjRicTAwMDAxIiA+DQoJCQk8aW1nIHNyYz0iaHR0cDovLzIzLTIyNy0xNzQtNjYuc3RhdGlj
Lmh2dmMudXMvMjAvNDYxNy8yMTIzMC9DYlVRYXJlS2Zwdy5qcGciPg0KCQk8L2E+DQoJCTxiciAv
Pg0KCQk8YSBocmVmPSJodHRwOi8vMjMtMjI3LTE3NC02Ni5zdGF0aWMuaHZ2Yy51cy8xTzAxMDU5
bmliMGlwNTh2LW5kZmsycjFxemgyNHozODRyNGJxMDAwMDEiID4NCgkJCTxpbWcgc3JjPSJodHRw
Oi8vMjMtMjI3LTE3NC02Ni5zdGF0aWMuaHZ2Yy51cy8yMC80NjE3LzIxMjMwL1VyTFlTT1dLci5q
cGciPg0KCQk8L2E+DQoJCTxiciAvPg0KCQk8YSBocmVmPSJodHRwOi8vMjMtMjI3LTE3NC02Ni5z
dGF0aWMuaHZ2Yy51cy8xTzAxMDU5bmljMGlwNTh2LW5kZmsycjFxemgyNHozODRyNGJxMDAwMDEi
ID4NCgkJCTxpbWcgc3JjPSJodHRwOi8vMjMtMjI3LTE3NC02Ni5zdGF0aWMuaHZ2Yy51cy84TzAx
MDU5bmlhMGlwNTh2LW5kZmsycjFxemgyNHozODRyNGJxMDAwMDEiPg0KCQk8L2E+DQoJCTxiciAv
Pg0KCTwvY2VudGVyPg0KPC9ib2R5Pg0KPC9odG1sPg==
------=NextPart-dec270cb1eea73e35b74ae24a6eced6c--
--===============1827440705681709861==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
bad-relays mailing list
bad-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/bad-relays
--===============1827440705681709861==--
```
/cc @gman999Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/tpa/status-site/-/issues/31Add another weather.tpo incident (down due issues after upgrading to Debian B...2023-11-08T16:13:42ZGeorg KoppenAdd another weather.tpo incident (down due issues after upgrading to Debian Bookworm)Tor Weather got busted in the wake of the Debian Bookworm upgrade and it's not clear yet what we can salvage. We should update the status page, though. See: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41388 for more context.Tor Weather got busted in the wake of the Debian Bookworm upgrade and it's not clear yet what we can salvage. We should update the status page, though. See: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41388 for more context.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42154Empty the clipboard on browser shutdown only if content comes from private br...2023-11-07T16:50:23Zcypherpunks1Empty the clipboard on browser shutdown only if content comes from private browsing windowsThe user may not expect or need this feature (#42019) and maybe it should additionally be disabled for non-private browsing mode.
One issue is that the clipboard is emptied even if its contents did not originate from a browser.The user may not expect or need this feature (#42019) and maybe it should additionally be disabled for non-private browsing mode.
One issue is that the clipboard is emptied even if its contents did not originate from a browser.ma1ma1https://gitlab.torproject.org/tpo/tpa/team/-/issues/41373please update my key in the TPA keyring2023-11-07T15:39:49Ziwakehplease update my key in the TPA keyringMy key is available here:
https://keys.openpgp.org/search?q=iwakeh%40torproject.org
or
https://pgp.mit.edu/pks/lookup?search=iwakeh%40torproject.org&op=index
Many thanks,
iwakehMy key is available here:
https://keys.openpgp.org/search?q=iwakeh%40torproject.org
or
https://pgp.mit.edu/pks/lookup?search=iwakeh%40torproject.org&op=index
Many thanks,
iwakehanarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41383Add al@ alias2023-11-07T12:53:36Zmicahmicah@torproject.orgAdd al@ aliasIt seems people write to al@torproject when they are meaning to write to smith@tor project. I know we have an alias for geko/gk, so maybe it would be nice to add an `al` one!It seems people write to al@torproject when they are meaning to write to smith@tor project. I know we have an alias for geko/gk, so maybe it would be nice to add an `al` one!Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41004Auto-build Tor + Mullvad Browsers on tag push2023-11-06T23:11:00ZrichardAuto-build Tor + Mullvad Browsers on tag pushWe chatted briefly last week about Mullvad somehow auto-building our browsers on tag push.
We would like to bring Mullvad into the build release verification process (eg as another builder) to give users further confidence that devs ar...We chatted briefly last week about Mullvad somehow auto-building our browsers on tag push.
We would like to bring Mullvad into the build release verification process (eg as another builder) to give users further confidence that devs are not collaborating to sneak malicious code into the build.
/cc @ruihildtjbjorkangjbjorkanghttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/41001Create Release Prep MR generating script2023-11-06T23:10:47ZrichardCreate Release Prep MR generating scriptOur release process is a giant checklist living in a gitlab template which, while nice and organized and cool, could be partially automated. The things we've enumerated include:
- [ ] translation hash updates
- [ ] dependency checking a...Our release process is a giant checklist living in a gitlab template which, while nice and organized and cool, could be partially automated. The things we've enumerated include:
- [ ] translation hash updates
- [ ] dependency checking and config updating for:
- [ ] noscript
- [ ] ublock
- [ ] mullvad extension
- [ ] openssl
- [ ] zlib
- [ ] tor
- [ ] go
- [ ] manual
- [ ] tor-browser
- [ ] geckoview
- [ ] *improved* changelog generation (eg include esr/geckoview updates, etc)
- [ ] qa + release emails
- [ ] website MR
- [ ] blog MRrichardrichardhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41554New Identity clears history even if history storage is enabled2023-11-06T23:08:01ZMike PerryNew Identity clears history even if history storage is enabledIf Tor Browser 12 is configured to store browsing history, New Identity now clears this history. This is unexpected, as we have always preserved history for people who enable that in the past. Because we do not render visited styles, his...If Tor Browser 12 is configured to store browsing history, New Identity now clears this history. This is unexpected, as we have always preserved history for people who enable that in the past. Because we do not render visited styles, history storage does not leak information to websites, so it does not need to be cleared in this case.
See also: https://gitlab.torproject.org/tpo/applications/team/-/issues/19
I am wondering if this is a side effect of re-implementing New Identity in the browser, as opposed to Torbutton? If we just naively switched to doing what Firefox does on "Clear all browser state", then we may also *not* be clearing some additional linkable state, or emitting events for extensions, and properly closing things like keep-alive connections, SSL state, blob urls, etc.
Torbutton's behavior on New Identity was formerly documented here: https://2019.www.torproject.org/projects/torbrowser/design/#new-identity.ma1ma1https://gitlab.torproject.org/tpo/tpa/team/-/issues/41381onionbalance-02 filling up swap2023-11-06T21:26:55Zanarcatonionbalance-02 filling up swap![image](/uploads/6d76950c3110ffcafe9a6816cdfcabdc/image.png)
https://grafana.torproject.org/d/amgrk2Qnk/memory-usage?orgId=1&from=now-1y&to=now&var-class=All&var-node=onionbalance-02.torproject.org
onionbalance-02 is not *quite* out of...![image](/uploads/6d76950c3110ffcafe9a6816cdfcabdc/image.png)
https://grafana.torproject.org/d/amgrk2Qnk/memory-usage?orgId=1&from=now-1y&to=now&var-class=All&var-node=onionbalance-02.torproject.org
onionbalance-02 is not *quite* out of memory, but it's getting pretty darn close. zooming into the last 30 days:
![image](/uploads/f9f08e80da67601dd5cabe3d15c40f7e/image.png)
https://grafana.torproject.org/d/amgrk2Qnk/memory-usage?orgId=1&from=now-30d&to=now&var-class=All&var-node=onionbalance-02.torproject.org
it shows the app usage converging to about 2GB ... maybe we can just add more ram to that one?
i don't actually knows who owns this service, @tpo/tpa? it's not even documented in our service list (!).Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42222Fix TorDomainIsolator initialization on Android2023-11-06T20:47:38ZPier Angelo VendrameFix TorDomainIsolator initialization on AndroidIn TBA 13.0aX and 13.0.X (until 13.0.2) the domain isolator is not being initialized incorrectly.
It seems the `TorStartupService` isn't being loaded (even though I'm quite sure it looks like exactly the one we had in Torbutton).
I don...In TBA 13.0aX and 13.0.X (until 13.0.2) the domain isolator is not being initialized incorrectly.
It seems the `TorStartupService` isn't being loaded (even though I'm quite sure it looks like exactly the one we had in Torbutton).
I don't know if it's due to the XPCOM changes that happened between 102 and 115, or if it's just because of the various refactors.
Since we don't have a circuit display, the only way to notice this is going to different sites that show the IP address, and notice that they have the same one, but we'd expect them to be isolated.
Some Tor-friendly ones are:
- https://check.torproject.org/
- https://www.wtfismyip.com/
- https://myip.wtf/ (same as the previous one, but different FP domain for TBB :smile:)
- https://mullvad.net/en/check
When we finally start working on tests we should also have a test that checks circuit FPI.Pier Angelo VendramePier Angelo Vendramehttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41382BTC PayServer offline?2023-11-06T19:02:59ZmattlavBTC PayServer offline?Got a [RT ticket](https://rt.torproject.org/Ticket/Display.html?id=318472) today indicating that our BTC PayServer is offline; @smith checked and confirmed this is the case. That's about all I know about it; we need this running in order...Got a [RT ticket](https://rt.torproject.org/Ticket/Display.html?id=318472) today indicating that our BTC PayServer is offline; @smith checked and confirmed this is the case. That's about all I know about it; we need this running in order to accept cryptodonations, so I'm making a ticket here. Let me know any way I can be useful -Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/web/donate-static/-/issues/134BTC PayServer offline?2023-11-06T19:01:15ZmattlavBTC PayServer offline?Got a [RT ticket](https://rt.torproject.org/Ticket/Display.html?id=318472) today indicating that our BTC PayServer is offline; @smith checked and confirmed this is the case. That's about all I know about it; we need this running in order...Got a [RT ticket](https://rt.torproject.org/Ticket/Display.html?id=318472) today indicating that our BTC PayServer is offline; @smith checked and confirmed this is the case. That's about all I know about it; we need this running in order to accept cryptodonations, so I'm making a ticket here. Let me know any way I can be useful -Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40830Non-fatal assertion now >= leg->link_sent_usec failed2023-11-06T14:50:08ZVortNon-fatal assertion now >= leg->link_sent_usec failed### Summary
Sometimes I see such lines in log:
```
Aug 03 03:40:28.000 [warn] tor_bug_occurred_: Bug: conflux_pool.c:828: record_rtt_client: Non-fatal assertion now >= leg->link_sent_usec failed. (on Tor 0.4.8.2-alpha 328f976245134501)
...### Summary
Sometimes I see such lines in log:
```
Aug 03 03:40:28.000 [warn] tor_bug_occurred_: Bug: conflux_pool.c:828: record_rtt_client: Non-fatal assertion now >= leg->link_sent_usec failed. (on Tor 0.4.8.2-alpha 328f976245134501)
Aug 03 03:40:28.000 [warn] Bug: Tor 0.4.8.2-alpha (git-328f976245134501): Non-fatal assertion now >= leg->link_sent_usec failed in record_rtt_client at conflux_pool.c:828. (Stack trace not available) (on Tor 0.4.8.2-alpha 328f976245134501)
```
### Steps to reproduce:
Looks like it appears randomly.
However I have ntpd installed, maybe it interferes with Tor somehow.
### What is the current bug behavior?
Error shows.
### What is the expected behavior?
No error.
### Environment
_- Which version of Tor are you using?_
Tor 0.4.8.2-alpha (git-328f976245134501) running on Windows 7 with Libevent 2.1.12-stable, OpenSSL 3.0.8, Zlib 1.2.13, Liblzma 5.4.1, Libzstd 1.5.4 and Unknown N/A as libc.
_- Which operating system are you using?_
Windows 7 SP1 x64
_- Which installation method did you use?_
I built Tor from sources.
### Relevant logs and/or screenshots
I saw such problem two more times:
```
Jul 24 03:15:14.000 [warn] tor_bug_occurred_: Bug: conflux_pool.c:828: record_rtt_client: Non-fatal assertion now >= leg->link_sent_usec failed. (on Tor 0.4.8.2-alpha 328f976245134501)
Jul 24 03:15:14.000 [warn] Bug: Tor 0.4.8.2-alpha (git-328f976245134501): Non-fatal assertion now >= leg->link_sent_usec failed in record_rtt_client at conflux_pool.c:828. (Stack trace not available) (on Tor 0.4.8.2-alpha 328f976245134501)
...
Jul 24 18:16:48.000 [warn] tor_bug_occurred_: Bug: conflux_pool.c:828: record_rtt_client: Non-fatal assertion now >= leg->link_sent_usec failed. (on Tor 0.4.8.2-alpha 328f976245134501)
Jul 24 18:16:48.000 [warn] Bug: Tor 0.4.8.2-alpha (git-328f976245134501): Non-fatal assertion now >= leg->link_sent_usec failed in record_rtt_client at conflux_pool.c:828. (Stack trace not available) (on Tor 0.4.8.2-alpha 328f976245134501)
```
### Possible fixeshttps://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/issues/55@gettor_bot on Telegram does not work2023-11-06T12:01:00Znina@gettor_bot on Telegram does not workIt does not react to the commands.
Reported by two users and confirmed by meIt does not react to the commands.
Reported by two users and confirmed by memeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/169Check `Token` header instead of `Cookie` header from rdsys2023-11-06T08:36:47ZjugaCheck `Token` header instead of `Cookie` header from rdsysIn #162 we decided that onbrisca authorizes the requests via a token in `Cookie` header, however tpo/anti-censorship/rdsys#174 doesn't set it with the `Cookie` header but the `Token` and `Authorization` headers. Therefore onbrisca has al...In #162 we decided that onbrisca authorizes the requests via a token in `Cookie` header, however tpo/anti-censorship/rdsys#174 doesn't set it with the `Cookie` header but the `Token` and `Authorization` headers. Therefore onbrisca has already been changed in production to look at these header instead to authorize the request.jugajugahttps://gitlab.torproject.org/tpo/community/support/-/issues/40129Update Forum guide:"Tor blocked in Russia - how to circumvent censorship"2023-11-04T02:03:55ZGusUpdate Forum guide:"Tor blocked in Russia - how to circumvent censorship"Let's review and update the Forum guide "Tor blocked in Russia - how to circumvent censorship".
https://forum.torproject.org/t/tor-blocked-in-russia-how-to-circumvent-censorship/982Let's review and update the Forum guide "Tor blocked in Russia - how to circumvent censorship".
https://forum.torproject.org/t/tor-blocked-in-russia-how-to-circumvent-censorship/982ninaninahttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41377Install golang compiler in rdsys-test-012023-11-03T09:45:47Zmeskiomeskio@torproject.orgInstall golang compiler in rdsys-test-01We'll need to compile the rdsys binaries on that machine. Can we get golang installed there?We'll need to compile the rdsys binaries on that machine. Can we get golang installed there?anarcatanarcathttps://gitlab.torproject.org/tpo/core/tor/-/issues/40730TROVE-2022-002: The SafeSocks option for SOCKS4(a) is inverted leading to SOC...2023-11-02T18:55:30ZDavid Gouletdgoulet@torproject.orgTROVE-2022-002: The SafeSocks option for SOCKS4(a) is inverted leading to SOCKS4 going throughThis is a report from hackerone: https://hackerone.com/bugs?subject=torproject&report_id=1784589
Below is the content of the report which has detailed information.
We have classified this as `medium` considering that tor was not defend...This is a report from hackerone: https://hackerone.com/bugs?subject=torproject&report_id=1784589
Below is the content of the report which has detailed information.
We have classified this as `medium` considering that tor was not defending in-depth for dangerous SOCKS request and so any user relying on `SafeSocks 1` to make sure they don't link DNS leak and their Tor traffic wasn't safe afterall for `SOCKS4(a)`.
Tor Browser doesn't use `SafeSocks 1` and SOCKS4 so at least the likely vast majority of users are not affected.
# H1 Report
## Summary:
This bug appears to be a typo; [src/core/proto/proto_socks.c, process_socks4_request()](https://gitweb.torproject.org/tor.git/tree/src/core/proto/proto_socks.c?h=tor-0.4.7.11#n236) contains the line:
` if (is_socks4a && !addressmap_have_mapping(req->address, 0)) {`
Which presumably should be `!is_socks4a`. The following logic appears correct only if that change is made; as it exists now, the check is inverted and only warns on and rejects safe SOCKS4a requests.
## Steps To Reproduce:
1. Configure Tor with SafeSocks set to 1 (listening on localhost, with default port 9050)
1. Perform an unsafe SOCKS4 request; e.g., with socat: `echo -en "HEAD / HTTP/1.1\r\nHost: duckduckgo.com\r\n\r\n" | socat -v STDIO SOCKS4:127.0.0.1:duckduckgo.com:80,socksport=9050,shut-none`
Note that the locally-performed DNS request is leaked, and only the server IP is sent to Tor, but Tor does not block the request as it should have. The request reaches the server, and Tor does not log that a DNS leak may have occurred.
1. Perform a safe SOCKS4a request: `echo -en "HEAD / HTTP/1.1\r\nHost: duckduckgo.com\r\n\r\n" | socat -v STDIO SOCKS4a:127.0.0.1:duckduckgo.com:80,socksport=9050,shut-none`
Note that the domain is being sent to Tor, but Tor incorrectly blocks the request, and logs an incorrect "Your application (using socks4 to port 80) is giving Tor only an IP address." error.
The check is inverted; when using SOCKS4/SOCKS4a, SafeSocks 1 does the exact opposite of what it should, ensuring the user is making only unsafe requests. I have not tested SOCKS5, though it presumably works correctly given TorBrowser uses it.
## Additional info:
I tested this on Tor versions 0.4.7.10 and 0.4.5.10; git history suggests this has been broken all the way back to 0.3.5, seems to have been introduced in a rewrite, merge commit 7556933537b5777a9bef21230bb91a08aa70d60e, see https://gitweb.torproject.org/user/nickm/tor.git/commit/src/or/proto_socks.c?h=socks_trunnel4_squashed_merged&id=9155e08450fe7a609f8223202e8aa7dfbca20a6d
The commands above were run using Bash and socat, and this bug had been discovered while using a custom SOCKS4a application.
## Impact
Impact is a DNS leak that occurs under a configuration intended to guard against such a possibility. That configuration is not under attacker control, but users who believe they need this protection may be more likely to turn on the broken config option.
2 scenarios are plausible, that impact user anonymity by leaking DNS traffic with SafeSocks 1:
1. Users configuring SOCKS4 apps that don't support SOCKS4a will be led to believe their traffic is fully secured, when in fact DNS requests are still being leaked.
1. Users configuring apps that do support SOCKS4a could be misled into selecting SOCKS4 instead, as Tor will error out if they try to use the safe configuration; this could conceivably create a DNS leak where one need not exist.
It should also be noted that the incorrect warning does still get printed even with SafeSocks 0, but it does not cause any otherwise-visible problems.
Note that users will only be impacted if they connect using SOCKS4, and rely on SafeSocks to protect against DNS leaks. SafeSocks 1 is recommended in a number of online guides to securing Tor. The application I was working on when I discovered this also relied on it as a defense-in-depth measure. I nevertheless suspect SOCKS4a may be a rare configuration, given this bug seems to have existed for about 4 years without detection.Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41376Update howto/postgresql recovery procedure2023-11-02T18:49:34ZJérôme Charaouilavamind@torproject.orgUpdate howto/postgresql recovery procedureThe current recovery steps in the wiki don't work for PostgreSQL version 12 and later.
This is because `recovery.conf` in the database directory is no longer supported. The `restore_command` config must be placed in `postgresql.conf`.
...The current recovery steps in the wiki don't work for PostgreSQL version 12 and later.
This is because `recovery.conf` in the database directory is no longer supported. The `restore_command` config must be placed in `postgresql.conf`.
```
Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30565-1] LOG: starting PostgreSQL 15.3 (Debian 15.3-0+deb12u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30565-2] LOG: listening on IPv4 address "0.0.0.0", port 5432 Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30565-3] LOG: listening on IPv6 address "::", port 5432
Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30565-4] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30568-1] LOG: database system was interrupted; last known up at 2023-11-01 18:52:52 UTC
Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30568-2] FATAL: using recovery command file "recovery.conf" is not supported
Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30565-5] LOG: startup process (PID 30568) exited with exit code 1
Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30565-6] LOG: aborting startup due to startup process failure
Nov 01 22:25:43 rude postgresql@15-main[30560]: 2023-11-01 22:25:43 UTC [30565-7] LOG: database system is shut down
```
From the [12.0 release notes](https://www.postgresql.org/docs/release/12.0/):
> recovery.conf is no longer used, and the server will not start if that file exists. recovery.signal and standby.signal files are now used to switch into non-primary mode.
In addition, after adding the restore directive, a `restore.signal` file must be create din the database directory to trigger the recovery process.
```
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31203-1] LOG: starting PostgreSQL 15.3 (Debian 15.3-0+deb12u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31203-2] LOG: listening on IPv4 address "0.0.0.0", port 5432
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31203-3] LOG: listening on IPv6 address "::", port 5432
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31203-4] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31206-1] LOG: database system was interrupted; last known up at 2023-11-01 18:52:52 UTC
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31206-2] LOG: invalid checkpoint record
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31206-3] FATAL: could not locate required checkpoint record
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31206-4] HINT: If you are restoring from a backup, touch "/var/lib/postgresql/15/main/recovery.signal" and add required recovery options.
Nov 01 22:33:31 rude postgresql@15-main[31198]: If you are not restoring from a backup, try removing the file "/var/lib/postgresql/15/main/backup_label".
Nov 01 22:33:31 rude postgresql@15-main[31198]: Be careful: removing "/var/lib/postgresql/15/main/backup_label" will result in a corrupt cluster if restoring from a backup.
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31203-5] LOG: startup process (PID 31206) exited with exit code 1
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31203-6] LOG: aborting startup due to startup process failure
Nov 01 22:33:31 rude postgresql@15-main[31198]: 2023-11-01 22:33:31 UTC [31203-7] LOG: database system is shut down
```Debian 12 bookworm upgradeJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org