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

[Jeremy Rand]

Alec Muffett:
> In my previous e-mail I suggested removing Tor from Debian precisely
> because of this future-staleness problem.
> 
> I still believe that this is a decent idea, because stale code sucks.
> 
> Another possible solution would be creation of a "Tor Server Bundle" -
> designed and maintained to run successfully on most major platforms, it
> would be a bunch of scripts that find existing, stale versions of Tor, kill
> and remove them, and migrate the platform to a more recent version, with
> *optional* enabling of auto-updating because you will want to have a stable
> environment. :-P
> 
> And it would (ideally) also ship with some portable, stupid but bombproof,
> interactive and scriptable CLI wizards for setting up Onion services.

I won't claim to know whether this is a good idea, but one other option
is to only have Tor in Debian Sid.  My understanding is that this is
already done for some Bitcoin-related software, because the Bitcoin
packagers refused to guarantee that their packages would work through
testing/stable's lifespans (due to the chance that consensus forks will
break old clients, which has happened before and could easily happen
again).  It seems plausible that a similar path could work for Tor.

Cheers,
-Jeremy



signature.asc
Description: OpenPGP digital signature
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

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

[grarpamp]

On Wed, Jan 4, 2017 at 3:13 PM, Alec Muffett  wrote:
> On 4 January 2017 at 19:39, grarpamp  wrote:
>
>> > But me, I want to get _everybody_ - teachers, journalists, kids,
>> everyone.
>>
>> Absolutely. Same for whatever functions other overlay networks are
>> good at too. Yet at least with tor, how will that happen when it is
>> restricted to strictly TCP and onion addressing?
>
> Answer: "incrementally".
> We're are not, and I think should not, attempt to replace the internet.
> Just augment it.  Add value.  Make it more interesting, diverse and fun.

Replacement would require knowledge interest support and participation
in individually owned and p2p connected guerrilla networking by the masses.
So shall we physically say till then (excepting local community versions
of that) we attempt to use internet overlays instead, of which CJDNS,
I2P etc may be an example.
Then we think of not replacing the internet but replicating it.
There is codewise replication, ie: dotted quad / IP, C / Java, ...
And functional replication, ie: categories of uses / cases
and analogs... messaging, storage, publication, etc.

> Just augment it.  Add value.  Make it more interesting, diverse and fun.

Yes codewise is not required. Yet to achieve this, functional may
likely be required. Then what do your code choices limit there?
What is one person's value, interest, diverse, fun? Same as another's?
And how do you scale it when even one fun app becomes a hit.
Tor probably can't support a Candy Crush worth of users.
So do you purposefully limit it, nullifying the "_everybody_" goal?

The augmentation and v.i.d.f. are surely beginning to be present.
And will continue to happen as overlay networks progress :)

https://en.wikipedia.org/wiki/Instant_messaging#Statistics
https://en.wikipedia.org/wiki/List_of_virtual_communities_with_more_than_100_million_active_users
https://en.wikipedia.org/wiki/List_of_virtual_communities_with_more_than_1_million_users
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

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

[grarpamp]

On Wed, Jan 4, 2017 at 8:29 AM, Sebastian Hahn  wrote:
>> On 04 Jan 2017, at 12:24, Alec Muffett  wrote:

>> Large chunks of the Tor community are focused on Tor's primary purpose as
>> an anonymising proxy, and that's very, very important.
>>
>> It is Tor's primary and best-understood, to provide people with a secure
>> and generally anonymized means to connect to cleartext websites.
>>
>> But (subjective opinion) I think the future of Tor is in disintermediated
>> networking.  I think the future is in onions.
>
> I think onions will either be the future or the downfall of Tor. We will see
> which one of these it'll be :)

Remember, tor's onion services were an early yet subsequent happenstance
that piggybacked on tor's already developed primary clearnet access case,
architecture and deployment. We all recognize the need for two things
1) clearnet access strategies, perhaps as largely represented by tor today
2) private / hidden / p2p services ecosystems

Under that realization, and developing / choosing best to suit needs,
it really doesn't matter if one application (tor) does them both or not.
So the use of 'future' or 'downfall' is not really a fairly applicable or
expectable terminology there. Forking / pathfinding of ideas / code
for best fitment is not shameful, it's necessary.

For all we know I2P or some other overlay will rise to serve (2).
Perhaps IETF will RFC for all physical links and chips being
point-to-point encrypted per link with full time background fill traffic.
Perhaps... lots of things to come we cannot predict yet.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

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

[Alec Muffett]

On 4 January 2017 at 19:39, grarpamp  wrote:

> > But me, I want to get _everybody_ - teachers, journalists, kids,
> everyone.
>
> Absolutely. Same for whatever functions other overlay networks are
> good at too. Yet at least with tor, how will that happen when it is
> restricted to strictly TCP and onion addressing?


Answer: "incrementally".

We're are not, and I think should not, attempt to replace the internet.

Just augment it.  Add value.  Make it more interesting, diverse and fun.

-alec

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

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

[grarpamp]

On Wed, Jan 4, 2017 at 6:24 AM, Alec Muffett  wrote:
> Aside: this was part of why we drunken reprobates were doing this stuff at
> 33c3 -- https://twitter.com/FiloSottile/status/814641733212536832 --

Some dreprobs in the onions have been doing this for years with OnionCat.
Or with plain onions if they use unidirectional channels, or before ocat.
People have posted tests/reports/performance to the list now and then
over the years. Text, audio, video has long been possible subject only
to the weather of your [engineered|random] circuit and the bitrate
selected.

+1 to everyone playing with these things.

> I want people to be able to use stuff like this (piece of crap, but it's
> just a proof of concept) https://github.com/alecmuffett/videonion - using
> onions to communicate directly with one-another.

> I want other people to have an easier time innovating with onions.

> I want everyone to have the opportunity to connect without an intermediary,
> if they choose.  It would be nice to have the option. :-)

> But me, I want to get _everybody_ - teachers, journalists, kids, everyone.

Absolutely. Same for whatever functions other overlay networks are
good at too. Yet at least with tor, how will that happen when it is
restricted to strictly TCP and onion addressing? Is this all the world
is made of? And just how limiting is that to development of varying
apps, particularly P2P and the stacks required for it?

Even if we had AF_*, we could hardly call it a solution for it will
take many years for the appplications and their protocols to
be patched and enhanced to use it.

> Or we can leave everything at the status quo, and just muddle along

In some areas we are, or are regressing (ie: prop224 onioncat / onionvpn).

> But it needs to be easy, not clunky.

Then it seems Tor / overlays will have to build in support for easy.

And app makers will have to give up their centralized services
$IPO dreams for the greater good and new dreams of true p2p.
Not as if they could not have a donate button or other model therein.

And lots more leaders will need to dive into the onion (and *overlay)
space to promote the meatspace and develop the underlying tools as
a whole. Beyond just setting up and announcing another Elgg.onion,
or another new redundant *coin.

Governments will have to relax and let progress beyond the
old legacies.

And let us not forget that the "Internet" was an uneasy
mystery for most users in the 1990's, but by a decade later
they largely taught themselves the necessary details.

If you build it they will come.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

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

[Sebastian Hahn]

Hi Alec,

> On 04 Jan 2017, at 12:24, Alec Muffett  wrote:
> 
> Actually, I don't believe that you do disagree with the problem statement
> :-)
> 
> I believe that you may concerns with one of my proposed solutions to the
> problem, and that's okay because I do too.  :-)
> 
> Let me see if I can reframe the problem statement, and maybe pose another
> alternative?
> 
> 
> == Problem Statement, Reframed ==
> 
> I believe that, at the moment, the Debian "installiverse" assumes that
> people who want to use Tor -- on a server -- are skilled and knowledgeable.
> 
> Case in point:
> 
> * For setting up relays you want to stand on a solid foundation, so Debian
> "stable" works really well.
> 
> * But I will bet that you are not running the relays by using the 0.2.5
> codebase which it offers. :-)

I currently maintain 15 debian systems privately (mostly VMs). All but one
of them have tor installed. Only four of them use the tpo repository (those
provide either public or private network relays or dirauths). The others
use regular debian-provided packages.

