The Tor BSD Diversity Project

aboutcontactlicensingoostatswikisupportfaqarchives

Replying to Tor Blog Comments

1505 words by gman999 written on 2016–08–05, last edit: 2016–08–05, tags: opinions, torPrevious post: So Much Quiet ProgressNext post: The Buildbot Needs BSD Relays


The last Tor blog post on Tor 0.2.8.8 is released, with important fixes prompted a flurry of comments regarding the BSDs and the Tor Project.

An important part of the Tor 0.2.8.8 release was a fix for bug #20103 discovered by TDP. Tor on OpenBSD was crashing with OpenBSD relays running 0.2.8.7 as the first hop. Gman999 first encountered the crashes while testing new TBB packages. Attila did the heavy lifting and reported it to the TP’s Trac.

OpenBSD is an ideal bug-finding platform as it follows the classic Unix approach in which a daemon dies loudly rather than quietly hiding its behavior. The bug likely affects other operating systems, so another +1 for operating system diversity.

The comments section opened a noisy series of posts about Tor and the BSDs, some of which we believe are inaccurate and demand responses. Snips from the posted comments are below, with our replies:

Since nickm mentioned OpenBSD users have been more seriously affected, we’d like to take this opportunity to ask why The Tor Project has no plans at all to release Tor Browser Bundle for *BSD operating systems, OpenBSD in particular.

There are lots of things the TP should be planning, and as non-Tor Project developers, we jumped on the opportunity to port Tor Browser to OpenBSD back in March 2015. We are in regular contact with the TP, and have been encouraged and assisted by a number of TP core people, including Moritz and Roger. Gman999’s recent attendance at the Seattle Tor Summit illustrated the great attention TDP is getting; he was personally flattered by the recognition.

The question for the anonymous poster is “what are you doing?” TP is an open source project. In BSD Land no one listens to gripes about software if the complainer doesn’t at least begin resolving the issue, like submitting debugging information, providing a patch, etc. It’s a principle that all open source projects should adopt. The poster in question should at least be testing our TB releases on OpenBSD. Fork the code, submit a useful issue, and so on, but complaining anonymously on a blog about what others should do is pointless at best.

It appears then that The Tor Project is not keen at all to support users of *BSD operating systems. Therein lies the danger. Again the following is a quote from The Tor BSD Diversity Project…

This comment follows up from noting the lack of source tarballs from the TP, which is the preference for porting Tor Browser and other software. Oddly, the poster quotes the TDP www site, yet in the previous comments says the TP “has no plans at all to release Tor Browser Bundle for *BSD operating systems.”

Nick M, Roger D, and others actively use the BSD Buildbot initiated by Christian S., and we have corresponded about it. Roger made multiple references to TDP in his postings on various Tor mailing lists. We hardly feel there is some conspiracy against the BSDs from Tor core developers. Rather, there is a genuine recognition of the TDP endeavor.

More generally: yes, the recent vulnerability from RFC5961 TCP implementations on Linux makes yet another strong case for operating system diversity, and it is neither the beginning nor the end of screams for diversity.

And it’s not just operating system diversity. More relays need to be running on architectures other than x86. PPC and ARMv7 are certainly worthwhile platforms, and the near-future should see production-quality support of 64-bit ARM hardware (aarch64) on FreeBSD.

Moroever OpenBSD users prefer to download Tor Browser Bundle directly from The Tor Project as the latter is the official software publisher of Tor.

We doubt too many open source operating system users would prefer to directly download from any third party for their packages as opposed to using software packaged specifically built for their operating system in their respective ports or package system.

In the case of OpenBSD, this is doubly true. If software gets into OpenBSD’s ports tree, a small but real amount of review is conducted at minimum. Third-party ports in the tree aren’t fully audited, but as one can see from the ports@ mailing list, ugly unreviewed ports don’t easily enter. We have been developing and tweaking TB on OpenBSD for a long time. Maybe if we could attend to the porting effort with more time and resources, TB would already be in the OpenBSD ports tree, but regardless, look through the comprehensive attention TB has received. Moreover, development on OpenBSD only happens on the -current branch, which changes rapidly and frequently.

There is another issue that gets glossed over when people propose that the Tor Project should distribute OpenBSD TBB packages: who signs them? It is not that common in the OpenBSD community for users to have umpteen keys from umpteen software repositories installed in /etc/signify and to mix packages installed from various sources. Users generally install packages built from ports by the OpenBSD team, signed with the keys distributed with the operating system (one notable exception: M:Tier, which is run by OpenBSD developers). We are therefore hesitant to suggest that the Tor Project start distributing packages, since they would then have to sign them and instruct their users to add the appropriate keys to their system. The better way, in our opinion, is for the port to be accepted into the official ports tree and for binary packages to be made available in the usual way.

If I had seen all this sooner, I wonder if it would have been worthwhile to have suggested tackling *BSD Tor packages be a hack topic at the recent Tor Project Hack Day in Seattle this weekend? Perhaps there’ll be a future chance?

It wasn’t an explcit topic in Seattle, but there was a fruitful discussion about diversity, and not just operating system diversity. There were also a number of informal discussions on the topic, but the ball is really in TDP’s court right now. TDP will need more TP involvement in the near future.

Regarding a version of TAILS on a BSD: It will never happen as *BSD kernels are notorious for being behind in their support for the latest Intel CPUs.

This is really just FUD: the vast majority of hardware is well-supported by the BSDs. OpenBSD is refreshingly intransigent about signing non-disclosure agreements, which can mean lack of support for some hardware, but they do distribute firmware for some wireless cards and other devices. Without that stance, a lot of open source development would never occur. “Open source operating system” would like mean a collection of mysterious bloated binaries with a “Certified Open Source” sticker slapped on the product.

Producing a TAILS-like alternative based on OpenBSD has been a goal of TDP since its inception. We’re still on the first step: porting TBB to OpenBSD.

And again regarding the RFC5961 issue in Linux: the argument should just be about having diverse kernels, because saying a known bug “proves” one of them to be inherently inferior is actually a temporary fact. In using a diversity argument and avoiding a comparative argument, I’d expect more support for *BSDs will be attracted from thinking people.

We aren’t focused on ‘superiority’ although most people who choose an operating system logically consider it superior on some level or another.

It is generally true that each of the BSDs have different roadmaps for implementing standards than Linux. In many cases, the BSDs differ among themselves, despite a shared origin and lots of overlap since.

I don’t understand why you brought Apple into the discussion.

and,

I think the OP refers to the public secret that Apple pilfered one of the *BSDs and adapted it into iOS, because the generous nature of the BSD licence allows it, hence why “BSD things are more better for closed source” as the OP puts it. It’s well known that iOS is a Unix clone, at least.

In a sense the BSD license throws up a white flag in the face of corporate usage of code. It’s a pointless battle, and their side always has more resources and lawyers. The point of the BSD license is to protect the developer, and to let code flow around like it should without restrictions; the simplicity of BSD-derived licenses is impossible to deny. We view licenses like the GPL (esp. post-v2) as generators of billable hours for corporate lawyers, something we’d care to avoid.

Apple does use BSD code, as do many other firms. “Pilfered” hardly describes the relationship. And yes, that lack of restrictiveness does mean BSD code is used but not loudly. Having a license that developers don’t need a lawyer to read offsets the loss, and BSD-licensed code’s influence is deep.

That’s it for now.


Copyright © 2015–2017 by The Tor BSD Diversity Project (TDP). All Rights Reserved.