[tor-dev] Re: Make torsocks mutli-arch ready

2025-03-26 Thread Jim Newsome via tor-dev
On 3/26/25 7:45 PM, Hefee wrote: Hey, This looks basically ok to me. More below: thx for this fast reply! Sorry I'm a little bit busy the last days... Btw. would it be possible to ship a new release the next days? So I can push this new version to Debian trixie? As the soft freeze is happe

[tor-dev] Re: Make torsocks mutli-arch ready

2025-03-12 Thread Jim Newsome via tor-dev
This looks basically ok to me. More below: On 3/10/25 8:50 AM, Hefee via tor-dev wrote: 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.: torso

Re: [tor-dev] Proposal 351: Making SOCKS5 authentication extensions extensible

2024-09-10 Thread Jim Newsome
It'd be helpful to have more context about the object IDs and what we're trying to accomplish with them here; why we need/want them in arti but didn't in c-tor. I'm inferring (maybe incorrectly) that the idea is that this is effectively letting us multiplex differently-configured SOCKS->Tor ser

Re: [tor-dev] Proposal 338: Use an 8-byte handshake in NETINFO cells

2022-03-20 Thread Jim Newsome
On 3/14/22 14:40, Nick Mathewson wrote: On Mon, Mar 14, 2022 at 3:18 PM Jim Newsome <mailto:jnews...@torproject.org>> wrote: On 3/14/22 11:44, Nick Mathewson wrote:  > Currently Tor relays use a 4-byte timestamp (in seconds since the Unix  > epoch) i

Re: [tor-dev] Proposal 338: Use an 8-byte handshake in NETINFO cells

2022-03-20 Thread Jim Newsome
On 3/14/22 11:44, Nick Mathewson wrote: > Currently Tor relays use a 4-byte timestamp (in seconds since the Unix > epoch) in their NETINFO cells. Notoriously, such a timestamp will > overflow on 19 January 2038. > > Let's get ahead of the problem and squash this issue now, by expanding > the t

Re: [tor-dev] Proposal 328: Make Relays Report When They Are Overloaded

2020-12-11 Thread Jim Newsome
On 12/11/20 08:04, David Goulet wrote: > we are talking a good 2-4 > years minimum once the feature is stable thus we have to get this out soon if > we hope to be useful in the foreseeable future. Right - the slow feedback cycle of deploying between deploying new logging and trying to use it is

Re: [tor-dev] Proposal 328: Make Relays Report When They Are Overloaded

2020-12-09 Thread Jim Newsome
On 12/7/20 14:06, David Goulet wrote: > Greetings, > > Attached is a proposal from Mike Perry and I. Merge requsest is here: > > https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/22 Disclaimer - As someone not very familiar with how tor load balancing works today, I might not be the

Re: [tor-dev] [RFC] Proposal: A First Take at PoW Over Introduction Circuits

2020-09-24 Thread Jim Newsome
On 9/22/20 07:10, George Kadianakis wrote: > George Kadianakis writes: > >> tevador writes: >> >>> Hi all, >>> > Hello, > > I have pushed another update to the PoW proposal here: > https://github.com/asn-d6/torspec/tree/pow-over-intro > I also (finally) merged it upstream to torspec as proposa

Re: [tor-dev] Using linux perf tool to look at sleep times

2020-08-31 Thread Jim Newsome
cc tor-dev for real this time :) On 8/31/20 17:23, Jim Newsome wrote: > Hi David, (cc tor-dev in case others are interested or know anything > about it) > > I'm told you're the local expert on the linux perf tool :). I'm using it > to profile sleep times in Shado