> ** (Not least, I believe that the crypto in anything older than 0.2.7.*
> will be a lot slower?)

This doesn't matter unless you run a high-performance relay. Also, I think
going from 0.2.7.x to 0.2.8.x increased my cpu usage on my busy relay.

> * So I believe that you are probably not running 0.2.5 because you are
> skilled enough to use backports or roll your own.

I consider myself skilled enough, but I'd rather keep the amount of custom
repositories to the bare minimum. Especially my more trusted computers
don't get additional repos if I can help it at all.

> Now, for contrast, consider Tor Browser Bundle:
> 
> * TBB is designed for use by "normal people".
> 
> * It is not running 0.2.5.* either, because it would be foolish to push out
> such "old code" to the clients.
> 
> * TBB runs code which we might call "Tor Stable", being probably a similar
> version to the code which you yourself would deploy for a relay.
> 
> * Therefore: "Debian Stable" is not offering "Tor Stable", instead it is
> offering "Tor Stale", or "Tor Stagnant".
> 
> 
> == Summary ==
> 
> Debian Stable, by default, offers code that we would deprecate on the
> servers, and would never ship on the clients.

Well, we're not currently deprecating it. It's still recommended by the
dirauths to run one of those versions.

I am not sure, but I think the main reason to ship recent Tors in TB is
because we have to ship new Firefox releases anyway, so the pain of adding in
some more software is minimal. That and the increased benefit of new
security features, better blocking resistance, etc.

> How is this to anyone's benefit?
> 
> It's like the old chef's rule about "never cook with wine that you would
> not drink by yourself"
> 
> 
> == Challenge ==
> 
> Consider schools. Consider journalists, hobbyists, non-CS university
> students. Consider "IoT tinkerers".

I'm a sysadmin at my school for a student computer pool, we have around 13k
users and around 250 physical machines for students to use. The biggest
thing I'd wish for were a system-wide installable Tor Browser that we can
keep updated for our users. And we would do it, just like we keep everything
else updated (for that job, while we do run debian stable, we're constantly
chasing down last versions for a variety of software where the latest version
is necessary for teaching or because it was requested by some students).

> Consider people who don't know what "vim" does. :-)
> 
> These are people who can use Tor for good purposes, and I believe that Tor
> should seek to "enable" them, and make Tor easier to use for them.
> 
> But the Tor code which comes with Debian, and thus with Raspbian, and
> kinda-with-Ubuntu, is (by the metaphor) bad wine which you would never
> offer to these people to actually drink nor cook with.

In my world, these people don't really use apt-get, they will look to
install something they can download from a website while following some
instructions. TB seems to fit for that mental model. I just see a kind of
disconnect between the hapless user and the advanced usecases where TB is
not enough.

If the user does know apt-get, they could install the torbrowser-launcher
package on debian stable, which helps get them a shiny new TB. Admittedly,
I have no idea about availability on Ubuntu.

> In my previous e-mail I suggested removing Tor from Debian precisely
> because of this future-staleness problem.

I find this to be totally the wrong thing. We all want all our users to
run our latest code, nownownow. It's a completely understandable line of
thought, after all we're developers and passionately implemented features,
created better architecture, debugged and fixed bugs for days. I think it's
still kind of arrogant/presumptuous. As long as there are no reasons to
kill an older version (like security issues, incompatability with a newer
protocol where the cost of keeping to support the older 

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

[Alec Muffett]

Hi Sebastian!

On 4 January 2017 at 06:24, Sebastian Hahn  wrote:

> Hi Alec,
>
> thanks for your thoughts. I have just one very quick comment, but
> it seems you haven't addressed it yet:
>

Okay, I'll give it a go :-)


I install Debian stable on my servers precisely because they don't
> necessarily track the latest packages for everything.


Yes, I totally understand that.  Especially for a long-lived platform I can
totally see the utility, sanity and wisdom of doing that, especially where
the person administering the system is skilled and knowledgeable.


When I have
> installed them and they work, I don't need to do super frequent
> maintenance - I get security updates, but not much more.


Yes totally.



> Tor updates for
> relays frequently require you to read the changelog carefully to have a
> sane upgrade path, other software does that too - having to do that
> constantly when you're not actually need any of the new features is
> super annoying imo.
>

Yes.



> There are some select pieces of software where this isn't the case -
> the kernel on my gaming system, the tor package on my relays, some
> others - where I selectively use backports or custom repositories. I
> would imagine if the main purpose of my machines wasn't providing tor
> relays, I'd prefer to just run whatever debian stable provides.
>

Yes.



> > So this is kinda the problem statement:
> > - old versions of Tor are out there in the wild
> > - they pollute the software environment, representing "cognitive load" /
> > barriers to easy adoption and learning
> > - adoption and learning are critical to the growth in use of Tor
>
> I guess I just disagree with this problem statement.
>


Actually, I don't believe that you do disagree with the problem statement
:-)

I believe that you may concerns with one of my proposed solutions to the
problem, and that's okay because I do too.  :-)

Let me see if I can reframe the problem statement, and maybe pose another
alternative?


== Problem Statement, Reframed ==

I believe that, at the moment, the Debian "installiverse" assumes that
people who want to use Tor -- on a server -- are skilled and knowledgeable.

Case in point:

* For setting up relays you want to stand on a solid foundation, so Debian
"stable" works really well.

* But I will bet that you are not running the relays by using the 0.2.5
codebase which it offers. :-)

** (Not least, I believe that the crypto in anything older than 0.2.7.*
will be a lot slower?)

* So I believe that you are probably not running 0.2.5 because you are
skilled enough to use backports or roll your own.

Now, for contrast, consider Tor Browser Bundle:

* TBB is designed for use by "normal people".

* It is not running 0.2.5.* either, because it would be foolish to push out
such "old code" to the clients.

* TBB runs code which we might call "Tor Stable", being probably a similar
version to the code which you yourself would deploy for a relay.

* Therefore: "Debian Stable" is not offering "Tor Stable", instead it is
offering "Tor Stale", or "Tor Stagnant".


== Summary ==

Debian Stable, by default, offers code that we would deprecate on the
servers, and would never ship on the clients.

How is this to anyone's benefit?

It's like the old chef's rule about "never cook with wine that you would
not drink by yourself"


== Challenge ==

Consider schools. Consider journalists, hobbyists, non-CS university
students. Consider "IoT tinkerers".

Consider people who don't know what "vim" does. :-)

These are people who can use Tor for good purposes, and I believe that Tor
should seek to "enable" them, and make Tor easier to use for them.

But the Tor code which comes with Debian, and thus with Raspbian, and
kinda-with-Ubuntu, is (by the metaphor) bad wine which you would never
offer to these people to actually drink nor cook with.

In my previous e-mail I suggested removing Tor from Debian precisely
because of this future-staleness problem.

I still believe that this is a decent idea, because stale code sucks.

Another possible solution would be creation of a "Tor Server Bundle" -
designed and maintained to run successfully on most major platforms, it
would be a bunch of scripts that find existing, stale versions of Tor, kill
and remove them, and migrate the platform to a more recent version, with
*optional* enabling of auto-updating because you will want to have a stable
environment. :-P

And it would (ideally) also ship with some portable, stupid but bombproof,
interactive and scriptable CLI wizards for setting up Onion services.


== Why? ==

Large chunks of the Tor community are focused on Tor's primary purpose as
an anonymising proxy, and that's very, very important.

It is Tor's primary and best-understood, to provide people with a secure
and generally anonymized means to connect to cleartext websites.

But (subjective opinion) I think the future of Tor is in disintermediated
networking.  I think the future is in onions.

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

[Sebastian Hahn]

Hi Alec,

thanks for your thoughts. I have just one very quick comment, but
it seems you haven't addressed it yet:

> On 03 Jan 2017, at 03:04, Alec Muffett  wrote:
> 
> Where I feel that issues arise are in the older Ubuntus and Debians.
> 
> Again, I understand that there are "backports" repos, but my experience of
> encouraging new people to adopt Tor is one of trying to help them to jump
> over the hurdles which we immediately place in their way.

