-
Notifications
You must be signed in to change notification settings - Fork 8
/
blog.html.bak
1164 lines (641 loc) · 115 KB
/
blog.html.bak
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8"/>
<title>The Tor BSD Diversity Project</title>
<link type="text/css" rel="stylesheet" href="torbsd.css"/>
<meta name="author" content="gman"/>
<meta name="editors" content="attila"/>
<meta name="date" content="2015-10-29"/>
<meta name="x-note" content="These lines at the top are multimarkdown metadata; leave them."/>
<meta name="sep" content="&#8916;"/>
</head>
<body>
<h1 id="thetorbsddiversityprojecttdp"><a href="index.html">The Tor BSD Diversity Project (TDP)</a></h1>
<p>&#8916; <a href="blog.html">Blog</a> &#8916; <a href="faq.html">FAQ</a> &#8916; <a href="resources.html">Resources</a> &#8916; <a href="https://github.com/torbsd/">GitHub</a> &#8916; <a href="contact.html">Contact</a> &#8916; <a href="http://bptfp7py2wclht26.onion/">TDP Onion</a> &#8916;</p>
<p><strong><a href="projects.html">The TDP Projects</a>:</strong><br/>
&#8916; <a href="https://github.com/torbsd/openbsd-ports/">Tor Browser for OpenBSD</a> &#8916; <a href="relay-guides.html">BSD Relay Guides</a> &#8916; <a href="corp-relays.html">Corporate Relays</a> &#8916; <a href="porting-pets.html">Ports for PETs</a> &#8916; <a href="oostats.html">Statistics</a> &#8916;</p>
<h2 id="ablogoracentrallocationforannouncesandnotes">A Blog, or a Central Location for Announces and Notes</h2>
<p><strong>October 2017</strong></p>
<p><a href="#ports-matter">Ports Really Matter</a> &#8916; <a href="#obfs4-everywhere">obfs4proxy is Everywhere</a></p>
<p><strong>September 2017</strong></p>
<p><a href="#tb705-ports">Tor Browser 7.0.5 in OpenBSD -current ports</a> &#8916; <a href="#installfest">*BSD Focused Tor Bridge Installfests</a></p>
<p><strong>August 2017</strong></p>
<p><a href="#tb704-ports">Tor Browser 7.0.4 in OpenBSD -current ports</a> &#8916; <a href="#welcome-obfs4">Testing obfs4proxy on FreeBSD and OpenBSD</a> &#8916; <a href="#getting-sick">Getting Sick</a></p>
<p><strong>June 2017</strong></p>
<p><a href="#onionoo-stats-1">OnionOO/JSON-based Stats</a> &#8916; <a href="#bsd-vps">BSD VPS Providers Needed</a> &#8916; <a href="#back-to-buildbot">Back to the Buildbot</a></p>
<p><strong>April 2017</strong></p>
<p><a href="#summit-2017-amsterdam">Tor Summit 2017 in Amsterdam</a> &#8916; <a href="#android-takeover">Android Overtaking Windows and OS Diversity</a> &#8916; <a href="#tor-motives">What Motivates You to Run a Tor Relay?</a></p>
<p><strong>March 2017</strong></p>
<p><a href="#busy-bbb">BeagleBone Online and Busy</a> &#8916; <a href="#obsd-bbb">Tor Relay on a BeagleBone Black Running OpenBSD -current</a> &#8916; <a href="#calling-bsd">Calling All BSD Firms</a> &#8916; <a href="#tsummit-amsterdam">Amsterdam in March</a></p>
<p><strong>February 2017</strong></p>
<p><a href="#current-relays">Running OpenBSD -current for Tor Relays?</a></p>
<p><strong>December 2016</strong></p>
<p><a href="#vinicius">Welcome Aboard, Vinicius</a></p>
<p><strong>November 2016</strong></p>
<p><a href="#inthetree">In The Tree</a></p>
<p><strong>October 2016</strong></p>
<p><a href="#morebananas">More Bananas</a> &#8916; <a href="#signifysanity">signify(1) Sanity</a> &#8916; <a href="#test605">Test Tor Browser 6.0.5 for OpenBSD</a> &#8916; <a href="#torblog0">Replying to Tor Blog Comments</a></p>
<p><strong>September 2016</strong></p>
<p><a href="#current0">Where Things Stand</a></p>
<p><strong>August 2016</strong></p>
<p><a href="#buildbot">The Buildbot Needs BSD Relays</a></p>
<p><strong>June 2016</strong></p>
<p><a href="#quiet-progress">So Much Quiet Progress</a></p>
<p><strong>March 2016</strong></p>
<p><a href="#tb-snaps-status2">TB 5.5 on the Current Snapshots</a> &#8916; <a href="#portpets-up">Porting PETs Updates</a> &#8916; <a href="#tb-snaps-status1">March 10 OpenBSD Snapshots</a> &#8916; <a href="#bsdcan0">TDP at BSDCan 2016</a> &#8916; <a href="#tb-snaps-status0">TB 5.5 and i386/amd64 Snapshots</a></p>
<p><strong>February 2016</strong></p>
<p><a href="#tb55snaps1">TB 5.5 and More New Snapshots</a> &#8916; <a href="#tb55snaps">TB 5.5 and New Snapshots</a> &#8916; <a href="#next-phase">Onto the Next Phase</a> &#8916; <a href="#tb-releases">Tor Browser Releases</a> &#8916; <a href="#tb-55-tagged">Tor Browser 5.5 Ports Tagged</a></p>
<p><strong>January 2016</strong></p>
<p><a href="#still-here">Still Plugging Away</a> &#8916; <a href="#torbox">Tor-in-a-Box?</a></p>
<p><strong>December 2015</strong></p>
<p><a href="#notes-from-the-front">Notes From The Front</a> &#8916; <a href="#pp-announce">Announcing Porting PETs</a> &#8916; <a href="#2016-events">Thinking About 2016</a></p>
<p><strong>November 2015</strong></p>
<p><a href="#pets-ports">PETs Porting Targets</a> &#8916; <a href="#br-case">The Case of the Brazil Relays</a> &#8916; <a href="#tb-update-again">TB 5.0.3 Packages Updated, Again</a> &#8916; <a href="#dirty-reports">Coming Soon: Quick-and-Dirty Reports</a> &#8916; <a href="#repro-builds">Thoughts on Reproducible Builds</a> &#8916; <a href="#up-to-you">It’s Up to You</a></p>
<p><strong>October 2015</strong></p>
<p><a href="#tb-update">Updated Tor Browser Packages</a> &#8916; <a href="#relay-guides">The BSD Relay Guides</a> &#8916; <a href="#first-bells">Our First Bells</a> &#8916; <a href="#beyond-os">Beyond OS Diversity</a> &#8916; <a href="#tb-5.0.3">Tor Browser version 5.0.3 for OpenBSD</a></p>
<p><a href="#attic">From the Attic</a></p>
<h3 id="20171010">20171010</h3>
<p><a id="ports-matter">Ports Really Matter</a> by gman999</p>
<p>The end-user doesn’t get the attention it deserves in BSD land. The end-user refers to the non-developer who doesn’t know or care which shell they are running and whether it plays nice with POSIX. The end-user who wants things to “just work.”</p>
<p>There are obvious and justifiable reasons the BSD operating systems aren’t necessarily user friendly. The BSDs have always been focused on the backend, the layer beyond the immediate grasp of the typical end-user. BSD code and infrastructure is the great invisible giant guided by the principle of making things work correctly with stability and security front and center. So the end-user can get their Netflix video streamed without knowing or appreciating the role of FreeBSD in that infrastructure. Or beyond the more common end-user, the sysadmin (aka, “devops”) can securely access servers over SSH without knowing the difference between SSHv1 or v2, or how asymmetric cryptography works.</p>
<p>That’s fine, and the BSDs will continue their legacy without end-user recognition. But fine isn’t really good enough.</p>
<p>A central criteria that all end-users weigh is whether a particular operating system can run ${application}. More importantly, it shapes the options for their respective sysadmin or help desk to determine which operating system “their users” will use or what will serve data and services to those end-users.</p>
<p>Samba is easy. All open-source Unix-like systems support contemporary versions of Samba to do file-serving. There might be questions of NFS support or Windows Active Directory authentication, but there is really no bad choice.</p>
<p>This is the reasoning behind <strong>TDP’s</strong> <a href="porting-pets.html">Porting PETs</a>. The large and growing community of users looking for privacy-enhancing applications jumps with each new wave of identity theft disclosures, unauthorized leaks of one sort or another or the revelation of censorship or surveillance amid political crisis.</p>
<p>Not providing the applications those particular end-users seek means your operating system is out of the running as an option.</p>
<p>This is why <strong>TDP</strong> focused on porting Tor Browser. The BSDs are renowned for their security approaches, and choosing OpenBSD as the first platform means porting TB would be easier for other POSIX-respecting Unix-like OSs.</p>
<p>Since TB, attention has been directed to ports that assist relay operators, like obfs4proxy. Or the upcoming how-to for chroot’g Tor on OpenBSD.</p>
<p>Those ports put the BSDs in more serious contention as options for relay or bridge operators. Without ports like obfs4proxy, the BSDs are a non-starter for some end-users.</p>
<p>For the less-technical end-user, it’s TB, and now onionshare is ready for testing. <a href="porting-pets.html">Porting PETs</a> is kept relatively fresh, and will expand as resources allow. <strong>TDP</strong> wants to see more popular PETs ports running on all the BSDs so they can be a more plausible option for the BSD-inclined sysadmin, or the more common “end-user.”</p>
<h3 id="20171003">20171003</h3>
<p><a id="obfs4-everywhere">obfs4proxy is Everywhere</a> by gman999</p>
<p>obfs4proxy is the <a href="https://torbsd.github.io/oostats/bridges-trans-count.txt">most common pluggable transport</a> offered by Tor to evade censorship.</p>
<p>obfs4proxy wasn’t in any of the BSD port systems until now.</p>
<ul>
<li><p>net/obfs4proxy is now in the -current OpenBSD ports tree, and will be in the 6.2 -stable release ports for November 1</p></li>
<li><p>net/obfs4proxy is now in NetBSD’s <a href="http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/net/obfs4proxy/">pkgsrc tree</a>, which means that not only should it run on NetBSD, but on <a href="https://www.netbsd.org/docs/software/packages.html#platforms">15 other hardware platforms</a> thanks to <a href="http://pkgsrc.se/bbmaint.php?maint=alnsn|a|NetBSD.org">alnsn</a></p></li>
<li><p>and security/obfs4proxy entered FreeBSD’s <a href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222645">Bugzilla as a port submission</a></p></li>
</ul>
<p>This enables *BSD Tor bridge operators to assist censored Tor users accessing the Tor network, in an effort to begin shifting the overwhelming <a href="https://torbsd.github.io/oostats/bridges-trans-os.txt">Linux monoculture in bridges and pluggable transports</a>.</p>
<p>The same port that listens for obfs4proxy connections can be employed as a client with some simple torrc changes. The OpenBSD port means <strong>TDP</strong> can soon enable obfs4proxy as a client pluggable transport, an important milestone.</p>
<p>Any DragonFly BSD porters listening?</p>
<h3 id="20170927">20170927</h3>
<p><a id="tb705-ports">Tor Browser 7.0.5 in OpenBSD -current ports</a> by gman999</p>
<p>Tor Browser 7.0.5 was <a href="https://marc.info/?l=openbsd-ports-cvs&m=150645572611625&w=2">committed yesterday into OpenBSD’s -current ports</a>. It hasn’t show up as a package yet, but should soon.</p>
<p>At the moment, the i386 port is building from an updated ports tree. Usually if a port compiles correctly on amd64, it compiles fine on i386, but there are enough differences in the architectures that it’s worth a full build. On an old i386 Thinkpad with the -j 4 flag for <a href="http://man.openbsd.org/make">make(1)</a>, recent build times by versions are:</p>
<ul>
<li><p>7.0.2p0: 211 minutes, 57.80 seconds</p></li>
<li><p>7.0.4: 252 minutes, 38.865 seconds</p></li>
</ul>
<p>We are going to submit a patch to backport TB to OpenBSD -stable again. TB needs to be up-to-date. Anonymity is a bitter, constant war of measures and counter-measures.</p>
<p>A step behind means you lose before you step onto the battlefield.</p>
<p>On another note, obfs4proxy was submitted to <a href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222645">FreeBSD’s Bugzilla</a>. Getting obfs4proxy into FreeBSD’s ports is a prerequisite for rectifying the usage of <a href="http://torbsd.github.io/oostats/bridges-trans-os.txt">pluggable transports for bridges</a>.</p>
<h3 id="20170906">20170906</h3>
<p><a id="installfest">A BSD-focused Tor Bridge Installfest</a> by gman999</p>
<p>The disturbing picture of the <a href="https://torbsd.github.io/oostats/bridges-os-count.txt">Tor bridge operating system monoculture</a> should frighten everyone.</p>
<p>No exaggeration intended, but when only one operating system kernel is responsible for the vast majority of censored traffic entering the Tor network, alarm bells should sound.</p>
<p><strong>TDP</strong> is looking to attack this problem on the local level with hands-on Tor installfests on the BSDs.</p>
<p>One could get online commitments from all over to wear a blue shirt on the first Tuesday of the month, to stop using salt on kale or to run a Tor bridge on a BSD variant, but those calls generally evaporate on the internet. It’s time to start doing physical sessions to gather the hardware, do the Tor configuration and ultimately start changing the bridge operating system count.</p>
<p><strong>TDP</strong> is organizing a *BSD Tor bridge installfest in New York City for <a href="http://www.nycbug.org/index.cgi?action=view&id=10654">October 4th</a>, as a <a href="http://www.nycbug.org/">New York City *BSD User Group</a> meeting.</p>
<p>The meeting will be introduced with a quick overview of Tor and the role of bridges, with a glance at the current <a href="https://torbsd.github.io/oostats.html">statistics</a>.</p>
<p>To make the event fruitful, users should do some prepatory work coming into the installfest.</p>
<ul>
<li><p>Get your small and quiet thin client, an <a href="http://pcengines.ch/apu2.htm">APU2 from PCengines.ch</a> or maybe a <a href="https://beagleboard.org/black/">BeagleBone Black</a> to move beyond the x86/Intel monoculture. This is a great opportunity to hack on some of the newer (and inexpensive) ARM-based hardware supported by the BSDs.</p></li>
<li><p>Install your preferred BSD on the hardware, but keep it lean and small. For FreeBSD users <a href="https://man.freebsd.org/src.conf/">/etc/src.conf</a> can be your friend. Minimize startup daemons and build this as a single-purpose system.</p></li>
<li><p>a simple, well-commented <a href="torrc-bridge.txt">bridge-enabled torrc</a> helps. Pluggable transport support is also important for users censored by deep-packet inspection, so be sure to install and configure our obfs4proxy port for <a href="https://github.com/torbsd/freebsd-ports/tree/egypcio/security/obfs4proxy">FreeBSD</a> and <a href="https://github.com/torbsd/openbsd-ports/tree/master/net/obfs4proxy">OpenBSD</a>. Don’t forget the dependencies.</p></li>
<li><p>In some parts of world bandwidth is underutilized. For those with FIOS or regular cable connections in a place like New York City, it’s likely that your connection is quiet, even if the providers are <a href="https://www.dslreports.com/forum/r31182597-bandwidth-deception">deceptive about the true bandwidth of residential connections</a>. Decide how much bandwidth to dedicate to the bridge. Setting <em>RelayBandwidthRate</em> in the torrc to 5000 or 10000 KB will probably go unnoticed by you, but could be lifeline to users blocked from the Tor network.</p></li>
<li><p>If the bridge will be behind a firewall or NAT, figure out how to forward a TCP port to it. The bridge should have a static <a href="https://tools.ietf.org/html/rfc1918">RFC1918</a> IP address, like 192.168.1.20.</p></li>
</ul>
<p>The NYC event will be followed up by a planned IRC sessions for those wanting more feedback and discussion once the bridge is up and running.</p>
<p>Take this model of a *BSD Tor bridge installfest and replicate in your own locale or as a birds-of-a-feather session at an upcoming BSD conference.</p>
<p>In the coming weeks, we’ll blog a full recipe for *BSD Tor bridge installfests, with all the details covered to ensure a successful event.</p>
<p>Consider this installfest open-sourced and ready to hack and replicate.</p>
<p>Let us know how it goes.</p>
<h3 id="20170827">20170827</h3>
<p><a id="tb704-ports">Tor Browser 7.0.4 in OpenBSD -current ports</a> by gman999</p>
<p>Earlier today, Tor Browser 7.0.4 <a href="https://marc.info/?l=openbsd-ports-cvs&m=150382405504052&w=2">was committed to OpenBSD’s -current ports</a>.</p>
<p>On some levels it’s a non-spectacular event. We build the packages, test those packages, rebuild, retest and then Attila submits the diff to OpenBSD’s ports@ list. Sometimes I retest from source or packages on i386 before it gets into ports. Other times it’s tested after it gets into ports on the most recent snapshot.</p>
<p>It may be a boring routine to the outside world, occuring mostly on offline build servers and laptops. You can’t watch it on GitHub. But it’s also remarkably time-consuming. We fight with ancient hardware, the issues of multiple admins on the same server, not to mention the host of Mozilla zig-zags Attila maps and translates. The statues of Christopher Columbus and Lewis and Clark should be replaced with him. Each release can be a step into uncharted territory on many levels.</p>
<p>Some shiny donated hardware would help a lot, such as a couple of amd64 laptops from this century for testing and a contemporary 64-bit server for the builds. We are running off of our own stock of hardware and colocation <a href="http://www.nycbug.org/">donated by NYC*BUG</a> and <a href="https://nyi.net/">New York Internet</a>.</p>
<p>Regardless, it remains <strong>TDP’s</strong> most basic activity. Tor Brower on the BSDs idled as a topic of chatter for years, since matching a critical anonymity tool with arguably the most secure open-source operating system was a logical progression. TB ported to OpenBSD put <strong>TDP</strong> on the map for some and on the radar for many others.</p>
<p>Besides hardware, another contribution we request is some feedback. We get loads of <a href="https://marc.info/?l=openbsd-ports&r=1&s=tor+browser&q=b&w=4">feedback from the OpenBSD ports list</a>, but we have little idea of the usage. OpenBSD doesn’t keep statistics on package downloads or port installs. That’s where <em>you</em> come in. Let us know what you think.</p>
<p>Have you tried TB on OpenBSD -current? -stable? Would a maintained -stable release (via backporting) be of use? Have you tested the pluggable transport obfs4proxy as a client in the browser? Are there differences with the Windows or Linux TB releases that you notice?</p>
<p>We need to know. <strong>TDP’s</strong> <a href="https://en.wikipedia.org/wiki/OODA_loop">OODA Loop</a> is inadequate without that feedback. Notify us with a <a href="https://github.com/torbsd/torbsd.github.io/issues/">GitHub issue for the www site</a>.</p>
<p>In the next few days, the <strong>TDP</strong> email address with PGP fingerprint will be posted.</p>
<h3 id="20170808">20170808</h3>
<p><a id="welcome-obfs4">Testing obfs4proxy on FreeBSD and OpenBSD</a> by gman999</p>
<p><strong>UPDATE 20170810:</strong> both ports are ready for more testing, and the OpenBSD obfs4 and the two dependencies were submitted for the ports system.</p>
<p><strong>UPDATE 20170809:</strong> as per <a href="https://github.com/torbsd/openbsd-ports/issues/8">Yawning’s ticket</a> we’re in the process of updating and testing both ports.</p>
<p>The Tor Project’s <a href="https://www.torproject.org/docs/pluggable-transports.html.en">Pluggable Transports</a> are a mitigation measure against deep-packet inspection, a.k.a. DPI. Commonly deployed on Tor bridges, <a href="https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec.txt">obfs4proxy</a> is the <a href="https://torbsd.github.io/oostats/bridges-trans-count.txt">most common PT in use</a>.</p>
<p>There is currently no official FreeBSD or OpenBSD support for obfs4, which means that the operating system diversity of obfs4proxy providers is <a href="https://torbsd.github.io/oostats/bridges-trans-os.txt">dismal</a>.</p>
<p><strong>TDP</strong> is working to change that.</p>
<p>While our Tor Browser for OpenBSD doesn’t yet support PTs on the client side, we’ve made some significant steps recently.</p>
<p>Vinicius built <a href="https://github.com/torbsd/freebsd-ports/tree/egypcio/security/obfs4proxy/">security/obfs4proxy</a> for FreeBSD with the two previously unported dependencies, <a href="https://github.com/torbsd/freebsd-ports/tree/egypcio/security/go-ed25519/">security/go-ed25519</a> and <a href="https://github.com/torbsd/freebsd-ports/tree/egypcio/security/go-siphash/">security/go-siphash</a>.</p>
<p>We also have <a href="https://github.com/torbsd/openbsd-ports/tree/master/net/obfs4proxy/">net/obfs4proxy</a> for OpenBSD -current, ready for testing. It seems to also build fine on -stable.</p>
<p>Within our <a href="https://github.com/torbsd/openbsd-ports/">openbsd-ports project</a> resides <a href="https://github.com/torbsd/openbsd-ports/tree/master/net/obfs4proxy/">net/obfs4proxy</a>, along with the required and unofficially ported <a href="https://github.com/torbsd/openbsd-ports/tree/master/devel/go-goptlib/">devel/go-goptlib</a>, <a href="https://github.com/torbsd/openbsd-ports/tree/master/security/go-ed25519/">security/go-ed25519</a> and <a href="https://github.com/torbsd/openbsd-ports/tree/master/security/go-siphash/">security/go-siphash</a>.</p>
<p>What can you do?</p>
<p>If you’re running a FreeBSD or OpenBSD -current Tor bridge, grab the source and build it. In the case of OpenBSD it must be either i386 or amd64 at the moment (the go compiler does not yet support non-x86 architectures).</p>
<p>Adding obfs4proxy support to a Tor bridge is easy, with the addition of a single line:</p>
<pre><code>ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy managed
</code></pre>
<p>Additional options that control logging are available; read the <a href="docs/obfs4proxy_manpage.txt">man page</a> for more details. The author’s own <a href="https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/README.md">README</a> is also recommended reading.</p>
<p>With <em>info</em> level logging enabled, the log, residing in the Tor data directory pt_state/obfs4proxy.log, should show something like this:</p>
<pre><code>2017/08/05 18:03:29 [NOTICE]: obfs4proxy-0.0.7 - launched
2017/08/05 18:03:29 [INFO]: obfs4proxy - initializing server transport listeners
2017/08/05 18:03:29 [INFO]: obfs4 - registered listener: [scrubbed]:35549
2017/08/05 18:03:29 [INFO]: obfs4proxy - accepting connections
</code></pre>
<p>Feedback, comments and patches are appreciated, preferably as a GitHub issue for <a href="https://github.com/torbsd/freebsd-ports/issues/">FreeBSD</a> or <a href="https://github.com/torbsd/openbsd-ports/issues/">OpenBSD</a>.</p>
<p>Both will be submitted to the respective ports trees.</p>
<p>A final general note on obfs4proxy. For obvious obfuscation purposes, the TCP port obfs4 listens on is randomized, although the same port will be used between restarts. That causes an issue for anyone running a bridge on a residential connection, where some form of port forwarding by port and protocol is necessary.</p>
<p>There is a simple work-around to that problem in the torrc file. Just add the following line with the preferred TCP port allowing a long-term setting for the necessary port forward:</p>
<pre><code>ServerTransportListenAddr obfs4 0.0.0.0:$preferred_port
</code></pre>
<h3 id="20170804">20170804</h3>
<p><a id="getting-sick">Getting Sick</a> by gman999</p>
<p>Bananas are a recurring topic for <strong>TDP</strong>. Not because we are particularly strong fans of them, but because the news stories about the Cavendish banana monoculture just don’t stop. Understanding the pitfalls of monocultures in the Tor network is easy enough on some levels, but having an example of a popular and well-documented monoculture makes the case clear to all.</p>
<p>The New York Times ran an article today entitled <a href="https://www.nytimes.com/2017/08/04/nyregion/the-secret-life-of-the-banana.html">The Secret Life of the Urban Banana</a>. Mostly focused on the dynamics of New York City’s banana importing and distribution, the article also points to the dangers of the banana monoculture.</p>
<p>Based in the Bronx’s Hunts Point Produce Market, Top Banana’s Joe Palumbo diversified his own distribution business beyond bananas faced with low-profit margins.</p>
<p>The author of <a href="http://www.nytimes.com/2008/06/18/opinion/18koeppel.html">“Bananas: The Fate of the Fruit that Changed the World”</a>, Dan Koeppel, explains how today’s Cavendish monoculture resulted from the previous Gros Michel banana monoculture. You probably haven’t had a Gros Michel banana recently, as the Panama Disease wiped out commercial production by 1960.</p>
<p>While the Cavenish banana succeeded the Gros Michel as it was resistant to the particular strain of the Panama Disease, it required more extensive infrastructure to ship and store the more fragile Cavendish.</p>
<p>Many realize the dangers of the new monoculture, as the Cavendish could be wiped out by newer strains of the Panama Disease.</p>
<p>Consensus reigns among scientists and laypeople alike that the Cavendish monoculture is poised for collapse, just like previous Gros Michel monoculture debacle.</p>
<p>Monocultures certainly maintain benefits of easily scaling production and a single common-body of knowledge for cultivation and distribution, but as Mr. Koeppel is quoted, “when one gets sick, they all get sick” as all those Cavenish bananas share the same gene pool.</p>
<p>Now consider this statistic about Tor bridge <a href="https://torbsd.github.io/oostats/bridges-os-count.txt">operating system diversity</a>? Enjoying a Gros Michel banana is more likely today than hitting a non-Linux kernel-based bridge.</p>
<h3 id="20170630">20170630</h3>
<p><a id="onionoo-stats-1">OnionOO/JSON-Based Statistics Reports</a> by attila</p>
<p>Preliminary work on switching over to <a href="https://onionoo.torproject.org">OnionOO</a>’s
JSON data for the Tor network is completed. We just put up a repository
with some scripts and sample output: <a href="https://github.com/torbsd/tdp-onion-stats">tdp-onion-stats</a>.
It is a work in progress but is good enough to replace our old
<a href="dirty-stats.html">Quick-and-Dirty Static Reports</a>, which were generated
from the old, non-JSON, non-historical data sources.</p>
<h3 id="20170627">20170627</h3>
<p><a id="bsd-vps">BSD VPS Providers Needed</a> by gman999</p>
<p>One of <strong>TDP’s</strong> recent projects is accumulating a list of virtual private server services (VPS) that provide a BSD option.</p>
<p>VPS’s are generally inexpensive services that enable the user to only concern themselves with software configuration, and not be bothered with hardware or basic operating system setup. In the pre-Cloud era, VPS providers were the “other people’s computers” that users outsourced their systems to.</p>
<p>The same shortcomings of cloud services apply to VPS providers. You don’t control the hardware. Your files are likely viewable by users up the directory hierarchy. The entropy source or pool is a single source for multiple systems. The same time drift applies to all time-keeping services.</p>
<p>Nevertheless, VPS services are often cheap and provide a good spread in terms of geography. All a provider really needs is a few server-grade computers and a decent network connection. VPS’s are still a gateway drug to bare-metal servers, although it seems more and more of these gateway users stop at stage one.</p>
<p>Cheap systems with a public IP are also a great way to tinker with a new operating system.</p>
<p>For this reason, <strong>TDP</strong> created this list of BSD VPS providers. Some explicitly deny running Tor as a server. Some just reference vague “proxy services.” Others don’t mention Tor or proxies at all.</p>
<p><a href="https://github.com/torbsd/torbsd.github.io/blob/master/docs/bsd-vps.md">https://github.com/torbsd/torbsd.github.io/blob/master/docs/bsd-vps.md</a></p>
<p>The current fields, with comma-separated values for easy Unix shell manipulation, include:</p>
<ul>
<li>provider name</li>
<li>www site</li>
<li>1/0 for FreeBSD, NetBSD, OpenBSD and other BSDs</li>
<li>type of provider, such as Xen, VMWare, FreeBSD Jails, KVM or “the cloud”, although we are still wondering what that exactly means</li>
<li>the contact and the contact method, based on our future dialog</li>
<li>the URL of the acceptable use policy/terms of service, where providers usually state forbidden activities</li>
<li>the starting price for the cheapest VPS option</li>
<li>the two-digit country code(s) of the VPS facilities</li>
<li>1/0 for IPv6 support</li>
<li>and finally, any relevant notes, like the odd persistence of Cloudflare for VPS web sites, when one would imagine that a solid provider would host their own web site</li>
</ul>
<p>The list is a start with currently just under 70 VPS providers listed. Input through various channels already started, and <strong>TDP</strong> intends to update the list over the coming months. A first draft email and open letter addressed to the providers were drafted, and we are looking to speak directly to at least some of the better-known BSD VPS providers.</p>
<p>We may be able to convince a few to allow public Tor relays, or at least published bridges. These providers could be new BSD users’ gateway drug into the world of BSD Tor nodes. Running a Tor relay shouldn’t be considered a particularly risky activity. Maybe we can adjust that perception.</p>
<p>Let us know any input via email or GitHub, and we’ll be glad to make updates.</p>
<h3 id="20170626">20170626</h3>
<p><a id="back-to-buildbot">Back to the Buildbot</a> by gman999</p>
<p>Christian S.’s <a href="https://buildbot.pixelminers.net/">Tor BSD Buildbot</a> needs attention again. His Buildbot is a vital tool for Tor core developers to test the Tor development branch on the various BSDs and hardware platforms.</p>
<p>The new 0.9.5 Buildbot software includes a number of noteworthy changes.</p>
<p>First, the new site requires JavaScript enabled to view the site. Also, it is now necessary to make sure that Christian has the hostname and password for each individual Buildbot worker. He can be contacted through the <a href="http://lists.nycbug.org/mailman/listinfo/tor-bsd">Tor-BSD</a>.</p>
<p>There are only two active Buildbot workers at this moment, NYCBUG0 and NYCBUG2. Time to get more Buildbot workers online.</p>
<h3 id="20170415">20170415</h3>
<p><a id="summit-2017-amsterdam">Tor Summit 2017 in Amsterdam</a> by egypcio</p>
<p>Thank you! Honestly, there is no way to start this post. Thank you all! It was an amazing experience and I not just hope to do it again, and again, but also hope to share with others what I learned during the days I stayed in Amsterdam to attend the Summit.</p>
<p>I also “need” to express huge gratitude to some people here: George, Attila, Moritz, Mark, Isabela, drebs, foz, Kali, Alison, Linus, and Jon. You guys rock!</p>
<p>The idea of just reaching out to the Tor Summit 2017 in Amsterdam for me is more than it looks like. My first steps into the Tor Project as user started quite long ago, but getting closer to its community and contributors/volunteers thought the BSDCon Brazil in 2015 and <strong>TDP</strong> was the big deal that brought me here. My on boarding at the <strong>TDP</strong>? You can read about it on <a id="vinicius">this</a> blog post. I really had no idea that I would even be attending the Summit; I left Brazil in December 2016 with no guarantee that it would (legaly) be possible to go there. I already had plans to flight to Serbia and stay there for a while waiting some stupid complications with Visa to settle down. My main goal was to get a job somewhere in Europe to work and live abroad - the current political situation running in Brazil since its last presidential elections doesn’t need to be discussed here. It feels sad to me talking about it. Let’s move on (because life forces us to do it sometimes).</p>
<p>A couple of weeks before the Tor Summit I was getting some codes and patches related to Tor that I had and sending them to my (still not much active) <a href="https://github.com/egypcio">GitHub</a> repositories. Things like the FreeBSD ports for Tor, and the experimental port of the Tor Browser are there now! I also updated a short modified version of a <a href="https://openbsd-br.org/pub/torrc.txt">torrc</a> file and hosted it where people could just get it to start setting up they relays using/reading a more intuitive and reduced version of the huge sample file shipped with Tor - the first draft of this torrc file supported a friend that started the first (public) relay in Paraguay, and it can be easily modified to work as exit node or bridge. There are also information about IPv6 configurations available.</p>
<p>So, a few days before the official date for the Summit I got good news from a company based in Germany regarding one of my job applications. IEI! Guess when I got the Visa? one day before my current one expires :) …and than I started looking for a way to attend the Summit. I was already working on the week of the Summit, so I couldn’t attend to all days and also needed to get a way to Amsterdam only late on Friday 24th. I arrived at the Central Station around 23h, and right after meeting Mark (realitygaps) I went to a little cozy bar with him to try getting in touch with some Tor people. There we met Moritz (<a href="https://torservers.net/">torservers.net</a>) and if it wasn’t for me stupid idea of traveling without a jacket I could stay longer enjoying another beer there. heh.</p>
<p>Getting a bike in Amsterdam was, let’s say, the obvious choice! That was not my first time there, so after getting some food from the wall I got a bike and rode to Mark’s place on the other side of the river. I mentioned to him that I used to get seasick in boat/ferry rides, but luckly nothing bad happened. Nice! At the end, we arrived at his place and chilled a bit. On the next day I needed to get up early and make my way to the Arena. I was part of two nice sessions: <a href="https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam/Notes/PluggableTransports">Pluggable Transports</a>, and <a href="https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam/Notes/CorpOnionServices">Convincing Big Companies</a>; got a lot from what people said, and also shared some toughts. It was awesome! Later on that day I was also in touch with amazing people getting feedback about the impact Tor plays in many different ways against censourship, how it really supports anonymity, and also how its community really matters to the Globe. I also got closer to people from other projects I used and only knew on the Internet (like <a href="https://ooni.torproject.org">OONI</a>, and others). Olá Derechos Digitales, e Primavera Hacker! Sorry I missed the <a href="https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam/Notes/GlobalSouth1">first session</a> of the Global South meetings :
I did not went to any party of late meeting on the Saturday 25th; not just because I was <em>really</em> dead tired, but I also wanted to chill an put some ideas, notes, and few lines of code in practice. That night was a regular pizza+code night, but was the best one I ever had. I would like to point you isis’ <a href="https://github.com/isisagoralovecruft">GitHub</a> repositories; there are many interesting things you can get and contribute from there. Cool stuff though!</p>
<p>As it also doesn’t hurt to remember, if you do have some time to test Tor, try getting the latest code from its <a href="https://gitweb.torproject.org">Git</a> repository and play with it. If you are interested on tests running in different BSD platforms, please check (and try to contribute to) Christian S’s <a href="https://buildbot.pixelminers.net">BuildBot</a>!</p>
<p>Well… Sunday 26th! On that day I could reach people from the Global South and went to the <a href="https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam/Notes/GlobalSouth2">second session</a>. Great discussions that took us to a little 15 minutes pause, and than the part 2 of the second session could start. There we talked about getting more legal support, more effective ways to deploy relays/bridges/nodes, new approaches to spreach the word of Tor and so on. It looks like we will have a meeting, or even a Summit, on latin America soon. Right? During the session I also compromised myself to write materials in portuguese+spanish (portuñol? heh) to help more people to get close to Tor and its benefits - I already started doing it, and hope to commit some posts soon after this post I am writting you. We are on IRC, btw! #tor-south@oftc :)</p>
<p>Later that day Moritz introduced me to Nick, and we talked about the FreeBSD port for the Tor Browser. I sure got pretty nifty feedback and incredible ideas to work with. There I decided to split the port into 2 “combined” ports; one for the main browser, and other to take care of the extensions - so if we need just a simple update on the extensions, there will be no need to rebuild the entire browser again. Other ideas, regarding the dedicated user profile, also considered the use of ZFS volumes to run the Tor Browser; sounds a good idea, but we might consider different use cases and host scenarios. I trully need to test it a bit more, and patch some stuff (specially because the Tor Browser port is conflicting with the extended support version of Firefox). Well, at the end, it’s gonna be just fine :)</p>
<p>My last hours in Amsterdam were incredible! Again, a big thank you to drebs, foz and kali that got me a sweet and cozy couch! So, at 4h00 I cycled from Kali’s to the Central Station, dropped the bike and there I got my train back to Germany and went to work. Arrived just in time; 10h00. Worth it every single second. Thank you everyone! </p>
<p>If I really did not list your name here, it doesn’t mean that you did not help me; it goes for 100% of the people I listened or talked to (on IRC, on any mailing list).</p>
<h3 id="20170403">20170403</h3>
<p><a id="android-takeover">Android Overtaking Windows and OS Diversity</a> by gman999</p>
<p>The central focus of <strong>TDP</strong> is operating system diversity by extending BSD Unix into the Tor network on all levels. From *BSD relays to Tor Browser ported to OpenBSD, <strong>TDP</strong> looks to hinder the capability of one operating system-specific vulnerability to harm the integrity of the entire Tor network.</p>
<p>From a different angle, <a href="http://gs.statcounter.com/press/android-overtakes-windows-for-first-time">Android edging out Windows</a> as the primary client operating system is a notable change.</p>
<p>The user “desktop” no longer necessarily resides at the user’s desk. Particularly in less-developed countries and among many working-class people, the main platform for accessing the internet is the phone. Essentially, there is a definition shift in client internet-accessing systems, and Android takes the day with some 37.93% of the market.</p>
<p>This is a far cry from the old <a href="https://cryptome.org/cyberinsecurity.htm">desktop monoculture debate (PDF warning)</a> from the early 2000’s. It was only a matter of time before Android took the cake as the role of the phone changed and Android dominates the cheaper end of the phone market globally.</p>
<p>Of course operating system diversity for internet-accessing platforms is good. The question is really is this “good enough”?</p>
<p>Android systems tend to cover a range of versions, some patched to addressed security vulnerabilities, but most are not. There are some interesting new Android forks such as <a href="https://copperhead.co/android/">CopperheadOS</a>, but mass adoption seems unlikely in the forseeable future.</p>
<p>No one gets bumped from their cellular carrier when their phone’s Android version faces an end-of-life development status, and many providers aren’t particularly interested in devoting resources to maintaining multiple branches of Android, and providing timely patching of known issues.</p>
<p>Replacing a Windows monoculture with a Windows/Android mix might seem like a significant step forward in terms of vulerability mitigation, but merely replacing crud with two cruds can’t be considered a victory for the security community.</p>
<p>The interesting angle might really be that the “desktop” is now attached to the end-user one linear step away from science fiction <a href="https://en.wikipedia.org/wiki/Cyborg">Cyborg reality</a>, and that cell phone network providers and device manufacturers are not better than Microsoft at handling security disclosures. In fact, with hundreds of network providers and handset manufacturers now populating the Android market, it’s no longer about convincing one software company to address security issues. The goal of reasonably secure client systems seems more of a delusion than even a remote possibility with the decline of the Microsoft monoculture.</p>
<p>Yes, some diversity can be <em>worse</em> for security and network integrity.</p>
<h3 id="20170401">20170401</h3>
<p><a id="tor-motives"><strong>What Motivates You to Run a Tor Relay?</strong></a> by gman999</p>
<p>Everyone who contributes to open source projects is driven by some combination of motives. For Tor relay operators, simply taking an occasional glance at the connection statistics should be sufficient.</p>
<p>Only in its second full day of operation, <a href="https://torstatus.rueckgr.at/router_detail.php?FP=577b81cd1fce5b3e7c1bd286774">OpenBSDBBB</a>, the new <strong>TDP</strong> relay running OpenBSD on a teeny-weeny BeagleBone Black is pushing some 1.31MB of bandwidth. The entry-stats gives us a good sense of many global users assisted:</p>
<pre><code>entry-ips us=296,jp=104,de=96,fr=96,es=88,it=72,ru=72,br=48,ar=32,bg=32,ca=32,gb=32,nl=32,pl=32,se=24,ua=24,au=16,gr=16,in=16,mx=16,th=16,ae=8,al=8,am=8,at=8,az=8,ba=8,bb=8,bd=8,be=8,by=8,ch=8,cl=8,cn=8,co=8,cr=8,cy=8,cz=8,dk=8,dz=8,ec=8,eg=8,fi=8,ge=8,hk=8,hu=8,id=8,ie=8,il=8,iq=8,ir=8,is=8,jm=8,ke=8,kh=8,kr=8,kw=8,ky=8,la=8,lk=8,lt=8,lu=8,lv=8,ma=8,md=8,mu=8,my=8,mz=8,no=8,pe=8,ph=8,pr=8,pt=8,py=8,qa=8,re=8,ro=8,rs=8,sa=8,sg=8,si=8,sk=8,sy=8,tn=8,tw=8,uy=8,uz=8,ve=8,vn=8,za=8
</code></pre>
<p>Simply adding lines like this to a torrc file produces wonderful motivations:</p>
<pre><code>EntryStatistics 1
</code></pre>
<p>Bridge operators can add this to their torrc to get similar statistics:</p>
<pre><code>BridgeRecordUsageByCountry 1
</code></pre>
<p>Yes, a simple point. But all the more powerful when it provides a snapshot into a relay’s users as they evade censorship and surveillance in a 24 hour period.</p>
<h3 id="20170330">20170330</h3>
<p><a id="busy-bbb"><strong>BeagleBone Online and Busy</strong></a> by gman999</p>
<p>The BeagleBone Black Tor relay is fully operational and according to both <a href="https://torstatus.rueckgr.at/router_detail.php?FP=577b81cd1fce5b3e7c1bd286774758608e50aeeb">one of the Tor Status sites</a> and Tor Atlas, is already pushing about 1 MBps.</p>
<p>It’s not up on the <a href="https://buildbot.pixelminers.net/">Buildbot</a> yet, but should be once some technical glitches are resolved on our end.</p>
<p>There is a number of advantages to this and similar relays.</p>
<ul>
<li><p>OpenBSD is unique among relay operating system platforms for a number of reasons, including its usage of <a href="https://www.libressl.org/">LibreSSL</a> as opposed to ubiquitous OpenSSL. At the moment, only some 1.42% of relays are running OpenBSD.</p></li>
<li><p>the BeagleBone is an armv7 platform, which stands outside the normal x86 monoculture. All hardware has its own share of advantages and disadvantages from the security-level. But the x86 monoculture is a scary one and often over-looked when assessing operating system diversity. The BeagleBone is open source hardware, and is not saturated with ugly binary blobs so common on x86.</p></li>
<li><p>finally, the BeagleBone is an Altoids-sized, fanless and silent computer easily accomodated in any data center cabinet, and draws insignificant electricity. And considering the amount of under-utilized bandwidth on so many residential connections in places like the US, the BeagleBone is ideal hardware for Tor bridges for any home. Pop some into your friends’ and family’s homes, and assist those with censored internet connections around the world.</p></li>
</ul>
<p>A final configuration tweak now that the relay seems to be hitting its stride.</p>
<p>OpenBSD is pleasantly stingy in allowing the number of files to be opened per daemon. This restriction works both for security purposes and for a consideration for systems with lesser resources. The tor daemon, to be able to hit its peak bandwidth, likely needs a bump in those values.</p>
<p>There’s two quick changes, on that note.</p>
<p>Increase the number of files that can be opened, assuming there is no previously configured /etc/sysctl.conf file:</p>
<p>$ echo “kern.maxfiles=20000” >/etc/sysctl.conf</p>
<p>To enble that change without a reboot:</p>
<p>$ sysctl kern.maxfiles=20000</p>
<p>Next allow the tor daemon to increase its own openfiles limit, edit the /etc/login.conf file and add the following:</p>
<pre><code>tor:\
:openfiles-max=8192:\
:tc=daemon:
</code></pre>
<p>While testing node configuration changes on a (mostly) randomized anonymity network is hard to measure, removing those limits can remove some local hindrances.</p>
<h3 id="20170328">20170328</h3>
<p><a id="obsd-bbb"><strong>Tor Relay on a BeagleBone Black Running OpenBSD -current</strong></a> by gman999</p>
<p>For anyone who hasn’t gotten the news, x86 hardware no longer reigns supreme in server land. For years other architectures, namely ARM, are increasingly moving beyond esoteric or hidden purposes. ARM isn’t just for your cell phone anymore.</p>
<p>On that note, <strong>TDP</strong> is set up a Tor relay on a <a href="https://beagleboard.org/black">BeagleBone Black</a> running OpenBSD. The OpenBSD <a href="https://www.openbsd.org/armv7.html">armv7 platform</a> covers some of the more popular armv7 hardware, including the <a href="https://www.wandboard.org/products/">Wandboard</a>, [Cubieboard](http://cubieboard.org/], <a href="http://www.banana-pi.org/">Banana Pi</a>, not to mention other BeagleBones and the <a href="https://beagleboard.org/beagleboard-xm/">BeagleBoard</a>.</p>
<p>The dmesg for the relay is <a href="http://dmesgd.nycbug.org/index.cgi?do=view&id=3140">on NYC*BUG’s dmesgd</a>. The device joined the Tor network today, and will be joining the <a href="https://buildbot.pixelminers.net/">Unofficial BSD Buildbot</a> maintained by Christian S. soon.</p>
<p>OpenBSDBBB is listed on <a href="https://torstatus.rueckgr.at/router_detail.php?FP=577b81cd1fce5b3e7c1bd286774758608e50aeeb">Tor Status</a> and also on <a href=https://atlas.torproject.org/#details/577B81CD1FCE5B3E7C1BD286774758608E50AEEB">on the Tor Project’s Atlas</a>.</p>
<p>The stable release of OpenBSD is 6.0, but this relay is running -current. Both net/tor and devel/py-buildslave are available as OpenBSD armv7 packages, making the setup easy enough.</p>
<p>The RelayBandwidthRate is set to 5000 KBytes and bursting to 6000 KBytes, and it will be worthwhile seeing if that rate is attainable.</p>
<p>A quick note on configuration. There are four partitions, as the output of df(1) illustrates:</p>
<pre><code>Filesystem Size Used Avail Capacity Mounted on
/dev/sd1a 491M 42.9M 423M 9% /
/dev/sd1f 1.4G 10.2M 1.3G 1% /home
/dev/sd1d 1.5G 521M 907M 36% /usr
/dev/sd1e 192M 77.7M 105M 43% /usr/local
mfs:54396 48.4M 4.0K 45.9M 0% /tmp
</code></pre>
<p>/tmp is running off RAM with mfs.</p>
<p>The ports tree is mounted on a 16G microSD card. It will enable us to build and test new ports on armv7. <strong>TDP</strong> is looking at porting other relevant PETs applications such as <a href="https://onionshare.org/">OnionShare</a> and finally moving <a href="https://github.com/jasperla/openbsd-wip/tree/master/net/obfsproxy">obfsproxy</a> into the official ports.</p>
<p>Running on -current might seem counter-intuitive, as it is the OpenBSD development branch, and may contain bugs and breaks. But like the tor-alpha branch, OpenBSD’s -current gets a lot of attention, and also includes the latest stable Tor port which is tor–0.2.9.9p0. While -current snapshots can be released multiple times a day on occasion, updating on a weekly basis is usually sufficient.</p>
<h3 id="20170324">20170324</h3>
<p><a id="calling-bsd"><strong>Calling All BSD Firms</strong></a> by gman999</p>
<p>A lot of major firms use BSDs. You just aren’t probably aware of them.</p>
<p>From WhatsApp to Juniper and Netflix, and blue-chip storage vendors like NetApp and Isilon, the BSDs are quietly omnipresent.</p>
<p>Some use the BSDs in their infrastructure, others use BSD code in their products. The liberal BSD license places negligible restrictions on the code usage, but doesn’t compel firms to publicize it.</p>
<p>The BSD license, whether the two- or three-clause versions, are catered for developers to share code, in that they are clear and succinct, and don’t require a lawyer to interpret them. Of course if you ask a lawyer, they will try to convince you legal counsel is necessary for reading a menu at a restaurant.</p>
<p>Many of the firms contribute code back into the BSD projects, a number also provide infrastructure, while others donate to projects such as <a href="http://www.openbsdfoundation.org/contributors.html">OpenBSD</a> and <a href="https://www.freebsdfoundation.org/donors/">FreeBSD</a>.</p>
<p>There’s always room for a little more.</p>
<p><strong>TDP</strong> is going to be putting out a public call in the near future, asking BSD-employing firms to run a Tor relay on their preferred BSD. These entities already maintains the infrastructure, staff and know-how and can easily work in another bare-metal server into their operation. </p>
<p>In December 2014, the Mozilla Foundation began <a href="http://www.pcworld.com/article/2877592/mozilla-puts-old-hardware-to-new-use-runs-tor-relays.html">running 12 Tor relays</a>. <strong>TDP</strong> believes this is an effort that needs to be replicated by BSD-using firms and entities. Hosting relays as corporate infrastructure provides legitimacy to online free speech.</p>
<p>BSD firms running Tor relays benefits the BSDs, the privacy enhancing community and the firms themselves, and our open letter should clearly make that case.</p>
<h3 id="20170317">20170317</h3>
<p><a id="tsummit-amsterdam"><strong>March in Amsterdam</strong></a> by gman999</p>
<p>For a variety of reasons, only one of us will be attending the upcoming <a href="https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam">Tor Summit in Amsterdam</a>. If you are attending, please make sure you speak to Vinicius.</p>
<p>Huge thanks to <a href="https://www.torservers.net/">torservers.net</a> for the last minute support for him. Enormously appreciated.</p>
<h3 id="20170227">20170227</h3>
<p><a id="current-relays"><strong>Running OpenBSD -current for Tor Relays?</strong></a> by gman999</p>
<p>The question of which branch or flavor of OpenBSD to use for a Tor relay is a frequent point of mention.</p>
<p>OpenBSD maintains three <a href="https://www.openbsd.org/faq/faq5.html#Flavors">flavors</a>:</p>
<ul>
<li><p>-release which comes out every six months as sure as the sun rises, if not earlier on occasion</p></li>
<li><p>-stable which includes the addition of necessary patches</p></li>
<li><p>and finally, -current, the bleeding edge of OpenBSD development, which updates regularly and sometimes <em>very</em> frequently</p></li>
</ul>
<p>The logical notion is that -stable or even -release should be the Tor relay platorm choice. It does seem to be the most common recommendation.</p>
<p>Yet there are a number of things to consider, and we tend to favor -current as the best option in most use-cases for any OpenBSD box.</p>
<p>First, what is -current in OpenBSD is not some wildly unusable system. -current is the platform for OpenBSD development, in that it is the flavor on which OpenBSD developers actually work. Not a few production servers run on -current, and most significant problems are quickly resolved.</p>
<p>The other issue to consider is that OpenBSD’s ports development takes place on -current. Therefore the most current OpenBSD ports are found in -current. net/tor is at version 0.2.9.9 with a single revision, while -stable is still at Tor 0.2.7.6 with three revisions.</p>
<p>And no, for the inquisitive, OpenBSD does not support alpha or beta software in its ports tree, which excludes the Tor development branch.</p>
<p>Updating -stable isn’t difficult, which ever <a href="https://www.openbsd.org/faq/faq10.html#Patches">updating routes</a> chosen. But following -current with the regular snapshots is equally simple. <a href="https://bsdly.blogspot.com/2012/07/keeping-your-openbsd-system-in-trim.html">This guide from Peter Hansteen</a> is dated, but gives the gist of the procedure.</p>
<p>Just because -current can update as frequently as a few times a day at times, doesn’t mean the Tor relay operator has to update the system each time. If one can keep a -current relay updated weekly, it should be fine.</p>
<p>The one other thing to note is that physical or serial console (or similar) access is also necessary for updating -current, as one has to boot off the bsd.rd kernel.</p>
<h3 id="20161217">20161217</h3>
<p><a id="vinicius"><strong>Welcome Aboard, Vinicius</strong></a> by gman999</p>
<p>Two of us launched <strong>TDP</strong> in March 2015. The accomplishments are substantial, and the impact is significant. <strong>TDP</strong> did more than raise the PETs flag in BSD land, it sparked a number of related projects and efforts.</p>
<p>One important player in the broad effort has been Vincius Zavam, a young BSD hacker in Brazil. Introduced to PETs and Tor in particular as he was an organizer of BSDCon Brasil in 2015, Vincius wasted no time engaging on multiple levels.</p>
<p>He not only started running a number of Tor relays on several BSDs, he also assisted others in Brazil. Without any external assistance, he began porting Tor Browser to FreeBSD, an enormously important endeavor. And most recently, he did a presentation on Tor with a focus on the BSDs.</p>
<p>He is not just full of energy and ingenuity, he is also a pleasure to work with. His locale of Brazil is another advantage which he has utilized to the fullest. He has provided patches to the FreeBSD security/tor port several times and is active on the <a href="http://lists.nycbug.org/mailman/listinfo/tor-bsd">Tor-BSD mailing list</a>.</p>
<p>Like the other <strong>TDP</strong> members, he might favor one BSD over another for different tasks, but “BSD agnosticism” is his ideology. Although this <a href="https://twitter.com/HenningBrauer/status/741485723778453504">tweet</a> might belay his deepest allegiance.</p>
<p>Welcome aboard, Vinicius. Our efforts are ongoing without monetary compensation. There is no pot of gold awaiting us, but if we can continue to enhance Tor and the PETs scene in general, the satisfaction is priceless.</p>
<h3 id="20161113">20161113</h3>
<p><a id="inthetree"><strong>In The Tree</strong></a> by attila</p>
<p>It was a long haul but the Tor Browser ports were finally <a href="https://marc.info/?l=openbsd-ports-cvs&m=147907177720815&w=2%29">accepted into the OpenBSD ports tree today</a>.</p>
<p>A huge thanks to <code>landry@</code>, <code>semarie@</code>, <code>danj@</code>, <code>mmcc@</code> and all the
other <code>ports@</code> people who made this possible with their critiques,
observations, pointers, suggestions and just plain work.</p>
<p>Now we’ve got to get cracking on <a href="https://www.torproject.org/docs/pluggable-transports.html.en">Pluggable Transports</a>. We won’t stop not stopping.</p>
<h3 id="20161025">20161025</h3>
<p><a id="morebananas"><strong>More Bananas</strong></a> by gman999</p>
<p>The easiest way to convey the problems with monocultures in technology is to point to a stark monoculture common to many: bananas.</p>
<p>The <a href="https://en.wikipedia.org/wiki/Cavendish_banana">Cavendish banana</a> is a non-reproducing variant that dominates global production, and is most likely the one encountered. The Guardian published an article entitled <a href="https://www.theguardian.com/commentisfree/2016/oct/25/banana-farming-danger-cavendish-crop-genetics">“The banana as we know it is in imminet danger”</a> regarding efforts to diversify banana types.</p>
<h3 id="20161017">20161017</h3>
<p><a id="signifysanity"><strong>signify(1) Sanity</strong></a> by gman999</p>
<p><a href="http://man.openbsd.org/signify">signify</a>(1) was released in 2014 as a simple means of signing and verifying files on OpenBSD.</p>
<p>What does signify have to do with <strong>TDP</strong>?</p>
<p>The current and standard practice for verifying the integrity of digial signatures on software is to use <a href="https://www.gnupg.org/">GnuPG</a>. The <a href="https://www.torproject.org/docs/verifying-signatures.html.en">procedure</a> is tedious, and likely ignored by most TB users.</p>
<p>signify is small and sticks to the Unix approach of doing one function.</p>
<h3 id="20161005">20161005</h3>
<p><a id="test605"><strong>Test Tor Browser 6.0.5 for OpenBSD</strong></a> by gman999</p>
<p>The release of TB 6.0.5 has been worked and reworked, and submitted to the <a href="https://marc.info/?l=openbsd-ports&m=147552847908620&w=2">OpenBSD ports@ list</a>.</p>
<p>If you’re an OpenBSD user running amd64 snapshots, and you want more operating system on the Tor network, you should be testing it. As always, consider this release without warranties and a serious infraction to your online anonymity!</p>
<p>The amd64 packages are on the <a href="http://mirrors.nycbug.org/pub/snapshots/packages/amd64/">NYC*BUG mirror</a>. The i386 packages should be up in the next day or so.</p>
<p>Feedback, comments, gripes not just welcomed, but demanded.</p>
<h3 id="20161004">20161004</h3>
<p><a id="torblog0"><strong>Replying to Tor Blog Comments</strong></a> by gman999 and attila</p>
<p>The last Tor blog post on <a href="https://blog.torproject.org/blog/tor-0288-released-important-fixes">Tor 0.2.8.8 is released, with important fixes</a> prompted a flurry of comments regarding the BSDs and the Tor Project.</p>
<p>An important part of the Tor 0.2.8.8 release was a fix for bug #<a href="https://bugs.torproject.org/20103">20103</a> discovered by <strong>TDP</strong>. 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.</p>
<p>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.</p>
<p>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:</p>
<p><em>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.</em></p>
<p>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 <a href="https://trac.torproject.org/projects/tor/wiki/org/meetings/2016SummerMeeting">Seattle Tor Summit</a> illustrated the great attention <strong>TDP</strong> is getting; he was personally flattered by the recognition.</p>
<p>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. <a href="https://github.com/login?return_to=%2Ftorbsd%2Fopenbsd-ports">Fork the code</a>, <a href="https://github.com/torbsd/openbsd-ports/issues">submit a useful issue</a>, and so on, but complaining anonymously on a blog about what <em>others</em> should do is pointless at best.</p>
<p><em>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…</em></p>
<p>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 <strong>TDP</strong> www site, yet in the previous comments says the TP “has no plans at all to release Tor Browser Bundle for *BSD operating systems.”</p>
<p>Nick M, Roger D, and others actively use the <a href="https://buildbot.pixelminers.net/">BSD Buildbot</a> initiated by Christian S., and we have corresponded about it. Roger made multiple references to <strong>TDP</strong> 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 <strong>TDP</strong> endeavor.</p>
<p>More generally: yes, the recent vulnerability from <a href="https://tools.ietf.org/html/rfc5961">RFC5961</a> 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.</p>
<p>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 <a href="https://www.freebsd.org/platforms/arm.html">FreeBSD</a>.</p>
<p><em>Moroever OpenBSD users prefer to download Tor Browser Bundle directly from The Tor Project as the latter is the official software publisher of Tor.</em></p>
<p>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.</p>
<p>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 <a href="https://marc.info/?l=openbsd-ports&r=1&w=2">ports@ mailing list</a>, 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.</p>
<p>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 <code>/etc/signify</code> 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: <a href="https://stable.mtier.org/">M:Tier</a>, 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.</p>
<p><em>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?</em></p>
<p>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 <strong>TDP’s</strong> court right now. <strong>TDP</strong> will need more TP involvement in the near future.</p>
<p>Regarding a version of TAILS on a BSD: <em>It will never happen as *BSD kernels are notorious for being behind in their support for the latest Intel CPUs.</em></p>
<p>This is really just <a href="https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt">FUD</a>: 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.</p>
<p>Producing a TAILS-like alternative based on OpenBSD has been a goal of <strong>TDP</strong> since its inception. We’re still on the first step: porting TBB to OpenBSD.</p>
<p>And again regarding the RFC5961 issue in Linux: <em>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.</em></p>
<p>We aren’t focused on ‘superiority’ although most people who choose an operating system logically consider it superior on some level or another.</p>
<p>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.</p>
<p><em>I don’t understand why you brought Apple into the discussion.</em></p>
<p>and,</p>
<p><em>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.</em></p>
<p>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.</p>
<p>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.</p>
<p>That’s it for now.</p>
<h3 id="20160906">20160906</h3>
<p><a id="current0"><strong>Where Things Stand</strong></a> by gman999</p>
<p>A brief list of where things stand with <strong>TDP</strong>:</p>
<ul>
<li><p>Tor Browser 6.0.4 is in the testing phase, but looking good. Builds for i386 should start today.</p></li>
<li><p>One of us will be attending the <a href="https://trac.torproject.org/projects/tor/wiki/org/meetings/2016SummerMeeting">Tor Summit</a>. Many invites, but it’s usually at a bad time for us.</p></li>
<li><p>The <a href="https://buildbot.pixelminers.net">BSD Buildbot</a> is more populated since our last call-to-enlist, but operators need to make sure the buildslave software is up and running.</p></li>
<li><p><a href="dirty-stats.html">Quick-and-Dirty Static Reports</a> is being updated regularly, but still manually and not consistently. Note that there has been a small but noticeable dip in the *BSD relays, and the number of countries without relays hovers over 85 recently.</p></li>
</ul>
<p>That’s the status right now. Updates should be happening in the near future.</p>
<h3 id="20160818">20160818</h3>
<p><a id="buildbot"><strong>The Buildbot Needs BSD Relays</strong></a> by gman999</p>
<p>One of the small yet important projects spawning from this Tor-BSD meme is Christian S.’s <a href="https://buildbot.pixelminers.net">BSD Buildbot</a>. Essentially it’s a tool for development builds of Tor for the Tor Project, with volunteers enlisting their BSD relays.</p>
<p>Recently its relevance was reinforced due to some libevent issues with OpenBSD and Tor. The OpenBSD base includes libevent, and libevent2 is a dependency port (LIB_DEPENDS) for the Tor port. Tor Project Trac tickets include <a href="https://trac.torproject.org/projects/tor/ticket/19902">19902</a> and <a href="https://trac.torproject.org/projects/tor/ticket/19904">19904</a>.</p>
<p>To enlist a BSD relay in the buildbot:</p>
<ul>
<li><p>Make sure that devel/git and devel/autotools is installed on the functioning Tor relay, the latter of which includes devel/autoconf and devel/automake as dependencies.</p></li>
<li><p>Create a non-privileged user for the buildbot, without any particular group outside of its own.</p></li>
<li><p>On FreeBSD and DragonFly BSD, install devel/buildbot-slave. On NetBSD, install devel/py27-buildbot-slave. On OpenBSD and Bitrig install devel/py-buildslave.</p></li>
<li><p>As the non-privileged user, run this command:</p></li>
</ul>
<pre><code>$ buildslave create-slave slave buildbot.pixelminers.net:9989 <buildername> <password>
</code></pre>
<p>where <buildername> is something you choose, and <password> is your key for the particular slave.</p>
<ul>
<li><p>In the new user’s directory, a slave/ directory will be created. Edit slave/info to provide a description, like the particular BSD, the architecture and maybe BSD release version, plus edit slave/admin to provide an (obscured) contact email for the buildbot slave.</p></li>
<li><p>Finally, run this command to join the buildbot, from the new user’s directory:</p></li>
</ul>
<pre><code>$ buildslave start slave/
</code></pre>
<p>For OpenBSD buildbot relays, /etc/profile needs to list the installed versions of autoconf and automake, as per <a href="http://lists.nycbug.org/pipermail/tor-bsd/2015-March/000270.html">this email</a> to the <a href="http://lists.nycbug.org/mailman/listinfo/tor-bsd">Tor-BSD mailing list</a>.</p>
<pre><code>export AUTOCONF_VERSION="2.69"
export AUTOMAKE_VERSION="1.14"
</code></pre>
<p>Assuming everything is configured correctly, the buildbot slave should appear on <a href="https://buildbot.pixelminers.net/buildslaves">https://buildbot.pixelminers.net/buildslaves</a>, and the log in slave/twistd.log should provide results.</p>
<p>Also: yes, we think the terminology of buildbot “slave” and “master” are inappropriate, and we only use them since they are the actually commands and lingo. The terms are not even descriptively useful to someone new to the concept of a continuous integration system.</p>
<h3 id="20160629">20160629</h3>
<p><a id="quiet-progress"><strong>So Much Quiet Progress</strong></a> by gman999</p>
<p>This blog remained silent over the past several months despite a flurry of very significant <strong>TDP</strong> activities.</p>
<p>The accomplishments are not reducible to a single blog entry, but here are summaries of the more interesting:</p>
<ul>
<li><p>There was continued development and the release of several Tor Browser versions. Packages for 6.0 and 6.0.2 (the current version) were produced. The OpenBSD packages for both amd64 and i386 are available at http://mirror.nycbug.org/pub/snapshots/packages/{amd64,i386}. With feedback from the OpenBSD ports@ mailing list, another version of TB 6.0.2 is in the works.</p></li>
<li><p>We held a presentation at BSDCan 2016 in Ottawa, Canada in June. The presentation, entited <a href="https://www.bsdcan.org/2016/schedule/events/712.en.html">Beyond Monocultures</a> is hosted on <a href="https://www.youtube.com/watch?v=KeQWET79t_Y">YouTube</a>. The meeting was engaging and filled with discussion, and there were some exciting possibilities produced by the meeting, including a code audit offered by a well-respected information security firm, plus some preliminary plans to port our TB code to <a href="https://hardendedbsd.org">HardenedBSD</a>.</p></li>
<li><p>Also as a consequence of BSDCan, Brian Conway of <a href="https://stable.rcesoftware.com/resflash/">resflash</a>, a flash-based OpenBSD build system began producing <a href="https://stable.rcesoftware.com/pub/resflash/tor/">images with a Tor relay pre-configured</a>. We have been exploring such a system for Tor bridges, with either resflash or <a href="http://www.nmedia.net/flashrd/">flashrd</a>, but are glad to see Brian took the initiative.</p></li>
</ul>
<p>We would have replied to the RFP for <a href="https://2016.eurobsdcon.org/">EuroBSDCon 2016 in Belgrade, Serbia</a> but the <strong>TDP</strong> schedule doesn’t permit.</p>
<h3 id="20160331">20160331</h3>
<p><a id="tb-snaps-status2"><strong>TB 5.5 on the Current Snapshots</strong></a> by gman999</p>
<p>As of last week’s OpenBSD’s i386 and amd64 snapshots, TB 5.5 is no longer working.</p>
<p>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.</p>
<p>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.</p>
<p>Meanwhile, the <a href="dirty-stats.html">Quick-and-Dirty Static Reports</a> are still updated regularly, albeit manually still.</p>
<p>Additionally, a lot of time has been recently committed to <a href="porting-pets.html">Porting Targets for PETs</a>. 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.</p>
<p>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 <a href="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bash">shell</a> or another. What does <a href="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bash">bash</a> provide that the install script requires? I mean, really? For the vast majority, a 1995 Bourne shell would be more than sufficient.</p>
<p>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. </p>
<h3 id="20160320">20160320</h3>
<p><a id="portpets-up"><strong>Porting PETs Updates</strong></a> by gman999</p>
<p><a href="porting-pets.html">Porting Targets for PETs</a> is meant as a hit list of privacy enhanncing related ports that may or may not be in the main BSD port/package systems. As we make clear on the page, some should be considered for entry into BSD ports systems, while others may not be good candidates for a variety of reasons.</p>
<p>As we (manually) update the project page, a few points come to our attention:</p>
<ul>
<li><p><a href="https://firstlook.org/code/project/pdf-redact-tools/">pdf-redact-tools</a> is now in NetBSD’s cross-platform ports system, pkgsrc.</p></li>
<li><p><a href="https://gitweb.torproject.org/torsocks.git/">torsocks</a> isn’t in the pkgsrc tree, which comes as a surprise (and correction).</p></li>
<li><p><a href="https://www.cypherpunk.at/onioncat_trac/">onioncat</a> was added to the list, and it’s also not in the pkgsrc tree. The OpenBSD version is outdated.</p></li>
<li><p>Since our last update, we’re happy to see that <a href="https://ricochet.im/">ricochet</a> is now in DragonFly BSD’s DPorts system.</p></li>
<li><p><a href="https://gitweb.torproject.org/pluggable-transports/obfsproxy.git">obfsproxy</a> is not in the OpenBSD ports tree, but it is in the GitHub <a href="https://github.com/jasperla/openbsd-wip">work-in-progress ports</a>. obfsproxy also isn’t in the pkgsrc tree. Pluggable transports are worthwhile ports to consider, since the censorers are fond of blocking Tor traffic.</p></li>
<li><p>We are excited there’s a pkgsrc <a href="http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/security/tor-browser/README.html">attempt to port Tor Browser</a>. We have reached out to the developer directly and indirectly several times, but have not heard back unfortunately. Our <strong>TDP</strong> fellow-travellers tried to reach out to the developer, ryoon AT netbsd.org, at [AsiaBSDCon](https://2016.asiabsdcon.org/] last week, but were unable to find him. We do hope to hear back from him at some point to synchronize our efforts. We are sure there’s a lot to learn from each others’ experiences.</p></li>
<li><p>Besides torsocks, pkgsrc doesn’t contain a <a href="https://stem.torproject.org/">stem</a> port which is vital for tools like <a href="#pkg-arm">arm</a> and for any tool that talks to the Tor control port.</p></li>
</ul>
<p>Don’t hesitate to ping us if you’re interested in addressing anyone of the above ports. We can direct you to the appropriate mailing list or developers, or dump any Makefiles we may have already created.</p>
<p>At this point, <strong>TDP</strong> isn’t focusing on porting these applications, but unofficially we have begun to toy with some of them.</p>
<h3 id="20160310">20160310</h3>
<p><a id="tb-snaps-status1"><strong>STATUS: TB 5.5 and i386/amd64 Snapshots</strong></a> by gman999</p>
<p>Tor Browser 5.5 is still working with the newest OpenBSD snapshots, which is #1638 for <a href="http://www.openbsd.org/i386.html">i386</a> and #1918 for <a href="http://www.openbsd.org/amd64.html">amd64</a>.</p>
<h3 id="20160303">20160303</h3>
<p><a id="tb-snaps-status0"><strong>STATUS: TB 5.5 and i386/amd64 Snapshots</strong></a> by gman999</p>
<p>TB 5.5 is working fine with the newest OpenBSD snapshots:</p>
<ul>
<li><p>amd64 is #1890</p></li>
<li><p>i386 is #1618</p></li>
</ul>
<h3 id="20160301">20160301</h3>
<p><a id="bsdcan0"><strong>TDP at BSDCan 2016</strong></a> by gman999</p>
<p>Our presentation entited <a href="https://www.bsdcan.org/2016/list-of-talks.txt">“Beyond Monocultures”</a> was accepted for <a href="https://www.bsdcan.org/2016/">BSDCan 2016</a> on June 10–11 in Ottawa, Canada.</p>
<p>We feel very fortunate, since there were a lot of submissions for what is the premier BSD event in the western hemisphere. BSDCan has grown substantially since 2004, with hundreds of attendees participating.</p>
<p>Last year we conducted a <a href="https://www.bsdcan.org/2015/schedule/track/BOF/624.en.html">birds-of-a-feather session</a> which attracted around 50 people.</p>
<p>This year, we should hopefully have some good news to publicize about <strong>TDP</strong>. In the meantime, the actual presentation should start coming together in the next month or so. In all honesty, it’s hard to determine what the focus of the presentation should be. We only have a general idea of where we’ll be by mid-June.</p>
<p>At this point, the introductory part should start with “Why Tor Sucks” plagiarizing Henning Brauer’s <a href="https://quigon.bsws.de/papers/2015/asiabsdcon/index.html">OpenBSD Sucks</a> concept. This is a backhand approach to arguing why Tor matters. The reality is that a lot of people in the BSD community continue to see Tor as ineffective or insecure, so the case for Tor being full of problems yet the very best thing available needs to be made.</p>
<p>It’s not that BSD people overwhelmingly aren’t concerned with security and privacy. At the bar last at BSDCan last year, surrounded by some of the best known BSD veterans from the 1970’s, I listened how they dealt with surveillance. One file system hacker with decades of experience mentioned how he always changed his MAC address when using public wireless.</p>
<p>But there’s also a sense that Tor is too easily broken, such as with timing attacks from a global passive adversary. Or that if enough Tor relays are run by an adversary to anonymity, the network is useless. All are valid points and certainly need further attention. The heavy brains at the bar that night could infuse some assistance.</p>
<h3 id="20160223">20160223</h3>
<p><a id="tb55snaps1"><strong>TB 5.5 and More New Snapshots</strong></a> by gman999</p>
<p>Yesterday the OpenBSD snapshots updated to #1881 for amd64 and #1609 for i386. TB is working fine on both.</p>
<p>Meanwhile, the TB packages were updated. First we implemented a meta TB package, as per landry@’s comments. Note that the start-tor-browser script was also deprecated recently. All the sloppy setup gook was replaced by neater Firefox hacks.</p>
<p>Installing TB from the mirror is simple:</p>
<pre><code>$ doas env PKG_PATH=http://mirrors.nycbug.org/pub/snapshots/packages/amd64/ pkg_add tbb
</code></pre>
<p>For i386 installs, replace /amd64/ with /i386/.</p>
<p><strong>Be aware that that we are still tinkering with TB 5.5 which has some significant vulnerabilities that could disclose a user’s identity. TB 5.5.2 is in the pipeline.</strong></p>
<p>A question for TB testers out there: does a Tor Browser icon appear on the desktop after TB installs?</p>
<p>According to the general standards on window manager desktops, it should as the installer places /usr/local/share/applications/tor-browser.desktop into ~/.local/share/applications. However, on XFCE it doesn’t appear, and the file needs to be placed in ~/Desktop. How about KDE and GNOME users out there? Let us know.</p>
<p>We imagine that most users following -current are probably running cwm.</p>
<h3 id="20160221">20160221</h3>
<p><a id="tb55snaps"><strong>TB 5.5 and New Snapshots</strong></a> by gman999</p>
<p>Just a short note: Tor Browser for OpenBSD 5.5 is still working with the most recent OpenBSD snapshots (#1880 on amd64 and #1608 on i386).</p>
<p>We always use the most recent snapshots on our boxes, and usually update the TB packages when TB needs updating due to relevant snapshot changes. Since our build process significantly simplified with TB 5.5, primarily due to <a href="https://marc.info/?l=openbsd-ports&m=145581927415588&w=2/">landry@’s input</a>, updates to both amd64 and i386 builds became relatively painless.</p>
<p>And it should only get better in the near-future releases.</p>
<h3 id="20160216">20160216</h3>
<p><a id="next-phase"><strong>Onto the Next Phase</strong></a> by gman999</p>
<p>The progress we’ve made over the past five days was exhausting, yet exciting.</p>
<p>Some very significant steps were made with Tor Browser. A revised 5.5 release does not contain the start-tor-browser script any longer; all the necessary setup steps are now done with Javascript, including the profile setup. The Firefox add-ons are now dumped into the profile as files, such as [email protected], instead of being extracted into directories. Additionally, we are now building an i386 version of TB.</p>
<p>We are aware that <a href="https://blog.torproject.org/blog/tor-browser-552-released/">TB 5.5.2</a> was released by the Tor Project this past Friday, a mere hour after we announced our 5.5 release. TB 5.5.2 includes some important security changes coming from the Mozilla upstream, although much can be mitigated by moving the security slider to high. And <a href="https://blog.torproject.org/blog/tor-browser-551-released/">TB 5.5.1</a> was also released before our TB 5.5, but the changes were significant. Nevertheless, the last five days of constant hacking and testing on TB makes future releases less painful and more smooth.</p>
<p>Finally, for those doing TB testing, we have a brief guide to what to test in a <a href="testing-tb.html">Testing Tor Browser</a> piece. The past week has already changed some of the steps, and we look to expand and formalize this document so it becomes a useful tool.</p>
<p>It’s almost a year since our first commits to GitHub, and it’s been a long and sometimes painful learning experience, but we think we’re now in a great spot.</p>
<h3 id="20160205">20160205</h3>
<p><a id="tb-55-tagged"><strong>Tor Browser Ports for 5.5 Tagged</strong></a> by attila</p>
<p>I just merged 5.5 onto master and <a href="https://github.com/torbsd/openbsd-ports/releases/tag/tbb-5.5-sans-pt/">tagged it</a>. This release was much easier after the work on 5.0.6, which has us using <a href="http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/www/mozilla/mozilla.port.mk?rev=1.84&content-type=text/plain">mozilla.port.mk</a> instead of a bunch of cut-and-paste adapted from same. This makes things a lot easier moving forward. So far 5.5 on amd64 is looking good.</p>
<p><a id="tb-releases"><strong>Tor Browser Releases</strong></a> by gman999</p>
<p>It’s been a while since our last Tor Browser releases, but it’s not because we haven’t been busy. Smaller projects like <a href="dirty-stats.html">Quick and Dirty Statistics</a> and <a href="porting-pets.html">Porting PETs</a> have continued to progress, and other stuff that attila can elaborate on in a future blog post.</p>
<p>While worked dragged on with the 5.0.6 Tor Browser release, we managed to not only finish that <a href="http://mirrors.nycbug.org/pub/snapshots/packages/amd64/archive/tb-5.0.6.tgz">release</a>, but also finish up the <a href="http://mirrors.nycbug.org/pub/snapshots/packages/amd64/README-55.txt">5.5 release</a>. That puts us parallel with the current Tor Project release.</p>
<p>We are now archiving previous versions of TB as tgz file in an <a href="http://mirrors.nycbug.org/pub/snapshots/packages/amd64/archive/">an archive directory</a>. Version 5.0.6, which barely saw the light of day, is there.</p>
<p>We are excited by the releases, and look forward to feedback from the testers out there.</p>
<p>One quick note about Tor Browser 5.5 on OpenBSD 5.8 stable. We have repeated ad nauseum, but it’s worth reiterating again: OpenBSD development happens on -current, a.k.a., snapshots, which ultimately turn into the next stable release every six months.</p>
<p>Developing Tor Browser for OpenBSD stable means dealing with multiple levels of differences between stable and current, from the package versions to libraries in the base operating system. In *BSD land, userland applications and the base OS are meant to play nice together by default.</p>
<p>In the case of trying to run TB 5.5 on OpenBSD 5.8 stable, there are two package incongruities. First, 5.8-stable’s Tor version is 0.2.6.10p1, while the current version is 0.2.7.6. Second, the nspr stable version is 4.10.8, while the current version is 4.11. Both current versions of the packages rely on operating system changes not present in stable. There is a ports freeze approaching for the May 1 OpenBSD 5.9 stable release, and we may use that as an opportunity to produce a stable version of the Tor Browser. Stay tuned.</p>
<h3 id="20160118">20160118</h3>
<p><a id="torinabox"><strong>Tor-in-a-Box</strong></a> by gman999</p>
<p>If someone reasonably technical bumps into Tor for the first time, eight or nine seconds later, they arrive at the concept of some type of Tor device that automagically routes all local network traffic through the Tor network.</p>
<p>Great idea. The fact that so many imagine such a concept certainly means something.</p>
<p>All too often, unfortunately, the implementation is wrong. Dead wrong.</p>
<p>In the early 1990’s, a desktop’s traffic to the public internet was simple. There might be some HTTP from a web browser, a dash of UDP for DNS lookups and maybe some POPing to a remote email server. All was relatively quiet.</p>
<p>Over the past two decades, the wall between the internet and the desktops evaporated. Why is Windows 10 a free upgrade? Likely because a “free” operating system is well-compensated by full control of the desktop environment. And that means a tcpdump(8) from 1994 bears no resemblance to the ugly spew of 2015.</p>
<p>After those initial eight or nine seconds, going back to the basics of design should be the next reaction. Stop trying to make tools that do everything half-way. Too often an all-in-one device that tries to solve multiple problems displays contradictions between those functions. Thus, the core Unix principle that is considered dated by many, yet justifies itself with each new “wonder box” incarnation: one tool for one function.</p>
<p>That is not an argument against innovation, products or progress on any level. The point is the moment an attempt is made to cast a wide net into a complex sea, the net is shredded. The net’s target is not a school of sardines, but sardines, sharks, with rusted earth-moving equipment, yellow school buses and maybe a piece of space hardware or two.</p>
<p>More on this theme later, but the resilience of the classic Unix themes rises from the grave daily in an age of all-in-one products or services that tries to do everything, but succeeds at doing some things poorly and others dead-wrong.</p>
<h3 id="20160102">20160102</h3>
<p><a id="still-here"><strong>Still Plugging Away</strong></a> by gman999</p>
<p>We are still moving along.</p>
<p>Attila began working on the next Tor Browser release yesterday.</p>
<p><a href="dirty-stats.html">Dirty Statistics</a> are still being updated and tweaked. More reports are in the pipeline.</p>
<p>Some inferences from the Dirty Statistics reports:</p>
<ul>
<li><p>‘Bandwidth Ranking by Country Code’ shows a disturbing concentration of public Tor bandwidth. The recent chatter in France about banning Tor would have a disastrous effect on available bandwidth, with a quarter of Tor bandwidth being from there. Two other countries, Germany and the Netherlands, also provide double-digits of Tor bandwidth. Lack of diversity is a critical Achilles’ Heel.</p></li>
<li><p>‘Bandwidth Ranking by Operating System Platform’ continues to illustrate our main motivation, over 93% of Tor bandwidth is running on one Linux distro or another. Interestingly, FreeBSD is a strong second at over 5.6% of public bandwidth, with the next contender being OpenBSD at under .5%. Those BSD numbers are fascinating since in terms of quantity of relays, Windows far exceed the BSDs.</p></li>
<li><p>‘Exit Relays by Country Code’ shows that even though the US provides under 10% of public Tor bandwidth, it accounts for almost 18% of exit relays with Germany being distantly in second place with under 12% of exit relays. France, despite dominating in public bandwidth, only accounts for less than 9% of exit relays.</p></li>
<li><p>‘Total Relay Count by Operating System’ illustrates the hard numbers of public Tor relays by operating system. Windows maintains second place, with FreeBSD and OpenBSD occupying third and fourth places. Besides displaying the Linux monoculture, it also illustrates that a lot of Windows users, most likely running relays with the Tor Browser client software, are contributing relays.</p></li>
<li><p>‘Relay Count by Country Code’ shows the disturbing concentration of public relays with three countries, Germany, the US and France, having double-digits in relays. In terms of distribution, having as many countries as possible get up to having 1% of relays would be ideal, but not by decreasing the number of public relays in the top entries.</p></li>
<li><p>‘Countries without Public Tor Relays’ generally hovers between the high–70’s to the mid–80’s in numbers. Of course, in a lot of those countries it’s dangerous or just cost-prohibitive to run relays, yet it is likely that Tor isn’t well-known enough in some of them. If you are in one of those countries, drop us a note on why running a public Tor relay is difficult. If you know someone in one of those countries, ask them yourself and let us know.</p></li>
</ul>
<p>Remarkably, Tor Browser 5.03 is still functional on OpenBSD/amd64 with the #1783 snapshot from December 27th. Snapshots frequently take hard twists and turns, as is to be expected with the development branch of any operating system, so this is something of a surprise. The early releases of <strong>TDP’s</strong> 5.03 faced some hiccups with various changes, but we are trouble-free since.</p>
<p>One thing to note is that the number of public *BSD Tor relays, not including BitRig, remains consistently above 5% of total relays. While we can’t necessarily attribute to <strong>TDP</strong>, we like to think the noise we make helped a little bit.</p>
<p>Stay tuned. We are still very active, even when we are publicly quiet.</p>
<h3 id="20151216">20151216</h3>
<p><a id="notes-from-the-front"><strong>Notes From The Front</strong></a> by attila</p>
<p>First: hats off to gman999 for his incessant efforts in getting the content of this site in better shape. I especially applaud this low-tech/no-tech blog layout in MultiMarkdown.</p>
<p>I have been noticeably lacking, but not totally idle. I’ve had to take some paying work, which has slowed me down on open source, but my path forward is fairly clear. My main task is to rework the makefiles (mainly the stuff in Makefile.inc) that comprise the <a href="https://github.com/torbsd/openbsd-ports/">OpenBSD ports</a> for TBB so that they dovetail with and use as much as possible of the Mozillan infrastructure already in the OpenBSD ports tree, much of it due to <code>landry@</code>, who has already helped me a couple of times. I should’ve done this from the beginning but my head wasn’t really on straight when I first started this. I’ve been reticent about touching anything that I didn’t write, choosing instead to adapt what others have done to get something working. Although this was perhaps effective in the short term if we want this in the tree it has to be consonant with it… in short: if you’re serious about contributing to OpenBSD then pick up a shovel and start digging, but politely. I’m sure I can do that so I just have to get to it.</p>
<p>I hope to have a first cut at a rework of the ports, still based on 5.0.3, sometime next week… I don’t really celebrate any holidays so I’m hoping to get a lot done while the rest of the world sleeps it off. Once the makefiles are closer to right I’ll work on an update to 5.0.5 (or whatever is current on the 5.0.x branch). I’m afraid I might miss the next ports lock window because I’ve taken too long, but oh, well… <em>que sera sera</em>.</p>
<p><a id="pp-announce"><strong>Announcing Porting PETs</strong></a> by gman999</p>
<p>One of the small projects we have spent some time on recently is <a href="porting-pets.html">Porting PETs</a>. This is an attempt to list the various privacy-enhancing applications and their statuses in the BSD ports.</p>
<p>Most of these ports arose as non-commercial, open source reactions to mainstream applications and services. Some are ported to one BSD or another, others are not.</p>
<p>The list is not exhaustive, but it was certainly exhaustive to create. Updates will happen manually, so <a href="https://github.com/torbsd/torbsd.github.io/issues/">diffs</a> are appreciated.</p>
<p>Porting third-party applications is a frequent gateway for BSD users to become developers, this list will be circulated in the relevant BSD channels.</p>
<h3 id="20151202">20151202</h3>
<p><a id="2016-events"><strong>Thinking About 2016 </strong></a> by gman999</p>
<p>The BSDCan 2016 <a href="https://www.bsdcan.org/2016/papers.php">call for papers</a> was issued yesterday, and a <strong>TDP</strong>-related submission was made. BSDCan is likely the largest BSD gathering globally, and an excellent opportunity to speak to *BSD developers and users.</p>
<p>EuroBSDCon 2016 <a href="https://2016.eurobsdcon.org/">is tentatively slated for September 2016</a> in Belgrade, Serbia. It is another significant BSD event, attracting users and developers from Europe and beyond. At a glance, there are only two Tor relays in Serbia, and both are Linux. Beyond Serbia, there are few Tor relays in the Balkan states overall, making EuroBSDCon 2016 a great opportunity to extend not just BSD Tor relays, but <em>any</em> Tor relays.</p>
<p>No dates have been set for <a href="https://2016.asiabsdcon.org/">AsiaBSDCon</a>, but it’s usually in March. Japan is well-wired with inexpensive residential broadband, yet there are only around 50–60 relays in the country. Considering it’s a BSD-heavy nation, it’s shocking that there are only a handful of *BSD relays. Yet another green field of opportunity.</p>
<p>Stay tuned. Whether we can speak at any of these events will also depend on financial support for <strong>TDP</strong>.</p>
<h3 id="20151119">20151119</h3>
<p><a id="pets-ports"><strong>PETs Porting Targets</strong></a> by gman999</p>
<p>After the June 2013 Snowden disclosures, a rush towards developing applications to counter mainstream, closed-source services commenced. Many focuse on Debian Linux as a development platform, but aim at more widely used Windows, OSX, iOS and Android user-base. Beyond client applications, there are also network-based servers and services seeking to provide privacy and anonymity.</p>
<p>The term “PETs” refers to privacy-enhancing technologies, and in this case, we use it as a catch-all for these server and client solutions.</p>
<p>Some of these projects have been ported to one or more BSD. Others have not. On that note, we began a <a href="porting-pets.html">list of applications and their status as BSD ports in the main BSD operating systems</a>. We encourage feedback on this list, and also investigations into porting these applications. Some of well-worth reviewing and considering; others have ceased development or are broken beyond resurrection. Others just need some reworking towards sanity, as one will notice that ubiquitous build dependency <a href="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bash">bash</a>.</p>
<p>It’s a call for engagement to the *BSD community. Bring your sane, portable development approaches, your intransigent working and reworking of Makefiles, your austere mentality. This is an opportunity to improve applications whose user base might be someone whose life depends on it.</p>
<h3 id="20151112">20151112</h3>
<p><a id="br-case"><strong>The Case of Brazil Relays</strong></a> by gman999</p>