tor-dev

tor-dev@lists.torproject.org

1 participants
3590 discussions

can tor use secondary groups to read FamilyKeyDirectory?
by nusenu 03 Apr '25

03 Apr '25

Hi, given the following example, tor fails to access the familykeydir folder. familykeydir has the following permissions: drwxr-x--- 2 root tor_reader id _tor uid=996(_tor) gid=993(_tor) groups=993(_tor),994(tor_reader) Is tor able to use secondary groups? When using sudo to switch to user _tor manually, it is possible to read files in that folder without problems. The problem does not happen when _tor's primary group is set to 'tor_reader'. Tested on debian. kind regards, nusenu -- https://nusenu.github.io

1 0

Proposal 358: Unifying circuit handshake extensions
by Nick Mathewson 27 Mar '25

27 Mar '25

https://spec.torproject.org/proposals/358-unified-handshake-extensions.html This proposal suggests that we should unify the EXT_FIELD_TYPE namespace, which is currently shared between CREATE2 and INTRODUCE2 messages. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick

1 0

Proposal 357: Circuit key exporters: A better way to use KH
by Nick Mathewson 27 Mar '25

27 Mar '25

https://spec.torproject.org/proposals/357-circ-key-exporters.html This proposal declares a new way to use the "KH" output of our circuit handshake protocol in the future, to avoid the possibility of creating cross-protocol attacks. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick

1 0

Proposal 356: Increasing netdoc strictness not considered (very) harmful
by Nick Mathewson 27 Mar '25

27 Mar '25

https://spec.torproject.org/proposals/356-desc-parsing-variance.html This proposal explains why we will not, in the future, generally worry about protocol changes that make strings that were formerly accepted as network documents become rejected in future versions. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick

1 0

Proposal 355: Options for postquantum circuit extension handshakes
by Nick Mathewson 27 Mar '25

27 Mar '25

https://spec.torproject.org/proposals/355-revisiting-pq.html This proposal updates earlier proposals about postquantum cryptography in Tor circuit extensions, to handle changes in Tor and the PQ landscape since those proposals were written. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! cheers, -- Nick

1 0

Make torsocks mutli-arch ready
by Hefee 27 Mar '25

27 Mar '25

Hey, in Debian we want to enable mutli-arch support for torsocks. To be able to run different binaries of different archs. We already splitted libtorsocks into own package, so you can now install e.g.: torsocks:amd64, libtorsocks:amd64, libtorsocks:i386, wget:i386 But the torsocks script loads the libtorsocks by full path, so torsocks wget will fail, as it loads the amd64 variant only. ldconfig has this nice feature to find the correct library, if you only add the name and that the library … [View More]

2 4

Proposal 354: Relaxing Path Restrictions in Arti
by Mike Perry 05 Mar '25

05 Mar '25

https://spec.torproject.org/proposals/354-relaxed-restrictions.html This is a proposal to simplify the usage of Family, Subnet, and custom path restrictions in Arti, so that clients don't reveal information about their Guards or Bridges by way of which relays they use, or don't use, in circuits. The meat of the proposal is that Arti's circuit path construction will satisfy the following rules: 1. Choose the Exit, HSDir, IP, or RP without considering restrictions 2. Choose Guard, Bridge, … [View More]

1 0

About the key derivation algorithm used in the Control Port password authentication
by techmetx11 04 Mar '25

04 Mar '25

Although several parts of Tor have been redesigned and upgraded over many years, the algorithm for the HashedControlPassword still remained the same. It still uses SHA-1 as the basis of the OpenPGP S2K algorithm, despite the fact that the algorithm has long-since been obsolete by newer and better hashing algorithms (on top of it, has had some practical collision attacks[1]). This is made worse by the fact that the S2K algorithm is not iterative (in the sense of recursive hashing), but rather … [View More]

2 1

Metadata Cleaner is looking for a new co-maintainer
by intrigeri 23 Jan '25

23 Jan '25

Hi, Many files contain hidden data, or metadata: * JPEG and other image files often contain information about where a picture was taken and which camera was used. * Office documents often contain information about their author, the date and time the document was created, as well as the complete changes history. To help you remove those metadata, Tails include Metadata Cleaner, a tool to remove metadata in a wide range of file formats: https://metadatacleaner.romainvigier.… [View More]

1 0

New BUG() call and stack-trace seen in the wild on 0.4.8.13 exit relay.
by George Hartley 16 Nov '24

16 Nov '24

Hi, I noticed the following when checking journalctl logs from Tor: > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] tor_bug_occurred_(): Bug: src/core/or/relay.c:2354: connection_edge_package_raw_inbuf: Non-fatal assertion !(conn->base_.marked_for_close) failed. (on Tor 0.4.8.13 )Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: Tor 0.4.8.13: Non-fatal assertion !(conn->base_.marked_for_close) failed in connection_edge_package_raw_inbuf at src/core/or/… [View More]relay.c:2354. Stack trace: (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/bin/tor(+0x1c8c5d) [0x62048e493c5d] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/bin/tor(+0x94325) [0x62048e35f325] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/bin/tor(+0x4335f) [0x62048e30e35f] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/bin/tor(+0x11afa6) [0x62048e3e5fa6] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/bin/tor(+0x10e8a2) [0x62048e3d98a2] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/lib/libevent-2.1.so.7(+0x22b42) [0x7488c6f57b42] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/lib/libevent-2.1.so.7(event_base_loop+0x4ff) [0x7488c6f593af] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/bin/tor(+0xd3da) [0x62048e2d83da] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/bin/tor(+0xa947) [0x62048e2d5947] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/lib/libc.so.6(+0x25e08) [0x7488c6527e08] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/lib/libc.so.6(__libc_start_main+0x8c) [0x7488c6527ecc] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] Bug: /usr/bin/tor(+0xba25) [0x62048e2d6a25] (on Tor 0.4.8.13 ) > Nov 13 19:51:10 matrix tor[615]: Nov 13 19:51:10.000 [warn] connection_edge_package_raw_inbuf(): Bug: called on conn that's already marked for close at src/core/or/relay.c:1870. (on Tor 0.4.8.13 ) I didn't have the time to actually look at the function in question, and I also left my Gitlab authenticator device (fully encrypted) at a friends / colleagues place, otherwise I would have likely opened a Gitlab ticket, given I figured out the actual bug behind it, if any. However, as I am unable right now and also not at my usual workplace, I included tor-dev in the recipients. Thanks. -GH [View Less]

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev