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

[Alec Muffett <alec.muffett@xxxxxxxxx>]

Hello Grarpamp!

On 3 January 2017 at 07:32, grarpamp <grarpamp@xxxxxxxxx> wrote:

> On Mon, Jan 2, 2017 at 9:04 PM, Alec Muffett <alec.muffett@xxxxxxxxx>
> wrote:
> > Before getting down to details, I hate to have to cite this but I have
> been
> > [...] not "normal", and I suspect the same can be said of anyone
>
> There are many other similar non normals, that is a good thing.
>

Oh yes - and I am not saying that there is anything wrong with having a
community of technical experts who bicker amongst themselves about fine
details; but I am pretty confident, experientially, that exposure to that
manner of thing is generally off-putting for people who have heard of Tor
and wish to "try it out".

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

> Given the (less than corporate-sized) resources at Tor's disposal
>
> There is no fooling people who have been around the block more than
> once. Tor Project Inc has plainly demonstrated itself as fully
> corporatized.
>

Aw, bless; I said "corporate sized resources", not "corporatized".   I just
left Facebook, forgive me.



> And it has substantial monetary and other strategic resources that would
> make other projects in the space cry.


Oh, I am certain you are right - I help out at ORG, likewise a non-profit -
but such does not preclude that much can be done:

- to make Tor more accessible

- to more people

- and thereby more important.


> Tor is
> > security-sensitive software with a bullseye target painted on its
> forehead,
>
> "OpenSSL" is security-sensitive software with ...
> "kernel" is ...
> "*" is ...
>

That's a very fair point you are making - all of the code in the trusted
computing base is critical.

But I think you are actually making my point for me, though:

* If all of the code (that goes into a Debian installation) is safety
critical,

* 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.


Linux distro model has imparted a brokenverse upon itself and its users.
>

Yes, I agree, and I see this may be one way to help mitigate against that.


> "torsocks" - a tool
> > which will become more critical for server-side adoption, real soon now -
>
> Why more crit rsn?, it's always been a useful tool.
>

Good question!

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
end, the client end, will largely comprise human beings who are competent
to poke bits of "netcat" into their ssh-configs, etc.

A few months ago someone posted a cute VMS instance on a Telnet port
attached to an onion address; the amount of work that would have been
necessary to hack a connection to the service (messing around with telnet,
fetching and setting up socat as a port forwarder) would have rather killed
the fun; so I tried runsocks, found it was out of date, and had to go down
the "backports" rabbit hole.

I agree with what you say - it's always been useful; but (just as with Tor)
the versions are wildly out of whack in various distributions, and are not
always up to date with respect to the current "tor" build, even.

Having torsocks (as a "universal client") exist separate from the main
"tor" binary, rather than in lockstep, is a bit messy. If onion networking
is to expand - as I think it will - then it will be key to have easy access
to a tool which patches around the lack of AF_ONION in the kernel socket
space.


In fact, both tools are critical for case of helping mass adoption
> and applications. However one of them is about to be hard killed
> off with no thought or effort to refresh or replace its functionality.
>

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


     -a


-- 
http://dropsafe.crypticide.com/aboutalecm
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk