[tor-talk] Possibly Smart, Possibly Stupid, Idea Regarding Tor & Linux Distributions

[grarpamp]

On Tue, Jan 3, 2017 at 5:04 AM, Alec Muffett <alec.muffett at gmail.com> wrote:
> community of technical experts who bicker amongst themselves about fine

Maybe they, or even we, are few who can do that philosophy freely.
There is but good and no fault there.

> details [...] exposure to that
> manner of thing is generally off-putting for people who have heard of Tor
> and wish to "try it out".

Well this isn't really a forum for mass users, if Tor Corp wanted a mass
forum, which is interesting possibility, it would create a "forum" for them.
"Forums" suck balls for technical reasons, but it could be a win.

> Disclosure: I am mostly talking about journalists with a technical bent,
> and lawyers, and people with "alternative" lifestyles; plus a few teachers.

I welcome these users, all users, to any overlay system,
for whatever their use case.

> Aw, bless; I said "corporate sized resources", not "corporatized".

Well sure there are orders of magnitude involved, but one should
not mistake certain structures and operative methods.

> but such does not preclude that much can be done:
> - to make Tor more accessible
> - to more people
> - and thereby more important.

Right. Except you know I see development diversity value in the
same for other anon overlay systems, be they extant or upcoming.
ie: tor is rather done model these days, and not end all be all.

> But I think you are actually making my point for me, though:
>
> * then if Tor can avoid stagnant tor code from being shipped with Debian
> for (guessing) 75+% of the lifecycle of "Debian Stretch"
>
> * should it not take that opportunity to make an incremental improvement to
> the world's installed base, by moving Debian software repos entirely
> in-house?
>
> It looks to me to be easier to explain, easier and more consistent to
> install, and more likely to be updated, if tor (the software) moves
> entirely to being under Tor's aegis.
>
> Overall, this would be (marginally) better security for the installed base
> of the world, for modest outlay.

I guess that was the bit about distributing static binaries of Tor.

If I recall, tor used to make rpms for some OS or another,
but then reached effective partnership and/or was satisfied with
current versions and discontinued the tor rpms. This was
maybe two years ago.

Tor could probably pay a $10-25k stipend to provide statics
for all OS if it wanted to.

> It's my opinion of course, but Tor is very geared-up for one thing - relays
> and/or onion web/poty reverse-proxying - with the assumption that the other

Tor is definitely web viewing centric at its roots. Yet does not
web viewing make mass protocol share. Now who will pick up
other (or the full) proto set?

> to poke bits of "netcat" into their ssh-configs, etc.
> fetching and setting up socat as a port forwarder) would have rather killed

tortel () { socat -d -d -,ignoreeof
socks4a:127.0.0.1:${1%%:*}:${1##*:},socksport=9050 ; }

Still hoping socks5 gets fully implemented in socat rsn ...

> the versions are wildly out of whack in various distributions, and are not

Didn't look, some are probably still previous generation.

> Having torsocks (as a "universal client") exist separate from the main
> "tor" binary, rather than in lockstep, is a bit messy.

It sortof was/is included as 'torify'. But then you'd have to consider
shipping OnionCat, Stem, etc as well.

> to a tool which patches around the lack of AF_ONION in the kernel socket

AF_ONION would be amazing. As would AF_*.
All being a few delicious kernel modules away...

> Yep, it sucks when that happens, but sometimes change is necessary.

Prop224 is necessary, or at least prudent, killing off users
of tools without providing even non-ideal hackish interim
replacements is not.