[tor-relays] FreeBSD 11.1 ZFS Tor Image

[Conrad Rockenhaus]

George,

I'm sorry, I didn't take your points as accusatory at all. I apologize if I 
came across that way. You had valid points, and after everyone on the mailing 
list pouncing me about these points, I can completely understand now that 
providing an image for production use is a bad idea. I know I've just started 
with the project, and I still have quite a bit to learn, so I apologize for 
offending anyone and stepping on any toes. 

Anyway, I know the BSD/Linux relay counts are totally skewed to Linux, which 
is why I converted all five of my exits to FreeBSD. Hopefully that helps a 
little.

Thanks,

Conrad

On Sunday, February 25, 2018 4:03:00 PM CST George wrote:
> Conrad Rockenhaus:
> > On Sunday, February 25, 2018 3:05:00 PM CST George wrote:
> >> Conrad Rockenhaus:
> >>> Hello All,
> >>> 
> >>> If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS image
> >>> that is fully configured and ready to run Tor. Right now it's an eight
> >>> GB
> >>> image, but I'm reducing the size by removing all of the extra stuff on
> >>> it
> >>> from the upgrade from FreeBSD 11 to 11.1.
> >> 
> >> I think it's great to ease the implementation of Tor relays,
> >> particularly on BSDs.
> > 
> > My main thought process behind trying to ease the implementation of BSD
> > relays is the fact that we should diversify what we have online within
> > the network. Most of our nodes are Linux. What if we have another
> > vulnerability that comes out that hits Linux specifically again?
> 
> Oh, absolutely. Completely valid and the reason for The Tor BSD
> Diversity Project's existence.
> 
> It's even uglier with bridges than with public relays.  Our stats give
> daily snapshots to back your point:
> 
> https://torbsd.org/oostats.html
> 
> >> However, I'd be wary of an image that I didn't build myself, personally.
> > 
> > That's your opinion. The AWS relay project was very successful. Numerous
> > people ran an image that they didn't build. Numerous people also run
> > Docker
> > containers that they didn't build. Numerous people run Vagrant boxes they
> > didn't build. You have the right to be weary, but there's numerous people
> > out there who run other people's images everyday.
> 
> Yes, being wary should be a guiding principle IMHO.
> 
> I'm aware of the other image-based roll-outs, but I just wanted to add a
> disclaiming comment.
> 
> Personally, I'm purely for bare-metal server solutions to minimize
> (although it doesn't eliminate) external trust. I understand that images
> from whatever method are a gateway, but caution is compulsory.
> 
> >>> If you're interested in the image let me know. This image has been fully
> >>> tested on OVH's Openstack infrastructure, so if you're interested in
> >>> running it on their infrastructure, let me know and I can walk you
> >>> through it, or you're more than welcome to host is within my cloud at
> >>> cost (it's a low monthly rate and unlimited bandwidth).
> >> 
> >> Another issue is that OVH is over relied upon for public nodes. It's the
> >> leading ASN with almost 15%.
> > 
> > They're one of the few providers out there that allow exits. That's why
> > 15% of our exits are on OVH.
> 
> Yes, of course. However, you refer to the lack of diversity in operating
> systems, but monocultures in providers/ASNs is another danger we should
> be conscious of.
> 
> >> https://torbsd.org/oostats/relays-bw-by-asn.txt
> >> 
> >> OTOH, I do think we (in particular BSD people) need to facilitate the
> >> implementation of BSD relays, including for VPS services for those
> >> looking to test the waters.
> > 
> > I completely agree.
> > 
> >> The TDP wiki has a list of other BSD-offering VPSs, plus a script for
> >> Vultur to build on OpenBSD. I tend to think using other people's scripts
> >> that can be reviewed and hacked is a better gateway for new relay
> >> operators than images.
> > 
> > It would actually be very easy to find tampering within a BSD operating
> > system. Again, you're welcome to your opinion, but this is no the first
> > time an image has been offered to assist people within in the network,
> > and again, with your view, let's get rid of the tor docker containers,
> > the AWS AMIs, etc.
> All hardware, all operating systems can be tampered with.  From network
> cards to your shell.  That is an accepted reality.
> 
> IMHO think virtualization in the current trend is dangerous and should
> be avoided, from clouds to docker. It's more code to have bugs, more
> systems to patch and more trust to grant.
> 
> But I'm not looking to debate those larger (and very real) issues.
> 
> Quite bluntly, it's easier for an adversary to just provide compromised,
> back-doored images than to crack AES, compromise hardware, etc. By no
> means am I being accusatory towards you, and as I started my replies
> with, I think you're raising a wildly valid issue, but full systems
> provided by someone on a mailing list don't pass a reasonable sniff test.
> 
> g

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20180225/fb581e06/attachment-0001.sig>