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
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays