fox :: from/undeadly.org

BSDNow Episode 055: The Promised WLAN **

undeadly.org — 2014-09-19 10:55:02

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140919065109

Contributed by tbert on Fri Sep 19 06:44:38 2014 (GMT)
from the WLAN of milk and honey dept.

In this [episode](http://www.bsdnow.tv/episodes/2014_09_17-the_promised_wlan) of [BSDNow](http://www.bsdnow.tv/), Kris and Allan go over the week's BSD odds and ends, including mention of an interesting article about using a Linux rescue image to bootstrap a headless OpenBSD installation on remote machines. Headlining is an interview with the FreeBSD wireless stack maintainer, Adrian Chadd.

**[** [Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0055-432p.mp4) **|** [HD Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0055.mp4) **|** [MP3 Audio](http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/jbmirror/bsd-0055.mp3) **|** [OGG Audio](http://www.podtrac.com/pts/redirect.ogg/traffic.libsyn.com/jbmirror/bsd-0055.ogg) **|** [Torrent](http://bitlove.org/jupiterbroadcasting/bsdnowhd) **]**

Heads Up: Sendmail Removed from Base **

undeadly.org — 2014-09-16 12:55:02

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140916084251

Contributed by tbert on Tue Sep 16 07:02:42 2014 (GMT)
from the day of the living tedu dept.

In the [first](http://marc.info/?l=openbsd-cvs&m=141081997917153&w=2) of several commits, Matthieu Herrb (matthieu@) has removed sendmail from the release:

>
>
> CVSROOT: /cvs
> Module name: src
> Changes by: matthieu@cvs.openbsd.org 2014/09/15 16:25:57
>
> Modified files:
> gnu/usr.sbin : Makefile
>
> Log message:
> Unlink sendmail from the build. ok krw@ ajacoutot@
>

Users of OpenSMTPd can rejoice in having no work to do; others will have to install sendmail from packages.

GSoC 2014: Systemd replacement utilities (systembsd) **

undeadly.org — 2014-09-15 10:55:02

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140915064856

Contributed by [jj](http://www.inet6.se) on Fri Sep 12 07:06:45 2014 (GMT)
from the all your system is belong to us dept.

Ian Kremlin wrote in with this report on the GSoC he was involved in:

> This summer I, along with my mentors Landry Breuil and Antoine Jacoutot, worked on systemd shim-like replacements for four D-Bus daemons systemd provides, namely hostnamed, localed, timedated, and logind.

> Now let's clear some things up:

The purpose of this GSoC was (is) not to port systemd to *BSD in way, shape or form. Nor is it to replace the existing init(8), boot(8) or rc(8) programs. Systemd and *BSD differ fundamentally in terms of philosophy and development practices and special care was taken to only wrap the functionality of the aforementioned daemons and not create any new systemd-like functionality.

You can find the repository [here](https://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git;a=summary)
.
Upon completion and review, my code will most likely end up as a port to be installed along with the GNOME suite, or any other ports that depend on systemd (upstream) and need a compatibility layer to work properly on non-systemd operating systems. It goes without saying that none of my code will end up (or belongs) in the base system.

Hostnamed (formally systemd-hostnamed) is a D-Bus daemon that handles setting system hostnames (in our case, that's through the sethostname(3) call and the /etc/myname file) as well as provides system information mostly found through uname(1). Hostnamed also handles determining the system's chassis type, whether it be a server, desktop, laptop, handheld, VM, etc. and providing a proper icon from that information.

Localed and timedated are more straightforward daemons that allow setting system/xorg locales/keymaps and times/dates/timezones/NTP settings respectively.

Logind (currently unfinished) is a rather large daemon that encompasses many aspects of a user's login session. This includes everything from getting current users and any PIDs under them, as well as system suspension and shutdown/reboot preparation. We are still researching a proper way to implement this as native systemd uses PAM for authentication, something we do not want to do on OpenBSD.

Overall, it was an excellent summer. I took this project because I was fed up with what systemd was doing to my then-main computer running Arch Linux. I figured this would be a great way to make the move to OpenBSD and I couldn't be happier. I dearly hope you'll be seeing more of me in the future ;)

As a fun aside, me and some friends all turned 21 around the beginning of August (the tail end of GSoC) and decided to pool our pennies together to take a road trip together to Colorado. This led to some [interesting circumstances](https://kremlin.cc/9workethic.jpg). All I can say is that there is stable LTE service between Texas and Colorado that work at speed in excess of eighty-eight miles per hour and that one can do a lot with a macbook charger, a working alternator, a bit of cabling and entry-level electrical engineering knowledge.

Thanks for the report, and hope you didn't get too tainted with systemd.

BSDNow Episode 054: Luminary Environment **

undeadly.org — 2014-09-12 15:55:02

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140912111017

Contributed by tbert on Fri Sep 12 10:58:07 2014 (GMT)
from the better than incendiary dept.

In [this week's episode](http://www.bsdnow.tv/episodes/2014_09_10-luminary_environment), the [BSDNow](http://www.bsdnow.tv/) crew discusses the week's dealings in the world of BSD, with a decent focus on OpenBSD's systemd-shim GSoC project, OpenBSD's versioning schemes, and the OpenBSD port of portscout.

**[** [Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0054-432p.mp4) **|** [HD Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0054.mp4) **|** [MP3 Audio](http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/jnite/bsd-0054.mp3) **|** [OGG Audio](http://www.podtrac.com/pts/redirect.ogg/traffic.libsyn.com/jnite/bsd-0054.ogg) **|** [Torrent](http://bitlove.org/jupiterbroadcasting/bsdnowhd) **]**

Energy-efficient bcrypt cracking **

undeadly.org — 2014-09-12 11:55:01

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140912072316

Contributed by [jj](http://www.inet6.se) on Fri Sep 12 07:22:07 2014 (GMT)
from the kiss-blowfish-get-free-lip-piercing dept.

Solar Designer posted on the openwall announce list about the recent status on using FPGAs to crack bcrypt passwords.

> From: Solar Designer
Subject: Energy-efficient bcrypt cracking (Passwords^14, Skytalks, WOOT '14 slides and paper); crypt_blowfish 1.3

> Katja Malvoni has given 3 talks at conferences in the US earlier in August at PasswordsCon Las Vegas, Skytalks, and USENIX WOOT '14. We've also submitted an academic paper to WOOT.
All of these reflect progress we made at the "Energy-efficient bcrypt cracking" project since last year. Here are the new slides, download links, and YouTube video link:

The talk video includes a live demo of bcrypt hash cracking with modified John the Ripper on several of the energy-efficient boards. For reference, here's last year's announcement:

New since last year are much improved results for FPGAs, in particular for Xilinx Zynq 7020 and 7045. The latter achieves what's probably the highest bcrypt cracking speed per chip that has been actually demonstrated so far (for any kind of chip, including CPUs and GPUs), as well as the highest energy-efficiency, although indeed even higher speeds are currently possible (e.g. on FPGAs that are bigger yet).

In particular, for bcrypt cost 5 the speed on Zynq 7045 is 20538 c/s, and for cost 12 it is 226 c/s (higher efficiency than for cost 5). Similarly expensive Xeon E5-2670 is 2.4x to 3.3x slower than Zynq 7045 on this test, yet consumes ~20x more power; GPUs are way behind.

The inexpensive Zynq 7020 now achieves speeds that are on par with CPUs and GPUs, but at much greater energy efficiency. We're going to continue the project, targeting other FPGAs and multi-FPGA boards.

We continue to recommend use of bcrypt for now. The crypt cracking speedups and energy efficiency improvements achieved so far are very important, but are not fatal to its continued use for a while longer. This is a short-term recommendation.

2\. I released crypt_blowfish 1.3 back in July:

Version 1.3 adds support for the $2b$ prefix introduced in OpenBSD 5.5+, which behaves exactly the same as crypt_blowfish's $2y$ did and still does. This way, full compatibility with OpenBSD's bcrypt is achieved at the new $2b$ prefix. crypt_blowfish 1.3 is already included in Owl-current builds (including the ISO images) made in July.

I'd like to thank the OpenBSD project for providing this avenue for us to achieve full compatibility between the implementations despite of the mistakes made previously. To be more confident there is indeed full compatibility, I wrote and ran a test suite cross-testing the two implementations, including on weird and invalid inputs. For the curious, it can now be found as bcrypt-tester-1.0.tar.gz under:

although there should be no need to run it (again).
As usual, any feedback is welcome.

2Q Buffer Cache in OpenBSD **

undeadly.org — 2014-09-08 15:55:02

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140908113732

Contributed by tbert on Fri Sep 5 04:39:36 2014 (GMT)
from the i will always 2q dept.

Ted Unangst (tedu@) wrote a [blog post]() about his replacement of the simple LRU buffer cache algorithm with a 2Q-ish one:

> Since the dawn of time, the OpenBSD buffer cache replacement algorithm has been LRU. It’s not always ideal, but it often comes close enough and it’s simple enough to implement that it’s remained the tried and true classic for a long time. [I just changed the algorithm](http://marc.info/?l=openbsd-cvs&m=140951935412282&w=2) to one modelled somewhat after the [2Q algorithm by Johnson and Shasha](http://dl.acm.org/citation.cfm?id=672996). ([PDF](http://www.vldb.org/conf/1994/P439.PDF))

> **LRU**
>
> LRU is simple enough it doesn’t require much explanation. Keep a list of all buffers. Whenever you use one, put it on the front of the list. Whenever you need a new (recycled) buffer, take it from the end of the list. Those are the oldest, least recently used buffers. In high level terms, the current working set is at the front of the list and the previous working set is fading away off the end. It’s responsive to changes in the working set, very quickly replacing old unused buffers with the latest. In other words, it has a short history; it’s not “sticky”.
>
> This strength is also a weakness. LRU is particularly vulnerable to erroneous replacement during scanning; i.e. it’s not scan resistant. After weeks of uptime, your system is running great and everything you need from disk is in cache. Then you download a few Linux ISOs to see what the fuss is about. Suddenly, even simple commands like ps need to be read in from disk. Seek, seek, thrash, seek, grind. Should have bought an SSD. What happened? Those ISOs were so large that they pushed everything out of the disk cache. (The obvious optimization, to only cache reads and not writes, doesn’t help here because you’re equally obviously going to run sha256 and checksum those ISOs, leading to the same result.)
>
> This problem has been known for long time, but thanks again to the short history rarely causes permanent damage. And caches with history are often harder to implement due to the additional state tracking required, and they can even suffer from too much history. After weeks of uptime, the exec pages for a command like ls are going to be pegged in memory. What if you catch color fever and switch to using colorls? Sorry, those plain ls buffers aren’t going to be recycled. Eldritch buffers are eldritch.
>
> At the hackathon I decided to look into the problem of scan resistance a little more. A hundred CS papers have proposed better algorithms; I settled on 2Q. Or at least something inspired by it, as the final result is more or less different depending on your squint.
>
> **2Q**
>
> Reading the paper is the best way to understand exactly what they’re doing. I’ll just summarize the highlights that I thought were applicable. The main insight is that in addition to LRU’s current working set and previous working set, there’s a third working set: the long term working set. We start by assuming that a buffer is in the current working set, then quickly move it to the previous working set (or sets; they keep quite a long history). If we need that buffer again, that’s a hint that it’s really in the long term working set. To conserve memory, 2Q doesn’t actually keep the previous working set data cached in memory. Only the addresses are retained which is enough to determine when a cache miss is new data vs previously seen data.
>
> The 2Q algorithm is scan resistant. The memory reserved for current working set is kept quite small; most of it is dedicated to long term. This keeps transient data out. At the same time, the long term list is itself managed as LRU, so it’s responsive to changes. All good.
>
> **bufcache**
>
> Earlier, I refactored the buffer cache interface so that the line between the buf cache and buf midlayer was better defined. The bufcache family of functions does all the work now, allowing us to make algorithm changes in one place. At the time I was experimenting with a different LFU style algorithm, but it was sufficient to prove the interface would work. 2Q represents the first real world test.
>
> **not quite 2Q**
>
> The code in OpenBSD resembles 2Q, but contains some significant differences as well. In large part, this is because I had another priority: ease of implementation. 2Q keeps a history of past buffer addresses to know when a miss was previously in the cache; bufcache doesn’t provide that capability in its current form. There were some other obstacles as well. The result is that I tried to implement the simplest variation I could, while also considering future plans. There are comments in the code as well, but I repeat the explanation here.
>
> We retain the key three working set distinction. In the OpenBSD code, they are named hot, cold, and warm, and each is an LRU queue. New buffers start hot. They stay that way as long as they remain on the hot queue. Eventually, a buffer will slip from the end of the hot queue onto the front of the cold queue. (We preserve the data, not just the address.) When a new buffer is needed, we recycle one from the tail of the cold queue. The oldest and coldest. If, on the other hand, we have a cache hit on a cold buffer, it turns into a warm buffer and goes to the front of the warm queue. Then as the warm queue lengthens, buffers start slipping from the end onto the cold queue. Both the hot and warm queues are capped at one third of memory each to ensure balance.
>
> Scan resistance is achieved by means of the warm queue. Transient data will pass from hot queue to cold queue and be recycled. Responsiveness is maintained by making the warm queue LRU so that expired long term set buffers fade away.
>
> **results**
>
> In some ad hoc md5 some large files testing, I confirmed the contents of the bin directory remained in cache when they otherwise would not. Other interactive responsiveness testing went well, too. The primary goal had been to achieve some degree of scan resistance: mission accomplished.
>
> The 2Q paper results are based on replaying traces in a simulator, which is the kind of thing you have to do to get papers published, but which also means they didn’t have to integrate with an existing system which anybody used. I’m not trying to publish a paper, so my results are lacking, but I did have to weld this thing into the existing kernel’s buf layer, which is why it didn’t come out quite the same. I’m all about rigor, as long somebody else does the work.
>
> **future**
>
> The numbers and ratios for the various queue lengths may need tuning. The current design and numbers were selected in part to minimize regressions, not maximize performance. One hopeful change is to finally add support for highmem on amd64 systems. The same algorithm that works to balance between hot and warm queues will work to balance between low and high mem. Now at least we have a launch point for future efforts to build upon.
>
> A name? TU-Q?

BSDNow Episode 053: It's HAMMER Time **

undeadly.org — 2014-09-05 12:55:02

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140905084104

Contributed by [jj](http://www.inet6.se) on Fri Sep 5 08:31:57 2014 (GMT)
from the when will bsdnow serve episodes using http(8) dept.

On the 1 year anniversary [episode](http://www.bsdnow.tv/episodes/2014_09_03-its_hammer_time) of [BSDNow](http://www.bsdnow.tv/), Kris and Allan interview OpenBSD's Reyk Flöter (reyk@) about the new [httpd(8)](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/httpd.8), in addition to the week's odds and ends in the world of BSD.

**[** [Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0053-432p.mp4) **|** [HD Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0053.mp4) **|** [MP3 Audio](http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/jnite/bsd-0053.mp3) **|** [OGG Audio](http://www.podtrac.com/pts/redirect.ogg/traffic.libsyn.com/jnite/bsd-0053.ogg) **|** [Torrent](http://bitlove.org/jupiterbroadcasting/bsdnowhd) **]**

Persist tmux environment across system restarts **

undeadly.org — 2014-09-04 21:55:02

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140904174329

Contributed by [jj](http://www.inet6.se) on Thu Sep 4 08:00:26 2014 (GMT)
from the frankensteins terminal dept.

Nagy Gábor writes in with a tip:
Tmux is great, except when you have to restart the computer. You lose all the running programs, working directories, pane layouts etc. There are helpful management tools out there, but they require initial configuration and continuous updates as your workflow evolves or you start new projects.

[tmux-resurrect](https://github.com/tmux-plugins/tmux-resurrect) saves all the little details from your tmux environment so it can be completely restored after a system restart (or when you feel like it).
No configuration is required, you should feel like you never quit tmux. It even (optionally) restores vim sessions!
Here's what's been taken care of:

* all sessions, windows, panes and their order
* current working directory for each pane
* exact pane layouts within windows
* active and alternative session
* active and alternative window for each session
* windows with focus
* active pane for each window
* programs running within a pane!
* restoring vim sessions (optional).

BSDNow Episode 052: Reverse Takeover **

undeadly.org — 2014-08-29 18:55:05

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140829144158

Contributed by tbert on Fri Aug 29 10:31:00 2014 (GMT)
from the pecan PIE dept.

[This week]() on [BSDNow](http://www.bsdnow.tv/), in addition to the week's BSD-flavored odds and ends, Kris and Allan headline with an interview with Shawn Webb about [ASLR](http://en.wikipedia.org/wiki/Address_space_layout_randomization) and [PIE](http://en.wikipedia.org/wiki/Position-independent_code) on FreeBSD.

**[** [Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0052-432p.mp4) **|** [HD Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0052.mp4) **|** [MP3 Audio](http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/jnite/bsd-0052.mp3) **|** [OGG Audio](http://www.podtrac.com/pts/redirect.ogg/traffic.libsyn.com/jnite/bsd-0052.ogg) **|** [Torrent](http://bitlove.org/jupiterbroadcasting/bsdnowhd) **]**

Heads Up: Nginx Removed From Base **

undeadly.org — 2014-08-27 11:55:07

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140827065755

Contributed by [jj](http://www.inet6.se) on Wed Aug 27 06:41:46 2014 (GMT)
from the dawn of the living tedu dept.

With [this](http://marc.info/?l=openbsd-cvs&m=140908174910713&w=2) commit, Robert Nagy (robert@) removed [nginx(8)](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-5.5/man8/nginx.8) from base:

> Log message:
remove nginx from the base system in favor of OpenBSD's own httpd(8)

Nginx fans will of course find it in [ports](http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/nginx/), and people that just want to run a simple web server should read up on the new [httpd(8)](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/httpd.8).

Heads Up: BIND Disabled in Base **

undeadly.org — 2014-08-23 10:55:04

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140823064850

Contributed by tbert on Sat Aug 23 06:39:48 2014 (GMT)
from the night of the living tedu dept.

After many years of being the default DNS server, BIND has been [disabled](http://marc.info/?l=openbsd-cvs&m=140873518514033&w=2) in OpenBSD base:

>
>
> CVSROOT: /cvs
> Module name: src
> Changes by: deraadt@cvs.openbsd.org 2014/08/22 13:19:25
>
> Modified files:
> etc : Makefile changelist group master.passwd rc
> rc.conf
> etc/mail : aliases
> etc/mtree : 4.4BSD.dist
> Removed files:
> etc/bind : db.localhost db.loopback db.loopback6.arpa
> named-dual.conf named-simple.conf root.hint
> etc/rc.d : named
> etc/systrace : usr_sbin_named
>
> Log message:
> disable use of bind in base; in the base use nsd/unbound instead.
> a proper & complete bind port will show up.
> discussed with many for years
>

In [another commit](http://marc.info/?l=openbsd-cvs&m=140873573614282&w=2), the build instructions have been pared back to provide the minimum command line utilities users are used to finding:

>
>
> CVSROOT: /cvs
> Module name: src
> Changes by: brad@cvs.openbsd.org 2014/08/22 13:28:25
>
> Modified files:
> usr.sbin/bind : Makefile.bsd-wrapper Makefile.in configure
> configure.in
> usr.sbin/bind/bin: Makefile.in
>
> Log message:
> Strip the BIND code down to just building and installing dig, host and nslookup.
>

Users who wish to continue using BIND will have to wait for the port to show up; those wanting to use base to serve their needs will now (finally) need to transition to unbound.

BSDNow Episode 051: Engineering Nginx **

undeadly.org — 2014-08-22 18:55:06

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140822142648

Contributed by tbert on Fri Aug 22 13:48:24 2014 (GMT)
from the missed the ngineering pun dept.

This week the [hosts](http://www.bsdnow.tv/) set up SSL on nginx and an interview about the FreeBSD community and utilisation in the commercial server space, along with the week's BSD-world odds and ends.

**[** [Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0051-432p.mp4) **|** [HD Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0051.mp4) **|** [MP3 Audio](http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/jnite/bsd-0051.mp3) **|** [OGG Audio](http://www.podtrac.com/pts/redirect.ogg/traffic.libsyn.com/jnite/bsd-0051.ogg) **|** [Torrent](http://bitlove.org/jupiterbroadcasting/bsdnowhd) **]**

syslogd(8) Now IPv6-Capable **

undeadly.org — 2014-08-22 17:55:06

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140822133925

Contributed by tbert on Fri Aug 22 09:14:22 2014 (GMT)
from the they're altogether ooky, the address family dept.

With the [penultimate](http://marc.info/?l=openbsd-cvs&m=140864046216023&w=2) in a series of commits, Alexander Bluhm (bluhm@) has added IPv6 support to [syslogd(8)](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/syslogd.8?query=syslogd):

>
>
> CVSROOT: /cvs
> Module name: src
> Changes by: bluhm@cvs.openbsd.org 2014/08/21 11:00:34
>
> Modified files:
> usr.sbin/syslogd: privsep.c syslogd.c
>
> Log message:
> Send and receive UDP syslog packets on the IPv6 socket.
> OK henning@
>

Google offers 5 EuroBSDCon 2014 travel grants for female computer scientists **

undeadly.org — 2014-08-21 10:55:05

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140821065200

Contributed by [jj](http://bsdly.blogspot.com/) on Wed Aug 20 10:09:05 2014 (GMT)
from the come fly with me dept.

Via the EuroBSDCon 2014 organizers comes the news that [Google will be sponsoring](http://2014.eurobsdcon.org/sponsors/google-emea-women-in-tech-conference-and-travel-grants-for-female-computer-scientists/) 5 female computer scientists to attend the EuroBSDCon 2014 conference. The announcement follows:

> **Google EMEA Women in Tech Conference and Travel grants for female computer scientists**
>
> As part of Google's ongoing commitment to encourage women to excel in computing and technology, Google is pleased to offer Women in Tech Travel and Conference Grants to attend the EuroBSDcon 2014 conference.
>
> 5 grants, are offered which include:
>
> * Free registration for the conference
> * Up to 1000 EUR towards travel costs (to be paid after the conference)

> To be eligible for a grant, the candidate must:
>
> * Be a woman working in or studying Computer Science, Computer Engineering, or technical field related to the conference subject
> * Have a strong academic background
> * Demonstrated leadership in the workplace or in school
> * Attend the core day(s) of the main conference
>
> **How To Apply**
>
> To apply, submit the form found on their website[1] by the 31 August 2014 deadline.
>
> To find out more about this Google program, please visit their website [2].
>
> [1] [ https://docs.google.com/spreadsheet/viewform?formkey=dHpHa1JJbTFSY2ZOTHFSUXEyUzNGY2c6MA](https://docs.google.com/spreadsheet/viewform?formkey=dHpHa1JJbTFSY2ZOTHFSUXEyUzNGY2c6MA)
>
> [2]
>
>>

Heads up: rcctl(8) the rc.conf.local management tool landing in base soon **

undeadly.org — 2014-08-20 13:55:04

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140820090351

Contributed by [pitrh](http://bsdly.blogspot.com/) on Tue Aug 19 17:34:45 2014 (GMT)
from the was that by by remote control dept.

Antoine Jacoutot (ajacoutot@) has just committed [committed](http://marc.info/?l=openbsd-cvs&m=140845736618486&w=2) a tool for managing [rc.conf.local(8)](), in order to make it simpler for automated management systems such as Puppet or Ansible to interface with the operating system configuration:

>
>
> CVSROOT: /cvs
> Module name: src
> Changes by: ajacoutot@cvs.openbsd.org 2014/08/19 08:08:20
>
> Added files:
> usr.sbin/rcctl : Makefile rcctl.8 rcctl.sh
>
> Log message:
> Introduce rcctl(8), a simple utility for maintaining rc.conf.local(8).
>
> # rcctl
> usage: rcctl enable|disable|status|action [service [flags [...]]]
>
> Lots of man page improvement from the usual suspects (jmc@ and schwarze@)
> not hooked up yet but committing now so work can continue in-tree
> agreed by several
>

Early bird rates for EuroBSDCon 2014 have been extended **

undeadly.org — 2014-08-18 19:55:05

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140818150726

Contributed by [phessler](http://www.openbsdfoundation.org/donations.html) on Mon Aug 18 15:07:07 2014 (GMT)
from the birds-of-a-feather dept.

As seen on [Twitter](https://twitter.com/Keltounet/status/501330332269150208), the Early Bird rates have been extended until August 25th. As you can tell, there are quite a few [delightful talks and tutorials](http://2014.eurobsdcon.org/talks-and-schedule/) scheduled. Some of your trustworthy Undeadly Editors have already registered, come join us!

[EuroBSDCon 2014 Registration](http://2014.eurobsdcon.org/registration/)

BSDNow Episode 050: VPN, My Dear Watson **

undeadly.org — 2014-08-15 13:55:05

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140815090815

Contributed by tbert on Fri Aug 15 09:08:09 2014 (GMT)
from the connective reasoning dept.

This week the fellas dish interview Robert Watson of FreeBSD, and present a tutorial for getting [OpenVPN]() working, in addition to the weekly odds and ends of the BSD world.

**[** [Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0050-432p.mp4) **|** [HD Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0050.mp4) **|** [MP3 Audio](http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/jbmirror/bsd-0050.mp3) **|** [OGG Audio](http://www.podtrac.com/pts/redirect.ogg/traffic.libsyn.com/jbmirror/bsd-0050.ogg) **|** [Torrent](http://bitlove.org/jupiterbroadcasting/bsdnowhd) **]**

mandoc 1.13.1 Released **

undeadly.org — 2014-08-13 09:55:04

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140813045834

Contributed by [pitrh](http://bsdly.blogspot.com/) on Sun Aug 10 21:38:55 2014 (GMT)
from the puff up your manuals dept.

Ingo Schwarze writes in with the news of a new and better mandoc release:

> after more than seven months of active development including two hackathons, i have just released mandoc = mdocml 1.13.1 on <>.

> This is a major feature release introducing the new [apropos(1)](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/apropos.1?query=apropos), [makewhatis(8)](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/makewhatis.8?query=makewhatis), and [man.cgi(8)](http://www.openbsd.org/cgi-bin/man.cgi) semantic search suite based on an SQLite3 database. In addition to that, it features an almost complete implementation of [roff(7)](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man7/roff.7?query=roff) numerical expressions, much improved warning and error handling and messages, and numerous minor new features and bugfixes in almost all areas. See the website for details, in particular <>.
>
> Even though this release is the first one in the 1.13 series, it is considered a mature and stable release ready for production. The codebase has been used in production in OpenBSD-stable for several months and is contained in the upcoming OpenBSD 5.6 release. Upgrading from 1.12.3 to 1.13.1 is recommended for all systems having working SQLite3 and [fts(3)](http://www.openbsd.org/cgi-bin/man.cgi?query=fts&apropos=0&sec=0&arch=default&manpath=OpenBSD-current) implementations. Upgrading is also recommended for all systems that do not want apropos(1), makewhatis(8), or man.cgi(8), no matter whether or not they have SQLite3 and fts(3). Only systems requiring apropos(1) and makewhatis(8) but lacking either SQLite3 or fts(3) should stay on 1.12.3 for now and switch to 1.12.4 and then to 1.13.2 when these become available. The 1.12.4 release is expected to happen within the next two weeks.
>
> Special thanks to Marc Espie and Jeremy Evans (OpenBSD) for help with various aspects of SQLite, to Sebastien Marie for a security audit of man.cgi(8), to Bob Beck (OpenBSD) for lots of feedback on the Web frontend, and to Kristaps Dzonsons (bsd.lv), Thomas Klausner (NetBSD), and Paul Onyschuk (Alpine Linux) for release testing.
>
> Enjoy mandoc, and see you in the mandoc tutorial at EuroBSDCon in Sofia next month!
>
> Yours,
Ingo

g2k14: Antoine Jacoutot on GNOME, rc(8) and /etc cleanup **

undeadly.org — 2014-08-12 10:55:05

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140812064946

Contributed by [pitrh](http://bsdly.blogspot.com/) on Sun Aug 10 12:46:18 2014 (GMT)
from the leading by example dept.

Antoine Jacoutot writes in with this report from the g2k14 hackathon:

> Finally a hackathon where I did not have to spend 90% of my time under ports/x11/gnome \o/ (but of course, I had to cd into it anyway...). Besides some regular tweaks and updates in there, I worked on the gnome.port.mk MODULE to make it more generic and allow non-GNOME ports to benefit from some of its goodies (like xdg triggers and such) without ending up with unneeded build dependencies or things being only relevant to GNOME.

> I also started working on a small utility to manage [rc(8)](http://www.openbsd.org/cgi-bin/man.cgi?query=rc&apropos=0&sec=0&arch=default&manpath=OpenBSD-current) configuration. Having to work with different management tools for my day job, I got really fed up by the fact that OpenBSD did not have a standard way to list, enable, disable... services which means each tool (Ansible, Puppet, SaltStack) has to implement some kind of quirky support for editing [rc.conf.local(8)](http://www.openbsd.org/cgi-bin/man.cgi?query=rc.conf.local&apropos=0&sec=0&arch=default&manpath=OpenBSD-current) (and in a different language) -- when it is actually implemented...
>
> This was the start of an interesting discussion between Theo, robert@ and myself, where we realized having a tool to edit a file that is actually sourced as a shell script may end up being very dangerous if the tool blows up.
>
> So Theo insisted that [rc.conf(5)](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/rc.conf.8?query=rc%2econf%2elocal) (and [rc.conf.local(5)](http://www.openbsd.org/cgi-bin/man.cgi?query=rc.conf.local&apropos=0&sec=0&arch=default&manpath=OpenBSD-current)) stopped being sourced by the [rc.d(8)](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/rc.d.8?query=rc%2ed) system and instead became parsed files. Beware, that means no crazy shell code in these files will work anymore.
>
> This leaded to even more changes: rc.local, rc.shutdown and rc.securelevel stopped being sources as well and are now executed directly by sh(1).
>
> It is worth noting that these 3 files are not even installed by default anymore.These changes de-polluted the rc(8) environment quite a lot!
>
> The fate of my rc edit tool is still under consideration as we may end up developing something that does actually much more than just dealing with rc.conf(8) files ;-)
>
> Speaking about rc.d(8) I implemented a new function: rc_wait(). By default, the rc.d(8) framework would forcibly kill a daemon after 30 seconds if it did not respond to the "stop" action (and would do the same with "start", i.e. stop trying to start it if it did not come alive fast enough). In large database environments, or when using the Squid proxy, this timeout can easily be reached and you probably do not want your application to unsafely end up being killed. Now by setting daemon_timeout, this timeout can be extended (or reduced).
>
> Theo and I started removing configuration files from /etc. Well, not "removing" but actually moving them to /etc/examples/ where they now serve as a placeholder for much more extensive configuration examples. The purpose is not to really to copy the example file under /etc but instead create a file from scratch with the help of the numerous examples that the file under /etc/examples contains. On top of this, some files that were in the etc set got moved to the base one like /etc/services or /etc/protocols (which I updated in the process).
>
> Amongst other benefits, all of this will ease [sysmerge(8)](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/sysmerge.8?query=sysmerge)'s job because it will not have to compare these files against the default ones since there are no default ones installed. When an example file changes from one release or snapshot to another and that you have a corresponding file under /etc, then sysmerge(8) will now warn you that the example has changed (which could indicate an important syntax change for instance).
>
> This move is not over yet, more files will follow, but there are already around 35 files that got moved from the /etc root. This will make automated updates much easier! One of the end-goal being to run sysmerge(8) automatically after an upgrade.
>
> Along with the initial /etc/examples support, I've worked on a very often requested feature for sysmerge(8): support for packages. I have an initial implementation which should be committed pretty soon. It will allow users to compare @sample files installed by packages against the default ones.
>
> As far as I am concerned this was a very productive hackathon and I am very excited with all the recent changes happening in OpenBSD.
>
> Ljubljana was as I remember it from a previous hackathon: awesome! And Mijta did again a more-than-perfect job in hosting the event.

LibreSSL 2.0.5 released **

undeadly.org — 2014-08-08 23:55:06

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140808195101

Contributed by [phessler](http://www.openbsdfoundation.org/donations.html) on Fri Aug 8 19:51:00 2014 (GMT)
from the only-a-few-empty-stomachs dept.

Brent Cook (bcook@) has [announced](http://marc.info/?l=openbsd-tech&m=140752295222929&w=2) the release of [LibreSSL](http://www.libressl.org) 2.0.5:

> We have released LibreSSL 2.0.5, which should be arriving in the LibreSSL directory of an OpenBSD mirror near you.
>
> This version forward-ports security fixes from OpenSSL 1.0.1i, including fixes for the following CVEs:
>
> CVE-2014-3506
CVE-2014-3507
CVE-2014-3508 (partially vulnerable)
CVE-2014-3509
CVE-2014-3510
CVE-2014-3511

>
> LibreSSL 2.0.4 was not found vulnerable to the following CVEs:
>
> CVE-2014-5139
CVE-2014-3512
CVE-2014-3505

>
> We welcome feedback and support from the community as we continue to work on LibreSSL.
>
> Thank you,
>
> Brent

g2k14: Reports Roundup **

undeadly.org — 2014-08-08 13:55:08

BSDNow Episode 049: Episode 049: The PC-BSD Tour **

undeadly.org — 2014-08-08 11:55:18

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140808073543

Contributed by tbert on Fri Aug 8 07:34:57 2014 (GMT)
from the delicious GUI filling dept.

On this week's [episode](http://www.bsdnow.tv/episodes/2014_08_06-the_pcbsd_tour) of [BSDNow](http://www.bsdnow.tv/), the gang takes us on a whirlwind tour of the GUI tools for PC-BSD, in addition to the usual weekly roundup of rumours and hearsay!

**[** [Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0049-432p.mp4) **|** [HD Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0049.mp4) **|** [MP3 Audio](http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/jbmirror/bsd-0049.mp3) **|** [OGG Audio](http://www.podtrac.com/pts/redirect.ogg/traffic.libsyn.com/jbmirror/bsd-0049.ogg) **|** [Torrent](http://bitlove.org/jupiterbroadcasting/bsdnowhd) **]**

phessler: emergency g2k14 hackathon **

undeadly.org — 2014-08-06 16:55:04

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140806125308

Contributed by [phessler](http://www.openbsdfoundation.org/donations.html) on Wed Aug 6 12:42:48 2014 (GMT)
from the you know it's urgent dept.

Longtime Undeadly editor, Peter Hessler (phessler@) writes in:

> With the g2k14 hackathon starting on tuesday, I saw the commits and chatter from the hackathon. sadly, my original plan was to stay at work mostly since I am out of vacation days for the year. Thursday morning, I see that not only were a few more hackathon shirts being printed for attendees that wanted more, but also last-minute flights to Ljubljana were actually affordable. I nudged claudio@, who works at the desk next to me "hey, want to go to the hackathon for the weekend?"

> He nods yes, so we rush to book everything. The flights left Friday after work, and returned stupid early on Monday morning so we could go back to work. We arrive in the evening on Friday, and run into Bob et al, who were just returning from a celebratory dinner after the first release of LibreSSL portable.
>
> During the hackathon I worked mostly in the installer/upgrader. I wanted to be able to have one more [enter] to whack when upgrading a laptop with softraid crypto, so I had the upgrader detect if the first disk partition 'a' is of type RAID, and if it is, then skip it. I still need to test on strange arches, and to check for corner cases.
>
> Another project was to support installing onto softraid crypto directly from within the installer. I have a working prototype, but again, lots of corner cases and testing still remains. I did end up doing a clean install on my main laptop with it, so it does work for simple cases.
>
> I also talked with rpi@ about the ability to auto-upgrade entirely from the local system. This would entail booting from bsd.rd, and it detecting a specially named file on the root partition, and doing the upgrade blindly. Risky, but if you have a remotely hosted system, with no console or access to the network, you may not have many options.
>
> None of these will make it to 5.6, but I hope to have them in -current not long after unlock.
>
> There was a big grand discussion involving the network stack hackers, and some of the low-level kernel experts, about the status of the network stack and MP, and where we wanted to go, and how to get there. Most of the discussion was figuring out which pieces can be split up, and where we should put the fences.
>
> I was at the previous hackathon in Ljubljana, and just like last time, had a fantastic time. Many thanks to Mitja for organizing the event, and special thanks for getting things organized for us last minute slackers!

OpenBSD product distribution will move **

undeadly.org — 2014-08-05 18:55:05

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140805141742

Contributed by [phessler](http://www.openbsdfoundation.org/donations.html) on Tue Aug 5 14:17:35 2014 (GMT)
from the farm-where-he-can-run-and-chase-rabbits-all-day dept.

After many years of faithfully serving the OpenBSD community, Austin Hook (austin@) will be [retiring](http://marc.info/?l=openbsd-misc&m=140724761719777&w=2) from mailing you your delicious Puffy-flavored merch. As such, the old stock (CDs, tshirts, baby mulchers) will become unavailable. [Order](https://https.openbsd.org/cgi-bin/order) now before they go extinct!

g2k14: Christian Weisgerber on Package Building without sudo **

undeadly.org — 2014-08-03 16:55:05

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140803122705

Contributed by [tbert](http://bsdly.blogspot.com/) on Sun Aug 3 05:54:09 2014 (GMT)
from the sandwich makes itself dept.

Christian Weisgerber wrote in with this report from g2k14:

> I updated the gettext port, of course. What'd you think I'd do at a hackathon?

The most interesting thing I worked on at g2k14 started out with a question: Why exactly do we run the fake step as root? (Hint: FreeBSD's corresponding stage infrastructure does not.)

> Because ports want to install with "install -o root -g bin"? But they only do so because we tell them to. We pass those flags to configure. We just need to stop doing this.
>
> Because some ports want to set a special user/group and chmod to suid/sgid? The vast majority of ports do not and the few that do already require corresponding annotations in the PLIST. Why not just use this metadata for the package, instead of the actual file modes?
>
> Really, most ports could be built just fine without sudo. Those that do not can be annotated, FAKE_AS_ROOT=Yes, and fixed eventually. (You will still need sudo for installing dependencies, though.) All that is required is a little bit of support in our infrastructure.
>
> To this end I came up with patches to bsd.port.mk and pkg_add that accomplish this. Initial testing revealed a number of ports modules that would also require minor tweaking, but as expected it became clear that rather few changes would go a long way to handling most of the ports tree.
>
> At this stage this is merely a proof of concept, showing that the approach is workable. To be revisited once the 5.6 release is out the door.

BSDNow Episode 048: Liberating SSL **

undeadly.org — 2014-08-01 12:55:06

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140801081629

Contributed by [jj](http://www.inet6.se) on Fri Aug 1 08:14:46 2014 (GMT)
from the block-cipher-diaries dept.

On this week's [episode](http://www.bsdnow.tv/episodes/2014_07_30-liberating_ssl), the [BSDNow](http://www.bsdnow.tv) crew gabs about the BSD tribe, continues the recursive Undeadly mentions, interviews [LibreSSL](http://www.libressl.org) portable maintainer Brent Cook (bcook@), and Bob Beck (beck@) writes in to let the hosts know about arc4random-related FreeBSD porting issues.

**[** [Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0048-432p.mp4) **|** [HD Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0048.mp4) **|** [MP3 Audio](http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/jbmirror/bsd-0048.mp3) **|** [OGG Audio](http://www.podtrac.com/pts/redirect.ogg/traffic.libsyn.com/jbmirror/bsd-0048.ogg) **|** [Torrent](http://bitlove.org/jupiterbroadcasting/bsdnowhd) **]**

Using ifstated to monitor links and dynamically adjust PF config on event **

undeadly.org — 2014-07-31 17:55:05

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140731130633

Contributed by [pitrh](http://bsdly.blogspot.com/) on Thu Jul 31 13:05:27 2014 (GMT)
from the states of confusion dept.

[Sevan Janiyan]() writes:

> It's possible to misuse NAT to load balance outbound traffic across multiple internet connections from different service providers,see the [Load Balance Outgoing Traffic](http://www.openbsd.org/faq/pf/pools.html#outgoing) section of [PF FAQ](http://www.openbsd.org/faq/pf).

The shortfall with this configuration is when implemented alongside unstable links, forwarding will continue to be attempted over the links which are down, this will cause issues such as long hangs for users behind the NAT while connections time out. To mitigate this, `ifstated` can be used to smooth things over.

Read the rest at [geeklan.co.uk](https://www.geeklan.co.uk/?p=1564), Sevan's blog site.

Call for Testers: radeondrm(4) updates **

undeadly.org — 2014-07-29 11:55:06

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140729071820

Contributed by tbert on Tue Jul 29 07:18:55 2014 (GMT)
from the not-that-DRM dept.

Jonathan Gray (jsg@) [posted](http://marc.info/?l=openbsd-tech&m=140654976008811&w=2) a call for testers for [radeondrm(4)]() updates:

> I'm looking for a few people to test some additional radeondrm fixes from the recently released Linux 3.8.13.27:
>
> In particular on newer asics with displayport/eDP as I can only test on r100/lvds at the moment.

g2k14: Ted Unangst on the Art of the Tedu **

undeadly.org — 2014-07-29 11:55:06

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140729070721

Contributed by tbert on Tue Jul 29 07:07:41 2014 (GMT)
from the less-is-more dept.

Ted Unangst (tedu@) talks about teduing a goodly amount of code, among other things:

> Despite being in the same room as many other LibreSSL developers for the first time (since the beginning of LibreSSL at least), I didn't do too much work on that front. I did remove the compression feature (as made famous by the [CRIME attack](http://en.wikipedia.org/wiki/CRIME); not all protocols or deployments are vulnerable, but we're also aiming for a simpler feature set overall) and made a few other cleanups. While it's very helpful to be in the same room as other hackers to exchange ideas, having everyone pounding on the source at the same time is a little troublesome so I elected to stay out of the way.

> I did, however, take the chance to bounce some ideas for a ressl API off the other developers. Instead of continuing to use the OpenSSL API, the ressl API is entirely separate. Internally, ressl itself uses the OpenSSL API, but the interface presented to the user is quite different. Our particular focus is on absolving the user of the need to know about X.509 and ASN.1 internals; instead you simply ask ressl to verify the remote peer's hostame. And actually, you don't even need to do that because that's the default behavior. (Un)fortunately, jsing@ liked the idea so much he ran ahead and implemented it before I got the chance. One of the dangers of being at a hackathon, I guess.
>
> Besides that, I continued my hackathon tradition of deleting a lot code that most people probably never even knew existed. Say goodbye to asa, fpr, mkstr, xstr, oldrdist, fsplit, uyap, and bluetooth. Of these, you may possibly miss bluetooth support. Unfortunately, the current code doesn't work and isn't structured properly to encourage much future development.
>
> I reviewed a few filesystem diffs from pelikan@ for ext2fs and tobias@ for msdosfs. At the beginning of the hackathon I showed some developers a diff that changes the buffer cache to using a 2Q like strategy. That's gone through a few iterations, but won't make 5.6. Expect to see it soon, though.
>
> I made two changes to the kernel malloc(). The first was an idea deraadt@ had suggested some time ago. The current poison values (designed to detect use after free and other corruption) are rather limited, meaning that if a particular flag bit is set or unset, the incorrect code may continue to function. I change the poison values to inverted patterns, reversing all the bits. This proved to be very successful, finding many more bugs. Too successful, in fact, because there's not enough time to chase down and fix all the fallout before release, so that change has since been reverted.
>
> The second change was to add a size argument to [free(9)](http://www.openbsd.org/cgi-bin/man.cgi?query=free&apropos=0&sec=9&arch=default&manpath=OpenBSD-current). This is currently not used, as most callers pass 0 to indicate unknown, but will allow us to simplify some code on the free side and make some other fun changes as well.
>
> For userland [malloc(3)](http://www.openbsd.org/cgi-bin/man.cgi?query=malloc&apropos=0&sec=3&arch=default&manpath=OpenBSD-current), I did some work to accelerate threaded applications. I now have a stable first version of this ready, but it will wait for the next release as well.

Ingo Schwarze Interviewed on BSDTalk **

undeadly.org — 2014-07-28 16:55:05

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140728123005

Contributed by tbert on Mon Jul 28 12:26:40 2014 (GMT)
from the man's-man dept.

The [latest episode ](http://bsdtalk.blogspot.de/2014/07/mandoc-with-ingo-schwarze.html) of BSDTalk involves our very own Ingo Schwarze (schwarze@):

> **bsdtalk243 - mandoc with Ingo Schwarze**
>
> Interview about mandoc with Ingo Schwarze. The project webpage describes mandoc as "a suite of tools compiling mdoc, the roff macro language of choice for BSD manual pages, and man, the predominant historical language for UNIX manuals."
>
> Recorded at BSDCan 2014.

g2k14: Andrew Fresh on Programming Perl **

undeadly.org — 2014-07-28 16:55:05

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140728122850

Contributed by [tbert](http://bsdly.blogspot.com/) on Mon Jul 28 12:28:44 2014 (GMT)
from the do you take it with one hump or two? dept.

> This was my first hackathon so I wasn't really sure what to do. I had some plans to possibly import perl 5.20, but I was hoping to include 5.20.1 which isn't out for at least a month and espie@ says that it is too close to lock. I will continue to push local patches upstream to get everyone using perl on OpenBSD to be using the same improvements that are in our base perl.

> I was sure some project would present itself that I really wanted to work on, so I started out by slacking and working on the [tool](https://github.com/afresh1/openbsd-module-ports) I've been playing with to make generating ports for things that keep track of their dependencies and have automated installers, such as things from perl's [CPAN](http://metacpan.org) or Node's [NPM](http://npmjs.org) Perl support is pretty good, but both Python and Nodejs, while started have run into roadblocks due to the different ways they handle dependencies. Talked some to abeiber@ about how to solve the nodejs problem and it sounds like someone will have to end up patching npm to add support for features we need, mostly the ability to install dependencies offline. Still not sure how to ask python packages for a list of their dependencies so automating that has ground to a halt.
>
> During the time I was avoiding reading npm source or better understanding Python's different package systems, I got the last few dependencies updated so that I can update [DBIx::Class](https://metacpan.org/release/DBIx-Class) to the current version. I actually submitted that update, but zhuk@ mentioned that he has examples of how to start up local database instances with their datafiles inside of the port's ${WRKDIR} so that I can run "live" tests automatically. That sounds like a great feature so I will figure out how to accomplish that and update the port before re-submitting.
>
> I did submit a few bugs to perl upstream while at the hackathon, [reporting](https://rt.perl.org/Public/Bug/Display.html?id=122263) an issue that ended up being unsolvable due to the way perl buffers output and also [adding](https://rt.perl.org/Public/Bug/Display.html?id=122252) configure glue and other things for pelikan@'s POSIX international currency formatting additions. I need to do a little cleanup on it, but that should go in soon.
>
> Eventually, there was discussion about why there are adduser, useradd, and "user add" commands and how terrible they were. There was a suggestion to get rid of the perl based adduser, but many people prefer the interactive interface because they add users so infrequently that the additional prompting is super helpful. Unfortunately, I fell for their trick and looked inside the file. I am now working on rewriting adduser with some more [modern perl](http://modernperlbooks.com) style, I got started on that on Friday evening and got about half way through an initial rewrite by Sunday night. The current design I am looking at is providing a module to do the heavy lifting so that people scripting system management tools (in perl) can talk to a better API than forking out and driving one of the existing scripts. I hope to make it easy to write your own tools to manage users safely and programmatically, while also providing a tool with a friendly, interactive frontend that is also easy to drive from a shell script.
>
> Ljubljana is beautiful, the people were amazing and so much good, vegan food. Plus the weather was overcast, all of which kept me from getting too homesick for [Portland, OR](http://www.youtube.com/show/portlandia). I really enjoyed how friendly and welcoming all of the people we met there were and how well we worked around the surprisingly few language barriers.
>
> As this was my first time in Europe, I left the hackathon on Monday morning and took a shuttle to Venice as recommended. The recommendations were always "Venice? Don't go there, it's so touristy! Oh, you've never been? You should go and see it at least once." So Lisa and I went and added to the number of tourists. We have learned that we really enjoy traveling the world and I am greatly looking forward to the next hackathon for an excuse to finally see more of the world. It did make me want to improve the number of human languages I can do basic things in.
>
> I too need to be sure to mention what a good job Mitja did organizing the hackathon, many, many thanks to him and to Dijaski dom Tabor.

BSDNow Episode 047: DES Challenge IV **

undeadly.org — 2014-07-27 09:42:57

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140725121157

Contributed by tbert on Fri Jul 25 12:11:40 2014 (GMT)
from the InceptionBSD dept.

On this week's [episode](http://www.bsdnow.tv/episodes/2014_07_23-des_challenge_iv), BSDNow interviews FreeBSD Security Officer Dag-Erling Smørgrav, links back to Undeadly g2k14 hackathon reports, and discusses the week's BSD news and hearsay.

**[** [Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0047-432p.mp4) **|** [HD Video](http://www.podtrac.com/pts/redirect.mp4/201406.jb-dl.cdn.scaleengine.net/bsdnow/2014/bsd-0047.mp4) **|** [MP3 Audio](http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/jnite/bsd-0047.mp3) **|** [OGG Audio](http://www.podtrac.com/pts/redirect.ogg/traffic.libsyn.com/jnite/bsd-0047.ogg) **|** [Torrent](http://bitlove.org/jupiterbroadcasting/bsdnowhd) **]**

g2k14: Landry Breuil on Taming Mozilla **

undeadly.org — 2014-07-27 09:42:57

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140724161550

Contributed by tbert on Thu Jul 24 08:54:43 2014 (GMT)
from the firefox-fur-coat dept.

> As is now an habit, i had made zero plans for this hackathon, i had some unfinished stuff lying around, and no real big task ahead. Firefox 31 betas were already working for me, and only needed actual testing.

> In the end, i spent quite a bunch of time doing some sysadmin stuff with ansible, with which i've really felt in love. Thanks to rpe@, we have a really up-to-date port, and it was the perfect occasion for me to reconfigure some of my infrastructure servers, starting by our test bulk cluster OPI - which can be now fully upgraded/reconfigured in a single ansible playbook task, taking care of all the steps to be able to run a bulk build. This will soon be featured in an article in a french newspaper issue about BSD systems. I'll really stress that ansible can be the perfect tool to remotely administer OpenBSD systems, only needing ssh and python on the remote machine, and the learning curve of the tool is really smooth.
>
> I also spent some time digging in various pkg_tools/pkg_locatedb/pkg_check/sqlports/pkg_sign usecases, more material for another article in the same newspaper - along this, i had lots of questions for espie@, who still thinks his code is easy to understand to outsiders.. unfortunately, not everyone is as smart as him.
>
> A hackathon wouldnt be one without some activity in mozilla's bugzilla, so i resumed pushing some patches that were still local and pending to reduce our count of local modifications - unfortunately, some last minute changes to our headers (read: endian.h) brought more patches to all our mozilla ports, and ruined my efforts :)
>
> I tried porting the new mozilla sync server, since the one we have in-tree will stop working with gecko 31. Unfortunately, after 15 new ports of some python libs, and realizing i'd also need to port around a bazillions of node js modules, i totally gave up on this. I doubt this'll improve in the future, the new sync server is not really designed to be properly packaged, rather ran directly from a one-shot checkout of its sources.
>
> I also did some minor wip update to the www/nginx port, adding the ldap auth patch, polished ports for a pair of GIS caching servers i plan to use at work (mapcache, and mapproxy) but that work is still awaiting feedback and review.
>
> As Vadim said, i spent quite a bunch of time proofreading lots of new ports needed for kde4 updates, fixing nits around and commenting on style issues - but since he's now an experienced porter, i didnt have much to add... and finally, i reviewed the work of our GSOC student about systemd-like daemons, to allow us to have equivalent features provided via D-BUS (those are more and more needed by gnome), and the architecture is shaping up quite nicely - we had quite some interesting exchange with him and ajacoutot@. I think that's material for a standalone undeadly issue, i'll let ian talk about it :)
>
> Thanks again to mitja and his crew, again a perfect event in a really nice city!

Minimalist HTTP Daemon Activated in Base **

undeadly.org — 2014-07-27 09:42:57

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140724094043

Contributed by tbert on Thu Jul 24 08:32:18 2014 (GMT)
from the slowhttpd(8) dept.

Reyk Flöter (reyk@) recently [committed](http://marc.info/?l=openbsd-cvs&m=140605064926486&w=2) the [rc(8)](http://www.openbsd.org/cgi-bin/man.cgi?query=rc&apropos=0&sec=0&arch=amd64&manpath=OpenBSD-current) glue to make his forked-from-relayd http server usable:

>
>
> CVSROOT: /cvs
> Module name: src
> Changes by: reyk@cvs.openbsd.org 2014/07/22 11:37:16
>
> Modified files:
> usr.sbin : Makefile
> etc : Makefile changelist rc.conf
> Added files:
> etc/rc.d : httpd
>
> Log message:
> Enable httpd(8) in the builds to get more testing, feedback and
> improvements. It is not "finished" but serves static files.
>
> ok deraadt@
>

This code is derived from [relayd(8)](), which means that it shares the privsep architecture and human-readable configuration syntax common to many OpenBSD-originated daemons.

This is still early work, and in a [series](http://marc.info/?l=openbsd-cvs&m=140615618302419&w=2) of [follow-up](http://marc.info/?l=openbsd-cvs&m=140615297101433&w=2) [commits](http://marc.info/?l=openbsd-cvs&m=140612204019668&w=2), reyk@ has fixed a smattering of issues that have come up during early use. If you have a need for a web server that does little more than serves static content, go ahead and give it a spin and see if you can keep Herr Flöter up late again!

Interview: Brent Cook Talks About Porting LibreSSL **

undeadly.org — 2014-07-27 09:42:57

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140724063728

Contributed by tbert on Thu Jul 24 08:19:14 2014 (GMT)
from the bringing-it-back-to-irix dept.

Undeadly was able to get a few minutes of time with Brent Cook (bcook@), who worked on the official LibreSSL [port]():

> **Undeadly**: Tell us about yourself; who are you, and how did you get involved with the LibreSSL porting effort?
>
> **bcook@**: My name is Brent Cook. I'm a generalist programmer by day, mostly working on low-level system stuff. I'm also a code performance junky, and I also play piano and saxophone, gigging occasionally around Austin, TX.

> I have worked on embedded Linux distributions and toolchains, multi-core network processors, real-time OSes, networking stacks, bootloaders and hardware bring up. My current gig at Boundary is developing and maintaining a system and network analysis agent that runs on many OSes, from Solaris to Windows.
>
> Last year, I wrote a [blog post](http://boundary.com/blog/2013/10/01/welcome-meter-2-foundations/) about software that was built into the Boundary agent, and OpenSSL was one of the biggest obstacles I encountered during its development, both building it and using its API.
>
> After patching a lot of systems post-Heartbleed this year, and when LibreSSL first start showing up in the OpenBSD CVS sources, I decided to have a go at implementing a new build system, linking in bits from libbsd as needed. To my initial surprise, everything I tested it on just worked, so I pushed the results to GitHub. Things remained relatively quiet though.
>
> One day, I noticed the referrals in the GitHub project shoot up after it was [linked to]() by the Insane Coding blog. After the great analysis by insane coder, I quickly realized that libbsd's implementations might implement the outward API, but in a lot of cases do not actually implement the same security guarantees of many of the functions from OpenBSD. So, I set out to use or rewrite the best implementations that I could find to 'fill in the gaps'.
>
> I was also maintaining a load of local patches on the libressl source itself, so to make things easier for myself, I pushed them to the tech@ list for review (to some initial trepidation.) I was happy to have some success and to find that the OpenBSD devs were interested in portability as well.
>
> After a month or so of occasional maintenance and refinement of the port, Theo contacted me about some changes to the CSPRNG code in LibreSSL and gave me a heads-up on things that should change in my port. I was on vacation at the time, but I managed to get some of the initial infrastructure for [getentropy(2)]() integrated with an ARM chromebook running Crouton. After that, I was invited to meet the rest of the OpenBSD team in Slovenia to work on an official port.
>
> During this time, I did not really pay much attention to the other ports. But from what I hear, I was the last man standing, if you will :)
>
> **Undeadly**: How was it working with the rest of the LibreSSL team? What did you learn that you didn't know before, and, conversely, what were you able to teach them?
>
> **bcook@**: After recovering from a mixture of impostor syndrome and jet lag, it was a very pleasant experience. The team works very well together, and I enjoyed getting to know Miod, Ted, Philip, Theo, Joel, Mark, and Bob, as well as the rest of the OpenBSD team.
>
> I did not know a lot about how the OpenBSD team coordinates itself before the hackathon. The tech@ and other mailing lists just seemed too quiet for the amount of development work that gets done. I also did not know how diverse the team was, which is pretty amazing.
>
> I liked seeing how mistakes were found and rapidly corrected through peer review, or simply by everyone running the latest code all the time. It was also cool watching opposing sides of various technical issues argue in a very passionate way; I sometimes thought maybe a fight might break out! But then everyone would eventually chill out, think about it more, and come up with a good solution that made everyone happy.
>
> I don't know if I really taught the team anything - they're really smart guys! Bob is probably learning a lot more about automake, autoconf and GitHub than he ever intended. We're all certainly expanding our repertoire of OS-specific hacks and features that we can use to coerce systems into working in secure and reliable ways. We especially learned that using the byte order macros on Solaris can be a very frustrating experience!
>
> **Undeadly**: Is there anything you've taken away from your experience that you'd like to apply in your own work?
>
> **bcook@**: Though the code that I typically work on already runs on a lot of different platforms, I learned much more about portability and POSIX details both from the OpenBSD team and the larger community. I would like to apply that knowledge to my own coding practices as well.
>
> As far as the team dynamics, I felt quite at home. The 'Shut up and Hack' ethos of solving problems rather than complaining about them is something I will definitely continue.
>
> **Undeadly**: Good to hear! Thanks for your time, and your work porting LibreSSL!
>
> **bcook@**: Cool, it has been fun so far.

g2k14: Matthieu Herrb on Bringing X Forward **

undeadly.org — 2014-07-27 09:42:57

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140723142224

Contributed by tbert on Wed Jul 23 14:22:19 2014 (GMT)
from the #define-ing-progress dept.

Matthieu Herrb (matthieu@), who is the mad Frenchman who maintains Xenocara, writes in to share his g2k14 experience:

> My main projects (multitouch, dhcpv6) didn't make any progress as I was distracted into X sets tweaks at the request of a few other hackers.

> After much discussion this only led to the addition of ucpp in base (after a short detour by /usr/xenocara/app/xrdb-cpp) as /usr/libexec/auxcpp.
>
> The reason is that xdrb (part of xbase which is required by many ports) needs a C pre-processor to run. But since gcc 4, /usr/bin/cpp is in the comp set because it's just another invocation of the full gcc. So xbase required the comp set to be installed.
>
> This annoys 2 kind of people: those with appliances with small disks and the paranoid ones who don't want to provide a C compiler to attackers (which may be a good idea, when looking at components of the [windigo operation](http://www.welivesecurity.com/2014/03/18/operation-windigo-the-vivisection-of-a-large-linux-server-side-credential-stealing-malware-campaign/)).
>
> So auxcpp is now part of the base set, and the depency of xbase on comp is gone. The X sets will stay in their current state for 5.6.
>
> Otherwise, I've done a few updates on xenocara components. The xenocara tree is now mostly ready for 5.6.
>
> I've nevertheless enjoyed the hackathon. Thanks to Mitja and his team for the organisation and to all foundation donors for the funding!

LibreSSL 2.0.3 Released **

undeadly.org — 2014-07-27 09:42:56

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140722071423

Contributed by tbert on Tue Jul 22 06:40:20 2014 (GMT)
from the demand-improved-spork-detection dept.

Bob Beck (beck@) has [announced](http://marc.info/?l=openbsd-tech&m=140599450206255&w=2) the release of [LibreSSL](http://www.libressl.org/) 2.0.3:

>
>
> We have released an update, LibreSSL 2.0.3 - which should
> be arriving in the LibreSSL directory of an OpenBSD mirror near
> you very soon.
>
> This release includes a number of portability fixes based on the
> the feedback we have received from the community. It also includes
> some improvements to the fork detection support.
>
> As noted before, we welcome feedback from the broader community.
>
> Enjoy,
>
> -Bob
>

g2k14: Ken Westerback on DHCP and dump(8) **

undeadly.org — 2014-07-27 09:42:56

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140722071413

Contributed by tbert on Mon Jul 21 17:35:11 2014 (GMT)
from the electric-boogaloo dept.

> Having missed Ljubljana 1, I looked forward to Ljubljana 2 with great expectations. I was not disappointed! Mitja ran a great hackathon with a nice site and an excellent city around it.

> I arrived with a bunch of M's in my tree that had been making no headway against the [LibreSSL](http://www.libressl.org/) gale. Mostly to do with fixing daemons using IMSG, and in particular msgbuf_write(). I found that standing next to the relevant developers and looking sad was very effective and got all the M's resolved. At which point claudio@ pointed out they could all be improved futher. Sigh.
>
> In addition, I noticed that [dhclient(8)](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/dhclient.8?&manpath=OpenBSD%2dcurrent&arch=amd64&query=dhclient) was writing out [resolv.conf(5)](http://www.openbsd.org/cgi-bin/man.cgi?query=resolv.conf&apropos=0&sec=0&arch=amd64&manpath=OpenBSD-current) a few more times than necessary (twice when binding and once when going away) and I got that down to once. Unfortunately killing several developers' machines by inducing hard renew loops for a while. But it was a hackathon, so that was ok.
>
> I worked with yasuoka@ to get some of his [dhcpd](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/dhcpd.8?&manpath=OpenBSD%2dcurrent&arch=amd64&query=dhcpd) fixes and enhancements in, and adapted a fix he had received for dhclient handling of classless routes.
>
> I also committed the [dump(8)](http://www.openbsd.org/cgi-bin/man.cgi?query=dump&apropos=0&sec=0&arch=amd64&manpath=OpenBSD-current) fixes for 4K sector devices. A bunch of msdos and ffs fixes from tobias@ also got my oks, as did some initial GPT support from Markus Mueller, one of our GSOC students.

g2k14: Stefan Sperling on wireless drivers **

undeadly.org — 2014-07-27 09:42:56

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140721125235

Contributed by [jj](http://www.inet6.se) on Mon Jul 21 08:55:11 2014 (GMT)
from the internet is just a series of airgaps dept.

> I spent most of this hackathon looking at problems in wifi drivers.

I wasn't exactly sure in advance which problems I wanted to work on. So I packed a bunch of hardware, including several USB wifi adapters, (rsu(4), 2x run(4), rum(4), urtwn(4), zyd(4)), some miniPCIe cards (an unsupported cousin of urtwn(4) named Realtek 8188CE, unsupported athn(4) AR9485, bwi(4)), two laptops, and an access point. This left me with more than enough toys for a week.

> I also brought a pcengines APU board which was given to me by Remi Locherer and mijenix (thanks!). It had arrived in the mail just a day or two before I started travelling. At the hackathon, kirby@ added some miniPCIe cards to my collection, ath(4) AR5424 and ral(4) RT3090.
I assembled the APU together with florian@ and ended up plugging the ath(4) and ral(4) cards into it first.

AR5424 turned out to be a problematic card ("ath0: unable to reset hardware; hal status ..."). This card has never been working, and searching mailing list archives turns up various [reports](http://marc.info/?l=openbsd-misc&m=140083635708140&w=2) [and](http://marc.info/?l=openbsd-misc&m=132969397110211&w=2) [attempts](http://marc.info/?l=openbsd-tech&m=126437914024661&w=2) of fixing the driver. I ended up hacking the driver for about two days, trying out changes based on information found in Linux and FreeBSD, with hints from reyk@. It turns out this is an 11g only card and should start working once ath(4) 11g mode is fixed (another known issue).

I put ath(4) aside for something more fun. Theo told me of a rather frustrating experience at a conference which had two wifi networks, both using the same SSID and the same encryption key, with one using WEP and the other using WPA. As a small step towards better usability, I made information about wifi encryption ciphers available to userland, and based on this changed ifconfig(8) scan to display the type of encryption used by wireless networks.

While testing my scanning changes I managed to make all USB ports on my laptop unusable by plugging in the zyd(4) device. mpi@ helped me track this down to race conditions in zyd(4)'s register i/o implementation which could end up dead-locking USB kernel threads. This took some time since the device occasionally stopped working entirely for mysterious reasons which we ended up blaming on broken hardware. Quite possibly the bug would not have triggered with a properly working device, though.

I also looked into a problem with bwi(4) which I [diagnosed](http://marc.info/?l=openbsd-misc&m=140267041817160&w=2) about a month ago. The device cannot do DMA to address ranges above 1GB of memory, so it is quite unhappy in my powerbook G4 with 1.5GB of RAM. claudio@ who had fixed a similar problem in bce(4) years ago helped and tedu@ and miod@ very convincingly made clear that all kernel panics and crashes I was experiencing were due to my local bwi(4) changes alone. I could not get this done at the hackathon and ended up doing some more work on it at home. I now have bwi(4) working on my machine and posted a [call for testing](http://marc.info/?l=openbsd-tech&m=140570091624436&w=2) and is now committed.

I also helped florian@ and henning@ with IPv6-related things and reviewed/tested workq->taskq conversion diffs from blambert@ who finally fixed that nasty duplicate-address prevention hack in nd6_addr_add() I had added some time ago.

The week was very enjoyable and flew by way too fast. I really didn't feel like leaving when the hackathon was over. Many thanks to Mitja for making this event happen!

g2k14: Florian Obser in IPv6 land **

undeadly.org — 2014-07-27 09:42:56

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140721125020

Contributed by [jj](http://www.inet6.se) on Mon Jul 21 08:54:35 2014 (GMT)
from the block in all inet6 on any flags = rfc4620 dept.

> I arrived in Ljubljana somewhat tired so I started the first day off with some light ping(8) and ping6(8) hacking. Some unifdef(1) application for
#ifdef FEATURE_THAT_EXISTS_SINCE_FOREVER_BUT_MAYBE_WE_DONT_HAVE_IT and some cleanup by hand. The idea is to have ping(8) and ping6(8) be the same binary like traceroute(8) and traceroute6(8).

> It has been clear for some time that the ping(8) merge would be harder than the traceroute(8) merge so I stared at the command line flags matrix I prepared some time ago (http://sha256.net/dump/ping_vs_ping6.txt) to figure out what to do about the colliding flags, i.e. '-I'.

On the second day I still had no clear idea what to do about the colliding flags besides that ping6(8) needed to change and not ping(8). It's used in scripts which must not break while ping6(8) is probably used far less, especially the obscure flags which I need to move around.

So to not get stuck I switched to my PowerDNS 3 port I have been working on and off for a year now - you can guess that it's always at the bottom of my todo pile. After finding some bugs earlier this year in PowerDNS itself the port was ready and I mailed it around - but then I noticed that the rundeps were missing for somewhat important dependencies like boost and botan. Having received no feedback for my mail on ports@ it dropped back to the bottom of my todo pile.

So now I'm at a hackathon and there are ports people around. I went and bothered naddy@. He had a quick look, "Oh yeah, you need to do this and that" and lo and behold it works. Boy, it's a lot easier when you know what you are doing...

With that sorted out, back to ping6(8) for me. I (re-)discovered the Node Information queries (RFC 4620 [http://tools.ietf.org/html/rfc4620], ping6 -w). I played with them before, but couldn't get an answer from an OpenBSD machine, so I figured that feature doesn't exist in OpenBSD's kernel. I tried again at the hackathon and suddenly I got answers. Uh oh. (There was probably a firewall in the way or something like that when I tested it before.)

A bit of a ruckus ensued in the hackroom and benno@ first changed the default for net.inet6.icmp6.nodeinfo from 1 to 0 to have it off by default and worked on a diff to completely remove it from the kernel, and committed it a day later.

Tedu@ dug up the very nice -Werror-implicit-function-declaration gcc flag and I cleaned up /sbin and /usr/sbin. Two quick fixes in disklabel(8) and mrouted(8) for missing prototypes and I thought I'm done there.

Well, turns out not quite. COPTS from usr.sbin/Makefile.inc don't get propagated to programs in usr.sbin using Makefile.bsd-wrapper and configure. Those are bind(8), nginx(8), nsd(8) and unbound(8).

I looked around in the build system and asked espie@ for help but was not not quite clear what the right fix might be.

So I focused on making sure those 4 programs are clean once the right solution presents itself. Well turns out, you need to be careful here. Suddenly conftests of configure are failing. For bind(8) this meant that it can no longer find openssl^Wlibressl. For nsd(8) and unbound(8) this meant that it suddenly couldn't figure out that OpenBSD is indeed providing certain string functions in libc and tried to use portability functions shipped with the nsd(8) / unbound(8) distribution. So some careful analysis was needed to make sure that both build the same way as before. Since wouter@ was in the room this could be quickly fixed upstream, too.

And now, off to IPv6 land...

I was sitting next to henning@ during the hackathon. I had just finished sweeping /usr/sbin for -Werror-implicit-function-declaration and was listening to music on my headphones. When there was silence because the song reached the end I heard that stsp@ had walked over to our table and was discussing something SLAAC (stateless address auto configuration) related with henning@. A big imaginary question mark formed over my head. Curious about what was going on I listened a bit, quickly read a diff they were apparently arguing about to get up to speed and then joined an half hour long discussion about the merits of one particular continue in a for loop. We also asked bluhm@ for input and I think in the end we found the right solution.

Turns out the diff they were arguing about was the ifconfig(8) autoconf flag diff. Now we have a per interface flag if we want to do SLAAC or not. The old net.inet6.ip6.accept_rtadv was for all interfaces.

With that we can move sending of router solicitation messages - something currently rtsol{,d}(8) is doing - to the kernel.

The kernel already does all the other stuff needed for SLAAC so just sending one packet at the right time is not so much more code for the kernel.

First of I wrote a userland implementation in ifconfig(8) to get a feel for the packets being send. The code in rtsold(8) is a bit all over the place and hard to follow. Also the turnaround times in userland are much faster then debugging something in the kernel.

Having this running after a few minutes it was now time to move this into the kernel. Turns out there are similar functions in sys/netinet6/nd6_nbr.c doing more or less the same stuff I need (btw. mpi@ send me off an a side quest to clean that up by factoring out common functionality).

So that was pretty easy, quickly hooked the function up at the point when DAD (duplicate address detection) finishes for the link local address and the proof of concept worked on the first try. No kernel panic! That's a new one! Yay!

With that working I solicited (pun intended) some help from stsp@ on brain storming in which situations we need to send solicitations.

After a few iterations of diff review by mpi@ and him explaining to me the finer details of the network stack I think the diff is now more or less ready but won't make 5.6. With this we will be able to send rtsol{,d}(8) to the attic.

Thank you very much Mitja and everybody else involved in making this hackathon happen. Also thank you to all the other OpenBSD developers who took the time and came to Ljubljana to make this an enjoyable and productive week.

p.s.: We need the same amount of beer/h to write code as Mitja's car needs gasoline while idleing. So I guess we are more energy efficient than Mitja's car.

Hibernating to Encrypted softraid(4) Now Supported **

undeadly.org — 2014-07-27 09:42:56

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140721090626

Contributed by [tbert](http://www.inet6.se) on Mon Jul 21 09:02:51 2014 (GMT)
from the do androids dream of encrypted sheep dept.

With [this commit](http://marc.info/?l=openbsd-cvs&m=140587954802314&w=2), Mike Larkin (mlarkin@) has added support for hibernating to encrypted [softraid(4)]() devices. This is what he had to say when asked about it:

> After RLE support (which went in in Slovenia), the next thing on the list to tackle was softraid crypto. Theo provided the initial idea on how to get the block transforms and crypto bits working over lunch one day in Slovenia and after about three or four days of on-and-off hacking this week, we had it working.

> For those new to hibernate, one of the key challenges is to keep the machine as idle as possible while snapshotting/writing out the memory image. In order to do this, one of the things you need is an I/O write routine that is completely side-effect free (or at least whose side-effects are constrained to known locations). Obviously, if the I/O routine is making changes in memory as the image is being written out, that's not good. This means no memory allocations, no spl*/splx, no printfs, etc, can occur during image write. We have had ahci and pciide/wd side-effect free routines in the tree for some time now.
>
> One difference with softraid though is that now we need two side-effect free I/O functions - one for softraid itself and one for whatever disk controller happens to be serving the volume containing the softraid paritions (eg, ahci/wd). Since those inner I/O routines expect their own block biasing, there needed to be some adjustment to the block numbers that get passed down through the stack. And with softraid crypto, if you get the block number wrong, you mess up the encryption which leads to an unrestorable image. Much was learned in how to do this the easy way by looking at the softraid crypto boot loader code, and indeed this is how we modeled the hibernate softraid crypto code in the end.
>
> The performance of the implementation is probably not as good as it could be as presently we are processing a disk block at a time. With more scratch pages available to the routine, we could batch as many as 8 blocks at once to be sent down to the underlying I/O routine. We'll probably revisit that some day as part of an overall improvement in the hibernate write path performance (which with the recent addition of RLE is really not bad anymore)

g2k14: Ingo Schwarze on manly stuff **

undeadly.org — 2014-07-27 09:42:56

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140721090411

Contributed by [jj](http://www.inet6.se) on Mon Jul 21 08:32:55 2014 (GMT)
from the runs the ministry of propaganda dept.

> In the week right before the hackathon, I have done quite a bit of work cleaning up mandoc(1) warning and error messages. The goal is to provide more, more precise, and more readily understandable information to the user, in particular mentioning in the messages which section titles, macro names, and arguments each individual message is related to, and which workaround or fallback mandoc(1) has chosen, if any.

> Also, I'm trying to use descriptive rather than imperative style wherever possible and unify the wording for similar issues. Some messages clobbering together unrelated kinds of issues were split, some bogus messages deleted, some overblown ones downgraded, in some cases from FATAL to a mere WARNING. In the process of looking at almost all messages, I fixed more than a dozen parsing and formatting bugs along the way, and i started providing regression tests for messages, cleanly integrated into the well-known OpenBSD /usr/src/regress/usr.bin/mandoc/ regression suite. This cleanup is not quite complete yet, but the bulk of the work has been done, maybe about 75% so far.

On the OeBB Eurocity train to Ljubljana, I already started working on man.cgi(8), the CGI interface to search and display manual pages on the web, upgrading the old Berkeley DB version rotting in the mdocml.bsd.lv tree to use the new mandoc 1.13 SQLite backend we have in OpenBSD, so I could commit a first working version to bsd.lv on the first morning in Ljubljana.

After simplifying the server directory structure, the manpath.conf configuration file format, and the URI scheme, I imported the source code into the OpenBSD tree and continued development there. The main user-visible progress this week is to cleanly distinguish between man(1) and apropos(1) mode. In man(1) mode, which is the default, we now always show an actual manual page, in addition to links to other pages of the same name, if any. The search form was polished using feedback from Bob Beck@ and others. Besides, there were lots of small improvements behind the scenes:

A full rewrite of the man.cgi(8) manual that is now also used online; a cleanup of error reporting; a reasonable default for .Os; getting rid of pointless run-time configuration, using minimal compile-time configuration instead; getting back closer to the classical URI scheme; always including manpath= when printing queries, and omitting empty parameters; and a compatibility hack for the old OpenBSD "manpath=OpenBSD" query parameter format. Thanks also to Ted Unangst (tedu@) for finding the time to send two bugfix patches for man.cgi(8) among all his other work.

There is an old saying that hackathons are ideal for either starting work on a new task, to be polished afterwards, or getting an old one finished that was started long before. The man.cgi(8) replacement is one of the rare examples where a task was started right on the voyage to the hackathon *and* finished before the end of it, including deployment of the less-than-five-days-old software in production on http://mdocml.bsd.lv/cgi-bin/man.cgi and even on http://www.openbsd.org/cgi-bin/man.cgi.
And by the way, using queries like
http://mdocml.bsd.lv/cgi-bin/man.cgi?manpath=4.4BSD-Lite2&apropos=1&query=Xr%3Dinet
you can now run semantic searches on the original CSRG 4.4BSD-Lite2 manual pages!

Partly in parallel to that, but mostly after man.cgi(8) was in production, I picked up the pod2mdoc(1) utility http://mdocml.bsd.lv/pod2mdoc/ that Kristaps@ Dzonsons recently wrote in one of his characteristic flurries of extraordinary creativity. To help Anthony J. Bentley@ getting started with the LibReSSL manual conversion form perlpod(1) to mdoc(7), i pushed a pod2mdoc-0.0.12 release out of the door, and he promptly updated his port in the OpenBSD tree. He then started using the tool in practice, converting many manual pages, doing considerable manual postprocessing on each of them, and reporting lots of bugs and feature requests with respect to the tool.

I couldn't quite keep up with his pace, but some stuff got done by now: during the hackathon, correct handling of filename extensions and better rendering of B, and right after the hackthon multiple fixes regarding the handling of POD commands and formatting codes and the spacing around them in general, substantially redesigning some of the internal interfaces in pod2mdoc.c. During the hackathon, I also started a regression suite for pod2mdoc(1). That work led to the pod2mdoc-0.0.13 release today, on July 19.

The low version number still makes sense, there is much to do still to polish this tool and add missing functionality, in particular heuristics for guessing how various kinds of text ought to be marked up, to make manual postprocessing less painful.

As usual, various other bits and pieces got addressed during the
hackathon:

>
> * The whatis(1) utility now correctly matches words instead of any
substrings. This helps man.cgi(8), but is also nice for the
stand-alone command line version.

> * The security(8) utility no longer complains when /etc/exports
does not exist - it is now optional. Thanks to Antoine
Jacoutot (ajacoutot@) for the bug report.

> * Together with Theo (deraadt@), i have cleaned up the format
of the file /etc/mtree/4.4BSD.dist to make it more readable.
All in all, g2k14 was an exceptionally focused and productive hackathon for me. Having a familiar and very well-organised venue helped a lot (thanks Mitja!). I didn't spend a lot of time in the city this year, but that doesn't matter much because I have seen and enjoyed some of it during s2k11. Well, I did find the time to have a stroll to the Golovec Hill http://sl.wikipedia.org/wiki/Golovec with Rapha@el Graf, which was a very nice conclusion of a great event.

g2k14: Jasper Lievisse Adriaanse on bootloader hacking **

undeadly.org — 2014-07-27 09:42:56

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140719134058

Contributed by [jj](http://www.inet6.se) on Sat Jul 19 08:54:02 2014 (GMT)
from the master of puppets dept.

> This hackathon started out for me with my usual routine of fixing some bugs in Puppet, add more facts to Facter and dig into pkg-config.

> So started out in fixing an issue in Puppet where multi-flavored packages couldn't be updated and along the way I added support for the structured 'partitions' fact in Facter.
>
> A few weeks ago Stuart Henderson (sthen@) found several issues in pkg-config when it had to compare OpenSSL-like versions (1.0.1g > 1.0.1e). After I added the regress tests the issue was quickly fixed, a hackathon isn't complete for me without fixing at least one pkg-config issue..
>
> Most of the hackathon I've spent tidying the bootloaders MD parts and make certain functions MI which can be shared between bootloaders. This started out as a distraction from my work on the OpenBSD/octeon bootloader.
>
> Last year in Toronto I committed a collection of stubs for the bootloader, but I quickly ran into a misbehaving bootprompt. Both Paul Irofti (pirofti@) and myself couldn't quite figure out what was going on with the UART until Miod Vallat (miod@) helped to debug the issue; with that the bootprompt works reliably. We still cannot load a kernel yet, but most other parts (timeout, boot_info/boot_desc passing, root device decoding) are implemented. Next step would be to add support for loading a kernel off an internal CF card. One thing that Miod said about writing a bootloader quite stuck with me, it was along the lines of: "There's no beauty prize at the end and you only know what needs to be done when you're finished."
>
> Thanks again to Mitja for the great organization and setup.

g2k14: Sebastian Benoit on chasing down annoyances **

undeadly.org — 2014-07-27 09:42:56

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140719104939

Contributed by [jj](http://www.inet6.se) on Sat Jul 19 08:57:47 2014 (GMT)
from the running-tetris-as-root dept.

Sebastian Benoit (benno@) lets us know what he did to make his life easier at g2k14:

> For me the hackathon started before arriving in Ljubljana. On my trip I noticed that there was something wrong with my ssh connections: some did not work. So I started debugging in Munich Airport and the result was a quick fix for a recent bug in ssh-add.

> Very early on I asked reyk@ if we should try to get his long awaited filter rewrite for relayd commited. I had a list of problems i had noticed with it and when i got my hands on his most recent version I started to go through them. Some where already fixed and others were quickly corected. So after a day he was able to commit his big diff and further work on it commenced in the tree. I also added a port for relayd-updateconf, a tool written by Andre de Oliveira (andre@) that helps migrating to the new relayd.conf syntax.
>
> florian@ was sitting nearby and worked on merging ping and ping6, sending some diffs to me. He noticed the ping6 options for ipv6 node information queries and our support inside the kernel for answering them. We both thought that we didn't like that kind of information leakage and others agreed. As a result, rfc4620 support was removed from the kernel.
>
> I also worked on some other things and ideas that had been bugging me for some time, for example that conserver was running as the root without any need for it. With some feedback from sthen I updated the port. And I still have two other diffs waiting for oks.
>
> g2k14 was an awesome hackathon, and I really got to do some hacking without the distractions of normal life.

g2k14: Jonathan Gray on driver improvements for X **

undeadly.org — 2014-07-27 09:42:56

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140719082410

Contributed by tbert on Sat Jul 19 08:24:01 2014 (GMT)
from the closing-holes-by-closing-apertures dept.

Jonathan Gray (jsg@) writes in to let us know why he spent 30 hours in coach to be with us:

> One of the first things I did at g2k14 was import the Mesa update I've been working on for some time now. I've been tracking the Mesa git for a few months and submitting patches to reduce the amount of pain involved and given the local diff isn't too large anymore it seemed like a decent time to update. Shortly before the hackathon I ran into a problem getting Mesa to build on i386 however. It turns out there is an i386 only codepath that does a sysctl to check if SSE is enabled. This turned out to be a problem because sysctl.h pulls in uvm_extern.h which then pulls in a bunch of kernel headers including mutex.h which meant that Mesa's mtx_init() collided with the kernel's mtx_init(). Theo spent some time cleaning up the sysctl and uvm headers so they wouldn't include anywhere near as many definitions, and that work had already been committed when I arrived at the hackathon.

> The following day I did some xenocara builds to try and catch any additional problems. The problem I found was due to a symlink in the Mesa dist file that cvs import ignores, which was fixed by pointing the Makefiles to a different directory. I also double checked that LLVM enabled Mesa builds worked still worked via the LLVMpipe software renderer. Another problem the Mesa builds showed is that sys.mk the Makefile that gets automatically included by make adds CFLAGS to CXXFLAGS. As Mesa is a mixture of C that assumes C99 and C++ code, g++ ends up complaining that it gets the C specific -std=c99 flag passed to it. A diff to correct this in the system Makefiles and a few other places will be mailed out in future.
>
> I also looked into getting the src tree to build with OPENSSL_NO_DEPRECATED defined which in most cases involved adding includes that are not automatically pulled in by other includes anymore. For some things like nginx that are externally maintained there are patches already available in future versions that we'll eventually pick up so it doesn't seem worthwhile patching our version just yet when there are still other places in the tree (libkeynote/bind/sendmail etc) that need changes made. I also had a quick look at compiling with OPENSSL_NO_SSL_INTERN but after seeing how dc and gzsig broke when building I decided to look elsewhere.
>
> I looked into updating some clang patches I've had lurking around for a few years and committed some things relating to that.
>
> Xorg can now run without having to grant userland direct access to a window of kernel/device memory if kernel modesetting (KMS) is supported. The problem being other devices still need access to this window to run Xorg. The installer asks a question if it finds a vga device that enables the window via the machdep.allowaperture sysctl. After a discussion with a few people at g2k14 I created some small scripts to extract PCI vendor/product numbers from the radeondrm and inteldrm drivers which are used by the pci attachment of the vga driver to print a line to dmesg if the window will be needed to run Xorg. The installer has been modified by halex@ and rpe@ to check for this line and will only ask if the person installing intends to run X11 (which enables the window) if it is found. The X11 question will not be asked on many servers now as there is a blacklist of graphics devices commonly found in servers in the code that decides whether the aperture is needed.
>
> A problem I've run into a few times now is the lack of a cpuid.h header which is provided by gcc >= 4.3 and clang to provide an interface to calling cpuid on i386 and amd64. Mesa git now requires cpuid.h to build. The Intel Xorg driver disables codepaths involved in deciding if SSE is present and making decisions based on cache sizes if it missing. And at least some ports (ie OpenXCOM) seem to expect it now. So I've taken the cpuid.h from clang to include in our version of GCC 4.2.1. Initially I changed the SSE_4_1 and SSE_4_2 definitions to SSE_41 and SSE42 to match the names used by GCC but likely both definitions will be included when this gets committed.
>
> Many thanks to the OpenBSD Foundation and Mitja for making g2k14 possible.

g2k14: Paul Irofti on the long road to octhci(4) **

undeadly.org — 2014-07-27 09:42:56

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140718134017

Contributed by [tbert](http://www.openbsdfoundation.org/donations.html) on Fri Jul 18 14:02:38 2014 (GMT)
from the USB-cookery-for-one dept.

> I came to the hackathon with a single goal: working on the driver for the USB host controller interface found on the octeon machines.

> I knew mpi@ would attend the event so that was a big plus. That meant that I could always reach him and bug him about how the OpenBSD USB infrastructure works and what's expected of the octhci(4) driver in different scenarios. Which, as I expected, ended-up being quite often.
>
> I was pleasantly surprised when jasper@ asked me to share the serial to my DSR500 machine so that he could work on improving the boot(8) program that he started at t2k13. We had a lot of fun poking and discussing the different octeon issues that we ran into during the entire hackathon and people started referring to us as the octeon-team which was nice.
>
> Things started moving once I managed to put together and understand the different logic and taxonomy between the OpenBSD's USB layer, the Cavium SDK and the actual USB 2.0 specification.
>
> And so, I was confident enough to ask miod@ for permission to commit a work in progress driver. Now this stub of a driver was very powerful in that it managed to fry umass(4) devices immediately! So I made sure that it wasn't enabled by default and that the interrupt routine was disabled.
>
> The next step was to add proper bus and hub routines that allowed the root hub to attach without a panic. Which was kind of nice as the dmesg(8) grew a bit:
>
>
>
> octhci0 at iobus0 irq 56: core version 2 pass 3.5
> usb0 at octhci0: USB revision 2.0
> uhub0 at usb0 " octHCI root hub" rev 2.00/1.00 addr 1
> uhub0: cannot open interrupt pipe
> usb0: root device is not a hub
>
>
> Afterwards I moved on to fixing the attach errors by adding proper root hub interrupt routines and filling in more bits and pieces in the HCI interrupt. That allowed me to enable the HCI interrupt which improved things a bit:
>
>
>
> cthci0 at iobus0 irq 56: core version 2 pass 3.5
> usb0 at octhci0: USB revision 2.0
> uhub0 at usb0 " octHCI root hub" rev 2.00/1.00 addr 1
>
>
> I made further progress by slowly filling in the controller-specific bits from the hub routines. That meant providing proper hub descriptors, getting and setting port features and clearing USB requests.
>
> This lead to a build-up of immense confidence that in turn allowed me to convince myself that the time for a new device connection test was in-place.
>
> The excitement was high. mpi@ joined my table and provided me with a YubiKey device to test with. But that didn't actually happen as he quickly changed his mind in fear of the Great USB Frying God and so brought over in exchange some old .vantronix USB sticks that he was more willing to see destroyed than the former YubiKey.
>
> With trembling hands I connect the device and... the machine froze! I pulled it out and quickly connected it to my laptop to see if it still worked. It did! I was so happy!
>
> I quickly found the cause of the freeze and fixed it: the host port interrupt flag was not cleared by the HCI interrupt routine so that lead to an interrupt storm.
>
> Clearing the interrupt put the machine in the same state as before I started hacking on this driver: USB device connections had no effect (-:
>
> Well that's not entirely true because now the kernel was becoming aware of USB events and knew how to properly treat some of them. This also meant that I could plug and unplug devices at will and test without fear of loss!
>
> Following that, I started relaxing some overly-paranoid checks that I treated with immediate panics when true. They were put there since the dark-ages of the frying sticks and were actually wrong.
>
> I added more event handling in the interrupt routines along with proper acknowledgment. I also started keeping track of port connections and port resets so that I can notify the upstream USB layer when connection status changed and when port resets were done.
>
> I'm currently working on getting device control and transfer pipes rolling that will hopefully lead to a successful device attach.
>
> Developments really sped up once device connections started working but unfortunately the hackathon came to and end.
>
> The Ljulbjana hackathon was a great event that allowed me to accomplish and learn a lot for which I would like to thank Mitja (our awesome organizer), the OpenBSD Foundation and Theo de Raadt for their efforts of putting all of this together!

BSDNow Episode 046: Network Iodometry **

undeadly.org — 2014-07-27 09:42:56

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140718122429

Contributed by tbert on Fri Jul 18 10:26:59 2014 (GMT)
from the not-to-be-confused-with-YOLOmetry dept.

In this week's [episode](http://www.bsdnow.tv/episodes/2014_07_16-network_iodometry) of [BSDNow](http://www.bsdnow.tv/), they interview Brian Drury of FreeBSD, talk about Allan Jude's trip to Cambridge on BSD grounds, and teach you how to DNS your way out of a restrictive network.

**[** [MP3](http://feeds.feedburner.com/BsdNowMp3) **|** [OGG](http://feeds.feedburner.com/BsdNowOgg) **|** [Video](http://feeds.feedburner.com/BsdNowMobile) **|** [HD Video](http://feeds.feedburner.com/BsdNowHd) **|** [HD Torrent Feed](http://bitlove.org/jupiterbroadcasting/bsdnowhd/feed) **]**

EuroBSDCon 2014 Registrations Open **

undeadly.org — 2014-07-27 09:42:55

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140718101234

Contributed by [jj](http://bsdly.blogspot.com/) on Fri Jul 18 12:25:34 2014 (GMT)
from the more pufferfish in the water dept.

Registration for the EuroBSDCon 2014 is now officially [opened](http://2014.eurobsdcon.org/registration/).

This year's conference is in Sofia, Bulgaria, and the important dates are:

* 25-26 September _Thursday & Friday_ - Tutorials
* 27-28 September _Saturday & Sunday_ - Main conference
* 27 September _Saturday evening_ - Social event As you can see from [the program](http://2014.eurobsdcon.org/talks-and-schedule), OpenBSD is fairly well represented (generally one talk in each of three parallel tracks, plus tutorials).

[Sign up now](http://2014.eurobsdcon.org/registration/) for early bird rates!

g2k14: Brent Cook on the portable LibreSSL **

undeadly.org — 2014-07-27 09:42:55

undeadly.org -> All

http://undeadly.org/cgi?action=article&sid=20140718090456

Contributed by [phessler](http://www.inet6.se) on Fri Jul 18 08:54:45 2014 (GMT)
from the insane porting dept.

A new developer with the OpenBSD project, Brent Cook (bcook@) writes in:

> As unusual as it sounds for someone working with the OpenBSD project, I'm not primarily an OpenBSD user. I actually use a Mac and Linux equally, and even do fair amount of Windows development. Some might say my involvement was more of a survival of the fittest.

> After Heartbleed, licking the fresh wounds at my work of updating all-the-things, and being continually annoyed at the build process of OpenSSL, I decided to take a stab (apparently, among many others) at porting LibreSSL, posting the early results to GitHub.
>
> A few weeks go by and I suddenly see a lot of hits and referrals from the Insane Coding blog (after all, GitHub is great at helping you find your coding social network . What followed was a humbling experience, as I quickly learned to be suspicious of any and all portability code for other OSes.
>
> I continued developing the port, occasionally pushing fixes upstream to the OpenBSD project that removed some BSDisms that were creeping in. Some patches were easily accepted, others were summarily rejected, but nothing that I wasn’t used to. My first Linux kernel patch fixing duplicate file handling in procfs was rejected with 'Doctor it hurts when I do this'
>
> Fast forward to month ago while on vacation, and Theo starts emailing me suggestions about things to try in my port. Armed with just a pokey ARM Chromebook and third-world internet connectivity, I managed to start integrating what would become the getentropy(2) emulations and other improvements from the OpenBSD source tree, while my family was asleep. A short time after, I was invited to help work on the official port.
>
> Apparently, I was the only 'unofficial port' maintainer that had actually continued maintaining his port and had actually done an OK job with it.
>
> The hackathon was a whirlwind that accelerated throughout the week, as Bob and I went from nothing to an almost fully scripted integration and release system. We still have a lot of work to do, but it was rewarding getting the first couple of builds out the door and getting so much feedback.
>
> Look forward to many more interesting LibreSSL releases in the future! I certainly am looking forward to when I can replace OpenSSL with LibreSSL in my own projects. I will certainly be using OpenBSD a lot more from now on as well.