⋔ about ⋔ contact ⋔ donate ⋔ license ⋔ archives ⋔
988 words by attila written on 2015–04–29, last edit: 2015–04–29, tags: open-source, openbsd, pets, ports, tor, tor-browser ⋔ Previous post: Things I Wish I’d Seen When They Were Posted ⋔ Next post: OpenBSD Tor Browser Ports Status Update: June 2015, v4.5.2
A few bits of progress to report on the Tor Browser Bundle ports.
First, my collaborator and I have set up a new GitHub account: The Tor BSD Diversity Project. We’ve moved all of our git repositories and are using GH to coordinate, for the most part. There’s even a nascent web page.
Most of the git repositories in that account are tracking mirrors of repositories at https://git.torproject.org. We do this because GH repositories are already well-supported by the OpenBSD ports system, so it is easy to point at them. We don’t modify the source e.g. to integrate our patches or do anything like that; we use the normal OpenBSD ports mechanism for managing patches and treat the GH repos like they are the upstream, because, well, they are. If this becomes too great a pain to maintain then I’ll start thinking about hacking up something different but for now it has made it easy to make more progress.
repository contains the actual OpenBSD ports. The
has been relatively stable for a while now: I’ve tracked a few version
bumps and there have been no hitches building the port.
I finally managed to get around to completing the HTTPS-Everywhere
(HTTPSE) port. It was a little painful, and required that I upgrade
textproc/py-lxml port to the most recent version: the rule
validation and “compilation” (into an
sqlite database) parts of the
build depended on a more recent version of
py-lxml than was in
ports. I’m now trying to step up and become maintainer of this port
(it had none) because I’m obviously going to care about it; HTTPSE,
unlike the other two extensions, changes frequently, if only because
it is rule-based and the rules must constantly be maintained.
The only item that’s left is Pluggable Transports (PT), which is actually many items. My attitude is that every independent piece of software in the TBB should be turned into a port in the OpenBSD realization. That means I have at least four more ports to go, maybe some version wrangling/hand-wringing with a couple of Python modules if they’re already in ports and not at the right version.
The Tor project just announced that version 4.5 has been released and will become the default version in a little under a week. This should not be that big a deal but there are still a lot of hand-operated bits involved in maintaining these ports, and that’s one more (meta)thing on my list: more automation in the way we track version changes. The process cannot be completely automated, of course, but there are certainly aspects of it that can be.
Now that TBB 4.5 is out, this is how things look version-wise for making the jump from 4.0.8:
|Name||Component||TBB 4.0.8||TBB 4.5||Notes|
|tor-browser||browser||4.0.8||4.5||Firefox ESR 36.1.0|
|https-everywhere||browser||4.0.3||5.0.3||changes all the time|
|meek-http-helper||browser/pt||1.0||1.0||“reflector” for meek TLS camo, c.f. meek project wiki|
|fte||pt||0.1.0||0.1.0||has not changed in a while|
|meek||pt||0.17||0.17||meek server written in Go, again c.f. meek project wiki|
So although getting HTTPSE working is great, I still am not quite half way
there counting by the number of ports… Also, the method by which
all of the PT stuff is hooked together (
torrc skulduggery) requires
some thinking and tinkering to get it right under OpenBSD. I thought
it was so great how quickly I was able to get the basic stuff working
but really it’s a slog to get the whole thing done.
Above and beyond all of that there are configuration hacks and tweaks
that have to be set up which cut across several of those individual
packages; this almost certainly will require a script which sits
between the user and
tor-browser and that makes sure the situation
is as the TBB expects it to be before
tor-browser starts. There is
already a script in the TBB,
start-tor-browser, which is the natural
object of my attentions in this regard. This will be the bow that
ties all of this up… I hope.
Finally: the number one question I’ve been asked about this is if I’ll
do a FreeBSD port. The answer is: if nobody else gets to it first
then I probably will end up doing that, but who knows how long it will
be (and I’ve never done it under FreeBSD so there’s that inertia to
overcome). In short: if you want this for FreeBSD you should find a
FreeBSD ports person who’s willing to look over
and at least comment on what it would take, if not pitch in (we could
easily sprout a
freebsd-ports GH repo if someone were willing to
carry the ball).
Alllright, so… back to work.
Copyright © 1999–2017 by attila <firstname.lastname@example.org>. All Rights Reserved.