I install Debian stable on my servers precisely because they don't
necessarily track the latest packages for everything. When I have
installed them and they work, I don't need to do super frequent
maintenance - I get security updates, but not much more. Tor updates for
relays frequently require you to read the changelog carefully to have a
sane upgrade path, other software does that too - having to do that
constantly when you're not actually need any of the new features is
super annoying imo.

There are some select pieces of software where this isn't the case -
the kernel on my gaming system, the tor package on my relays, some
others - where I selectively use backports or custom repositories. I
would imagine if the main purpose of my machines wasn't providing tor
relays, I'd prefer to just run whatever debian stable provides.

> So this is kinda the problem statement:
> 
> - old versions of Tor are out there in the wild
> 
> - they pollute the software environment, representing "cognitive load" /
> barriers to easy adoption and learning
> 
> - adoption and learning are critical to the growth in use of Tor

I guess I just disagree with this problem statement.

Cheers
Sebastian
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

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

[grarpamp]

On Tue, Jan 3, 2017 at 5:04 AM, Alec Muffett  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.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

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

[Alec Muffett]

Hello Grarpamp!

On 3 January 2017 at 07:32, grarpamp  wrote:

> On Mon, Jan 2, 2017 at 9:04 PM, Alec Muffett 
> 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@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

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

[grarpamp]

On Mon, Jan 2, 2017 at 9:04 PM, Alec Muffett  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.

> 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.
And it has substantial monetary and other strategic resources that would
make other projects in the space cry. (Or as the case may be, reject various
elements of the Tor Project Inc as a model they would care to follow after).

> 1) change always needs to be paid for; if we glibly say "someone at Tor
> 2) the repos won't always appreciate people throwing new code at them, and

Depends on their priorities and policies. Given tor has few dependencies
above and below it, I'd think most would accept a bump to the latest version..
Now who generates the bump as in (1) above is different story.

> 3) There is a very big event impending, the freeze for "Debian
> I am told that Debian prioritises code stability

Yes those having other priorities tend to have beefs with Debian.
Just because freezer can doesn't mean should freeze beef forever.

> Tor is
> security-sensitive software with a bullseye target painted on its forehead,

"OpenSSL" is security-sensitive software with ...
"kernel" is ...
"*" is ...

> Observing the "installiverse" list, we can see
> quite a nice thumbnail sketch of the "if-and-or-but" decisions which new
>  begin 
> If you're using [...] just run [...] ...

Linux distro model has imparted a brokenverse upon itself and its users.
Do not feel bad or that you have to solve it for them, unless that
should be your life's next happy project.

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

OnionCat is an example of a tool that is very useful and
is absolutely going prop224 critical real soon now.

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.

A corporate manager might put some of the team from the
now mostly finished torsocks refresh, as part onto a new onioncat
team. Some of them having recently thought about Socks5,
OS interfaces, and network bits other than TCP. Granted problem
requires mostly thinkers around onions, or big protocol update.

> Comments?

As always, faced with problem of raising and allocation of volunteer
resources across shared responsibility space. No answer there
other than bring them all together for a powwow [1] on the subject.

> But what I would like to do is see the above complexity ("ask Wikipedia?")
> be simplified into coherent nonexistence, for all major platforms.

[1] But if there's big interim demand to have something to
point your users to as supported all else be damned...
compile statically for in /.../ for your platforms and
distribute and document that. That's what corporate $payware
software houses / sellers often do. Some even ship their own OS
environment if the user's is too much to deal with.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

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

[Alec Muffett]

I will admit that I have not fully thought this through yet, so I am
writing this in the hope that other folk will follow up, share their
experiences and thoughts.

So: I have installed a bunch of Tor systems in the past few months -
CentOS, Ubuntu, Raspbian, Debian, OSX-via-Homebrew - and my abiding
impression of the process is one of "friction".

Before getting down to details, I hate to have to cite this but I have been
a coder and paid Unix sysadmin on/off since 1988, and I have worked on
machines with "five nines" SLAs, and occasionally on boxes with uptimes of
more than three years; have also built datacentres for Telcos, ISPs and
built/setup dynamic provisioning solutions for huge cluster computing. The
reason I mention this is not to brag, but to forestall

