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

[grarpamp <grarpamp@xxxxxxxxx>]

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.

> 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 /.../<isolated> 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@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk