The Tor BSD Diversity Project

aboutcontactlicensingoostatswikisupportfaqarchives

TB 5.5 on the Current Snapshots

408 words by gman999 written on 2016–03–31, last edit: 2017–09–03, tags: openbsd, tor-browserPrevious post: Porting PETs UpdatesNext post: So Much Quiet Progress


As of last week’s OpenBSD’s i386 and amd64 snapshots, TB 5.5 is no longer working.

We are looking to start building the Tor Project’s most recent TB soon. Spending time on TB 5.5 is fruitless when 5.5.4 is the current TP release.

The OpenBSD project just announced the release 5.9 a month early, which I personally don’t remember ever happening. The project usually follows a strict six-month release cycle. We are going to focus on getting TB into the next stable release of OpenBSD, which would be 6.0, planned for November 1. Of course we hope to have TB in the snapshots ports way before that date.

Meanwhile, the Quick-and-Dirty Static Reports are still updated regularly, albeit manually still.

Additionally, a lot of time has been recently committed to Porting Targets for PETs. It’s a tough battle. You spend time getting the basic aspects of the Makefile operational, you figure the peculiarities of how a port is compiled, the array of licenses, and so on, but then you realized a host of unported Python libraries build or run dependencies. Jump out of vi(1) and into the rabbit hole.

A final note on porting PETs-related software, mostly directed at developers. Write your software to be portable, please. Creating a Python module port or package may be a simplistic example of portability, but a negative example is doing builds specific by each OS and Linux distribution. Don’t give me setup_debian.py, or a setup file that relies on a handful of operating system choices. Give me an install script that can recognize the global variables and avoid hard-coded paths, that doesn’t need one shell or another. What does bash provide that the install script requires? I mean, really? For the vast majority, a 1995 Bourne shell would be more than sufficient.

If you only want, say, Debian users, for your PETs application, you are definitely not looking at the basic diversity arguments so apparent to most people. You are also cutting off more potential downstream developers that could be making your life easier. Treated nicely, downstream developers can make you look significantly smarter than you might be. There are arguments whether the “many eyeballs” make open source software more secure when most people don’t read code, but there’s no question that more downstream developers hacking on your code really does.


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