* "There is nothing hard about tar-xvf/configure/make/make-install", or...

* "All you need is {yum,apt-get} and to add $MAGIC_REPOSITORY (eg:
backports) to $WEIRD_FILE", or...

* "All you need is launch $NICHE_DISTRO_GUI_TOOL and tick $SOMEBOX under
$FOLDED_MENU_ITEM"

* "Read the manual for 'dpkg'" / "what about reproducible builds?" /
"Install OpenBSD"

...responses.  I know that such tools exist, I know how to drive them;
however I am not "normal", and I suspect the same can be said of anyone who
would offer such advice to a new person who wants to use Tor.

If I have not messed this up, the current state of the Tor
"defaultinstalliverse" includes:

Debian Jessie: 0.2.5.12-4
Raspbian Jessie - tracks Debian (this is the Raspberry Pi platform)
Ubuntu Xenial LTS 0.2.7.6-1ubuntu1
Ubuntu Yakkety 0.2.8.8-1ubuntu1
Centos7(1611) - n/a, use Fedora
Fedora 0.2.8.12-1.fc26
OSX Homebrew 0.2.9.8
OSX Macports 0.2.9.8

There's quite a spread here; amazingly the OSX repos are on the cutting
edge, with Fedora and the latest Ubuntu is close behind.

Where I feel that issues arise are in the older Ubuntus and Debians.

Again, I understand that there are "backports" repos, but my experience of
encouraging new people to adopt Tor is one of trying to help them to jump
over the hurdles which we immediately place in their way.

The conversation usually goes a bit like this:

"Okay, you want to install Tor. First thing: you must ignore the version of
Tor that your operating system supplies. Oh, wait, you already installed
it? Did you use backports? You don't know what that is? Okay, if you type
'tor' what numbers does it give you? Type "which tor". Yes, that one. Okay,
that's an old version, we need to remove that and give you something
better. You don't know how to remove it because you were using the GUI?"

...which does not constitute a "positive user experience", nor "simple
advice", nor is it "fun".

It's gotten to the point where sometimes, if I want to ensure that the user
has a current Tor daemon on their machine to play with, I tell them to
install Tor Browser Bundle and use the SOCKS port to connect to Tor, a
solution which will go away once UNIX socketing is adopted for TBB
communications.

So this is kinda the problem statement:

- old versions of Tor are out there in the wild

- they pollute the software environment, representing "cognitive load" /
barriers to easy adoption and learning

- adoption and learning are critical to the growth in use of Tor

Further, as additional context, I am told that Tor "support" models will be
changing soon, and that only $SOME_NUMBER of recent releases will retain
support/bugfixes; presumably if one does not get on the train and track the
supported releases, one will be on one's own.  Given the (less than
corporate-sized) resources at Tor's disposal, I think this is fair and
agree with the decision.

I do not have a magic fix to address the problem statement, but I do have
some observations:

1) change always needs to be paid for; if we glibly say "someone at Tor
should build releases and push them to the repos!" then that person will
have to be paid for, and from where does the money come? This challenge
straddles growth, usability and outreach.

2) the repos won't always appreciate people throwing new code at them, and
even if that happens they may relegate it to a $MAGIC_REPOSITORY to a net
loss in usability as mentioned above.

3) There is a very big event impending, the freeze for "Debian Stretch";
from the above you can see that Debian is possibly the most significant
source of "install pollution" of Tor; it impacts all debian-derived
distros, and even Ubuntu "LTS" (the current Long Term Support release)
seems to treat Tor with some drag even though Ubuntu has "rolled its own".

I am told that Debian prioritises code stability - and as a former Solaris
engineer I wholeheartedly agree with that goal - but where Tor is
security-sensitive software with a bullseye target painted on its forehead,
perhaps it'd be wiser for the per-platform communities to plan to move
faster.

Observing the "installiverse" list, we can see that it is not considered a
fatal flaw that (say) Centos does not distribute Tor; documentation on