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.

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!

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) **]**

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!

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.

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.

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.

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<blank>" 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<NULL>, 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.

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)

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.

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!

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.

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
>

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!

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.

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!

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!

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) **]**

CVSROOT: /cvs
Module name: src
Changes by: jsing@cvs.openbsd.org 2014/07/25 08:04:51

Modified files:
lib/libssl/src/crypto/chacha: chacha.h
lib/libssl/src/crypto/poly1305: poly1305.h

Log message:
Add missing year to copyright.

CVSROOT: /cvs
Module name: src
Changes by: reyk@cvs.openbsd.org 2014/07/25 09:47:11

Modified files:
usr.sbin/httpd : httpd.conf.5 parse.y

Log message:
Add and document 'root' configuration option for the docroot.

CVSROOT: /cvs
Module name: src
Changes by: schwarze@cvs.openbsd.org 2014/07/25 10:06:19

Modified files:
usr.bin/mandoc : cgi.c

Log message:
Rewrite http_parse() completely:
1. Make sure the last occurrence of each key is used, even if
it is empty, in which case it resets the value to the default.
2. When there is an HTTP encoding error, skip the affected
key-value pair only, but not all subsequent key-value pairs.
3. Do not modify a string returned from getenv(3).
4. Do not assume the NULL pointer is all null bits.

CVSROOT: /cvs
Module name: src
Changes by: reyk@cvs.openbsd.org 2014/07/25 10:23:19

Modified files:
usr.sbin/httpd : config.c httpd.c httpd.h parse.y server.c
server_http.c

Log message:
Add support for "virtual hosts" aka. server blocks aka. multiple
servers with the same or "overlapping" IP address but a different name.

ok beck@

CVSROOT: /cvs
Module name: src
Changes by: schwarze@cvs.openbsd.org 2014/07/25 10:43:05

Modified files:
usr.bin/mandoc : cgi.c

Log message:
clean up pg_show() to not modify a string returned from getenv(3)

CVSROOT: /cvs
Module name: src
Changes by: schwarze@cvs.openbsd.org 2014/07/25 10:55:40

Modified files:
usr.bin/mandoc : cgi.c

Log message:
The names of all other struct query memebers match the corresponding
QUERY_STRING keys, so rename "expr" to "query".
Also add some missing function prototypes.
No functional change.

CVSROOT: /cvs
Module name: src
Changes by: reyk@cvs.openbsd.org 2014/07/25 11:04:47

Modified files:
usr.sbin/httpd : parse.y

Log message:
Add a single line to fix the address matching of multiple server blocks with
non-virtual hosts. I had this line in a previous diff.

CVSROOT: /cvs
Module name: src
Changes by: schwarze@cvs.openbsd.org 2014/07/25 11:33:51

Modified files:
usr.bin/mandoc : cgi.c

Log message:
Even though this is not XHTML yet, remove some gratuitious violations
of XHTML syntax. Also add some cosmetic newlines to the HTML code.

CVSROOT: /cvs
Module name: src
Changes by: jasper@cvs.openbsd.org 2014/07/25 11:36:32

Modified files:
distrib/sets/lists/base: md.octeon

Log message:
fix perl5 architecture name

ok deraadt@

CVSROOT: /cvs
Module name: src
Changes by: reyk@cvs.openbsd.org 2014/07/25 11:49:11

Modified files:
usr.sbin/httpd : httpd.conf.5

Log message:
Add multiple-servers "virtual hosts" example.

CVSROOT: /cvs
Module name: src
Changes by: schwarze@cvs.openbsd.org 2014/07/25 11:51:33

Modified files:
usr.bin/mandoc : cgi.c

Log message:
In generated .Xr links, avoid double encoding of ampersands
and avoid empty arch= keys.

CVSROOT: /cvs
Module name: src
Changes by: schwarze@cvs.openbsd.org 2014/07/25 12:19:33

Modified files:
usr.bin/mandoc : cgi.c

Log message:
We cannot easily control the order of the QUERY_STRING keys generated
by the search form, it's just the order of the fields in the form.
Actually, that's not too bad; the generated URI resembles the
generating form.

To minimize confusion for people looking at URIs, give the keys
in the same order when generating URIs for search listings and
search redirections, the latter being used instead of search
listings that would have only one single entry. Also, if the
manpath is the default, remove it form the generated URIs.

CVSROOT: /cvs
Module name: src
Changes by: schwarze@cvs.openbsd.org 2014/07/25 13:36:02

Modified files:
usr.bin/mandoc : cgi.c

Log message:
oops, we must not try to validate a manpath we don't have;
fixing an oversight introduced in rev. 1.17

CVSROOT: /cvs
Module name: src
Changes by: schwarze@cvs.openbsd.org 2014/07/25 14:08:49

Modified files:
usr.bin/mandoc : cgi.c

Log message:
Sort the URI keys for .Xr links in the same order used by the search form,
and leave out the manpath when it is the default.
For building the HTML formatter options, do not use a static buffer.

CVSROOT: /cvs
Module name: src
Changes by: reyk@cvs.openbsd.org 2014/07/25 14:13:06

Modified files:
usr.sbin/httpd : server_file.c

Log message:
Don't leak docroot in the error message if the default index file is missing.

OK florian@

CVSROOT: /cvs
Module name: src
Changes by: schwarze@cvs.openbsd.org 2014/07/25 15:05:38

Modified files:
usr.bin/mandoc : cgi.c

Log message:
Choosing the right encoding is a tricky business...

Printing query strings for URIs *always* needs URI-encoding, and when
embedding the URI into an HTML document, it needs replacement of
the "&amp;" separators by "&amp;amp;" *in addition to that*, not instead.
Delete the function html_primtquery(), it was completely wrong.

You can see the badness by entering "mandoc &amp;sec=2" into the query input
box before this patch and click "Submit". You come to the right page at
first (...man.cgi?query=mandoc+%26sec%3D2&amp;apropos=0&amp;sec=0&amp;...), but now
the link to mandoc(1) is wrong: ...mandoc.1?query=mandoc &amp;amp;sec=2&amp;amp;...
Clicking on that, the "&amp;sec=2" disappears from the query input box and
suddenly you have the first dropdown set to "2 - System Calls". Oops.

CVSROOT: /cvs
Module name: src
Changes by: dtucker@cvs.openbsd.org 2014/07/25 15:22:03

Modified files:
usr.bin/ssh : ssh-agent.c

Log message:
Clear buffer used for handling messages. This prevents keys being
left in memory after they have been expired or deleted in some cases
(but note that ssh-agent is setgid so you would still need root to
access them). Pointed out by Kevin Burns, ok deraadt

CVSROOT: /cvs
Module name: src
Changes by: reyk@cvs.openbsd.org 2014/07/25 15:29:58

Modified files:
usr.sbin/httpd : httpd.c httpd.h server_file.c server_http.c

Log message:
Canonicalize the request path once without the docroot and prepend the
docroot only only when it's needed. Suggested by deraadt@.

CVSROOT: /cvs
Module name: src
Changes by: reyk@cvs.openbsd.org 2014/07/25 15:36:37

Modified files:
usr.sbin/httpd : server_http.c

Log message:
New HTTP/1.1 RFC 7231 prefers IMF-fixdate from RFC 5322.

CVSROOT: /cvs
Module name: src
Changes by: reyk@cvs.openbsd.org 2014/07/25 15:48:05

Modified files:
usr.sbin/httpd : server_http.c

Log message:
Append mandatory Date header to each response.

CVSROOT: /cvs
Module name: src
Changes by: reyk@cvs.openbsd.org 2014/07/25 17:23:39

Modified files:
usr.sbin/httpd : http.h httpd.h server.c server_file.c
server_http.c

Log message:
It is recommended to use a URL in the Location header of 3xx
responses. To accomplish this, add some semantics to retrieve the
server host name of a connection: either IP, IP:PORT (if not 80) or
[IP6]:PORT, or Host value (if valid).

CVSROOT: /cvs
Module name: src
Changes by: reyk@cvs.openbsd.org 2014/07/25 17:25:38

Modified files:
usr.sbin/httpd : server_http.c

Log message:
Reset the default Host for each request

CVSROOT: /cvs
Module name: src
Changes by: reyk@cvs.openbsd.org 2014/07/25 17:30:58

Modified files:
usr.sbin/httpd : config.c httpd.h server.c

Log message:
Differentiate servers by address and port, not just by address.

CVSROOT: /cvs
Module name: src
Changes by: tobias@cvs.openbsd.org 2014/07/26 01:48:49

Modified files:
usr.sbin/dhcpd : packet.c

Log message:
Fix very hard to reach DoS attack vector, which would involve more than
8 billion network packets. Mixture of many many malformed and proper
packets could result in a division by zero.

ok krw@

CVSROOT: /cvs
Module name: src
Changes by: reyk@cvs.openbsd.org 2014/07/26 03:59:15

Modified files:
usr.sbin/httpd : httpd.c

Log message:
bzero is over, memset is cool. pointed out by halex@

CVSROOT: /cvs
Module name: src
Changes by: reyk@cvs.openbsd.org 2014/07/26 04:27:19

Modified files:
etc/examples : httpd.conf

Log message:
Add more examples. Requested by deraadt@

CVSROOT: /cvs
Module name: src
Changes by: mpi@cvs.openbsd.org 2014/07/26 04:48:59

Modified files:
usr.sbin/apmd : apmd.c

Log message:
Revert "adjust -C algorithm to be more aggressive in scaling up" for
the moment, it triggers a race that breaks suspend/resume on some
machines.

ok tedu@, deraadt@, jsg@

CVSROOT: /cvs
Module name: src
Changes by: kettenis@cvs.openbsd.org 2014/07/26 10:07:39

Modified files:
sys/kern : kern_sched.c

Log message:
If we're stopping a secondary cpu, don't let sched_choosecpu() short-circuit
and return the current current CPU, otherwise sched_stop_secondary_cpus()
will spin forever trying to empty its run queues. Fixes hangs during suspend
that many people reported over the last couple of days.

ok bcook@, guenther@

CVSROOT: /cvs
Module name: www
Changes by: beck@cvs.openbsd.org 2014/07/26 12:25:42

Modified files:
libressl : index.html

Log message:
Nuke blink, add statement about OS provided intrinsics

CVSROOT: /cvs
Module name: src
Changes by: reyk@cvs.openbsd.org 2014/07/26 16:38:38

Modified files:
usr.sbin/httpd : server_file.c

Log message:
Remove redundant slash

CVSROOT: /cvs
Module name: ports
Changes by: landry@cvs.openbsd.org 2014/07/24 12:24:03

Modified files:
mail/mozilla-thunderbird: Makefile distinfo
mail/mozilla-thunderbird/patches:
patch-mail_installer_Makefile_in
patch-mozilla_js_src_configure_in
patch-mozilla_js_src_jscpucfg_h
patch-mozilla_storage_src_mozStorageConnection_cpp \

\
patch-mozilla_toolkit_components_downloads_nsDownloadManager_cpp
patch-mozilla_xpcom_io_SpecialSystemDirectory_cpp
mail/mozilla-thunderbird/pkg: PLIST-lightning PLIST-main
Added files:
mail/mozilla-thunderbird/patches:
patch-mozilla_gfx_skia_moz_build
\
patch-mozilla_gfx_skia_trunk_src_opts_SkBitmapProcState_opts_SSSE3_cpp \
patch-mozilla_media_libvpx_Makefile_in Removed files:
mail/mozilla-thunderbird/patches:
\
patch-mozilla_browser_components_certerror_content_aboutCertError_xhtm \
l
\
patch-mozilla_content_media_gstreamer_GStreamerLoader_cpp
\
patch-mozilla_ipc_chromium_src_base_debug_util_posix_cc
\
patch-mozilla_ipc_chromium_src_base_dir_reader_bsd_h
patch-mozilla_js_src_ctypes_libffi_configure
\
patch-mozilla_js_src_ctypes_libffi_src_x86_freebsd_S

Log message:
Update to thunderbird 31.0/lightning 3.3.

- See <a href="https://www.mozilla.org/en-US/thunderbird/31.0/releasenotes/" rel="nofollow">https://www.mozilla.org/en-US/thunderbird/31.0/releasenotes/</a>
- Fixes MFSA 2014-56-&gt;66 (except 60)
- Move i386 to build with gcc to be in sync with other mozillas
- Remove patch-mozilla_content_media_gstreamer_GStreamerLoader_cpp,
merged (#927898)
- Remove patch-mozilla_ipc_chromium_src_base_debug_util_posix_cc,
merged(#927810)
- Remove patch-mozilla_ipc_chromium_src_base_dir_reader_bsd_h, merged
(#909005)
- Remove patch-mozilla_js_src_ctypes_libffi_configure and
patch-mozilla_js_src_ctypes_libffi_src_x86_freebsd_S, merged (#928381)
- Add patch-mozilla_media_libvpx_Makefile_in for libvpx hack on
amd64/clang (#982693)
- Add patch-mozilla_gfx_skia_moz_build &amp;
patch-mozilla_gfx_skia_trunk_src_opts_SkBitmapProcState_opts_SSSE3_cpp
to fix build on i386 (#1028827)

Tested at least with 28.0b1, 30.0b1, 31.0b1 and 31.0b2 during this cycle..
and even starts on sparc64!

ok sthen@ jasper@ naddy@

CVSROOT: /cvs
Module name: ports
Changes by: landry@cvs.openbsd.org 2014/07/24 12:24:27

Modified files:
mail/thunderbird-i18n: Makefile.inc distinfo

Log message:
Update to thunderbird-i18n 31.0