This week on BSDNow, we’ll be talking to Diane Bruce about using it for Ham Radio Enthusiasts, the RPi3. That plus all the latest news from the week & more, stick around for your place to B…SD!

RSS Feeds:

MP3 Feed | OGG Feed | iTunes Feed | Video Feed | HD Vid Feed | HD Torrent Feed

Become a supporter on Patreon:


– Show Notes: –


PC-BSD is now TrueOS

  • If you’ve been watching this show the past few months, I’ve been dropping little hints about the upcoming rename of PC-BSD -> TrueOS. We’ve made that more official finally, and are asking folks to test out the software before a wider announcement this fall.
  • For those wondering about the name change, it’s been something discussed over the past few years at different times. With us beginning to move more aggressively with changes for 11.0 (and eventually 12-CURRENT), the time seemed right to have a fresh start, using it as a spring-board to introduce all the changes in both software, and development / release model.
  • I’ll be discussing more about this shift in a talk at MeetBSD2016 (Another reason for you to go), but here’s some of the highlights.
  • No longer tied to specific FreeBSD point-releases, TrueOS will instead follow a rolling-release model based upon FreeBSD -CURRENT.
  • Special tooling and features (Such as boot-environments) make this a feasible option that we didn’t have as easily in the early days of PC-BSD.
  • In addition, TrueOS builds some things different from vanilla FreeBSD. Specifically Matt Macy’s DRM and Linux Compat work, LibreSSL directly in base, built from External Toolchain (No clang in base system package) and much more.
  • New tools have have replaced, and are in the process of replacing the legacy PC-BSD control panel as well, which allows remote operation, either via Qt GUI, or WebSockets / REST API’s.
  • I’ll be talking about more as things unfold, but for now please feel free to test and let us have feedback while we push towards a more stable release.

The Voicemail Scammers Never Got Past Our OpenBSD Greylisting

  • Peter Hansteen (That grumpy BSD guy) gives us an interesting look at how their OpenBSD grey-listing prevented spam from ever making it to their inbox.
  • Specifically it looks like it occurred during Aug 23rd and 24th, with a particularly nasty ransomware payload destined to play havoc with Windows systems.
  • Peter then walks us through their three-server mail setup, and how spamd is run in greylisting mode on each.
  • The results? Nothing short of perfection:

From those sources we can see that there were a total of 386 hosts that attempted delivery, to a total of 396 host and target email pairs (annotated here in a .csv file with geographic origin according to whois). The interesting part came when I started looking at the mail server logs to see how many had reached the content filtering or had even been passed on in the direction of users’ mailboxes. There were none. The number of messages purportedly from voicemail@ in any of the domains we handle that made it even to the content filtering stage was 0. Zero. Not a single one made it through even to content filtering.

  • Not bad at all! Looks like spam-trap addresses + grey-listing is the way to go for stopping this kind of foolishness. Checkout Peter’s blog post for more details, but perhaps this will encourage you to setup a similar-type system for your business.

FreeBSD on a tiny system; what’s missing

  • Adrian Chadd talks about some of the bits that are missing to make FreeBSD truly useful on small embedded devices
  • Some of this stuff can be done now, but requires more work than it should

The first is a lack of real service management. FreeBSD doesn’t have a service management daemon – the framework assumes that daemons implement their own background and monitoring. It would be much nicer if init or something similar to init could manage services and start/restart them where appropriate.

  • Of course, on a system with 32mb of memory, such a service manager would need to be very light weight

maybe I want to only start telnetd or dropbear/sshd whenever a connection comes in. But I’d also like to be able to add services for monitoring, such as dnsmasq and hostapd.

  • telnetd and sshd can be run from inetd, but often depend on special support from the daemon

The next is a lack of suitable syslog daemon. Yes, I’d like to be able to log some messages locally – even if it’s only a couple hundred kilobytes of messages. I’d also like to be able to push messages to a remote service. Unfortunately the FreeBSD syslog daemon doesn’t do log rotation or maximum log file sizes itself – it’s done by “newsyslog” which runs out of cron. This isn’t any good for real embedded systems with limited storage.

  • Syslog leaves much to be desired, especially in its configuration syntax, and filtering capabilities. Having it be able to detect with log files have grown beyond a reasonable size and fire off newsyslog would be very interesting

Then yes, there’s a lack of a cron service. It’d be nice to have that integrated into the service management framework so things could be easily added/removed. I may just use cron, but that means cron is also always running which adds memory footprint (~1.3 megabytes) for something that is almost never actually active. When you have 32MB of RAM, that’s quite a bit of wasted memory.

  • Systems have come back full circle, to where 32MB and 64MB are amounts of memory people expect to work with, while other people still want the system to perform well with 32 or 64 GB of memory
  • It will be interesting to see how this balancing act plays out, trying to make the same codebase useful for extremely small and extremely large systems at the same time, while also running it on your middle of the road laptop.

So I lost my OpenBSD FDE password

The other day I set up a new OpenBSD instance with a nice RAID array, encrypted with Full Disk Encryption. And promptly proceeded to forget part of the passphrase.

  • So they started a little project
  • Goal: “We need to extract enough info from the encrypted disk and rebuild enough of the decryption algorithm to be able to rapidly try many passphrases.”
  • The post walks through how they reverse engineered the encryption system from the source code and a hexdump of a small encrypted memory disk

Now that we know how to extract the data and how to try passphrases against it, it will be trivial to write a bruteforce tool to recover the part of passphrase I forgot.

  • So, rather than having to try every possible passphrase, they only had to try fuzzing around the known keyword that was their passphrase.

UPDATE: I found it! After fixing a bug or two in the brute force tool and almost losing hope, it found the right combination of forgotten word and (Italian) misspelling.

  • This work lead to the author recommending that OpenBSD consider strengthening the key derivation algorithm used in its FDE.
  • Rather than using a fixed number of rounds (8000 currently), do a small benchmark and determine how much work can be done in a reasonable amount of time
  • This is what FreeBSD’s GELI FDE does, targeting ‘over 2 million microseconds’ of work. On my desktop i5-3570 this results in 974842 rounds. The number will likely not be the same twice because of minor variations in how long it will take in microseconds.

Interview – Diane Bruce – / @Dianora_1

  • Ham Radio, RPi3 & more!

News Roundup

See Me (Michael W. Lucas) in 2016

  • Looking for a chance to interact with author Michael W Lucas in meat-space? (That sounds wrong)
  • If so, he has posted a list of the up-coming conferences he’ll be speaking at, starting with Ohio LinuxFest Oct 7-8, where he’ll be giving an introduction to ZFS talk.
  • Nov 8th, he’ll also be at MUG (Michigan User Group) giving a PAM talk.
  • Sadly, no MeetBSD for Michael this year [moment of silence], but if you are able to make it to one of the aforementioned gatherings, be sure to bring your books for autographs. We promise he doesn’t bite. Much.

It’s hard work printing nothing

It all starts with a bug report to LibreSSL that the openssl tool crashes when it tries to print NULL. This bug doesn’t manifest on OpenBSD because libc will convert NULL strings to ”(null)” when printing. However, this behavior is not required, and as observed, it’s not universal. When snprintf silently accepts NULL, that simply leads to propagating the error.

There’s an argument to be made that silly error messages are better than crashing browsers, but stacking layers of sand seems like a poor means of building robust software in the long term.
As soon as development for the next release of OpenBSD restarted, some developers began testing a patch that would remove this crutch from printf.

  • If you’d like to help with this work, see our call for volunteers from 2 weeks ago: opportunity to help: %s audit in mandoc
  • Of course, immediately things started to complain. The configure script for talloc does a number of checks (check out the additional interesting observations by TedU here)

The test checking that our snprintf function conforms to the C99 standard actually contains, at a minimum, 3 deviations from the standard. It should say “Checking for non-conformant vsnprintf”.

Of course, we’re dealing with NULL pointers, so all bets are off, but I wonder what people who expect printf NULL to work expect out of strlen? Does it return 0? Does it crash?

  • So, talloc decides that the system printf is no good, and it should use its own bundled implementation

After all the configure testing, eventually the build will fail, because somebody forgot to actually add the replacement object file to the Makefile.

If the replacement function has never been used, that’s hardly reassuring that it is actually better tested than the version we have in libc.

Revisiting W^X with OpenBSD 6.0

  • OpenBSD 6.0 includes enforcement of W^X in user-land
  • This prevents an application from being able to map a page of memory with both Write and Execute permissions (protecting mmap(2))
  • Once mapped a page of memory should not be able to have permissions escalated (protecting mprotect(2))
  • OpenBSD 6.0 enforces the strict W^X definition, and not the PaX/grsec “once write never execute” type of policy

OpenBSD imports a letsencrypt client into the base system

  • We’ve mentioned letskencrypt before (A native C version of the letsencrypt client, developed by Kristaps).
  • Looks like it’s undergoing a name-change to “acme-client” and has made it’s way into OpenBSD’s base system!
  • This should ensure first-class support for management of Let’s Encrypt certificates, here’s hoping the portable version continues to thrive as well.
  • Congrats to Kristaps!

Beastie Bits


  • Send questions, comments, show ideas/topics, or stories you want mentioned on the show to

Question? Comments? Contact us here!