Veteran OpenBSD developer Miod Vallat (miod@) has written another deep dive article on porting our favorite operating system to a new platform and maintaining the code, this time the OpenBSD/hppa platform.

The piece titled The scariest boot loader code certainly lives up to the title!

If you're the right type of person, you will know to set aside a goodly chunk of time for this piece.

The OpenBGPD project have announced their new release, OpenBGPD 9.0.

The announcement reads,

List:       openbsd-announce
Subject:    OpenBGPD 9.0 released
From:       Claudio Jeker <claudio () openbsd ! org>
Date:       2025-12-30 13:23:11

We have released OpenBGPD 9.0, which will be arriving in the
OpenBGPD directory of your local OpenBSD mirror soon.

This release includes the following changes to the previous release:

    * Rewrite the Adj-RIB-Out handling to be more memory efficent
      and faster. For large IXP route server deployments a reduction
      in memory usage of more than 50% should be feasible.

    * Process UPDATE messages in two phases: first update Adj-RIB-In,
      Loc-RIB, and FIB, then process all the Adj-RIB-Out tables.
      This significantly reduces the latency since updating all the
      Adj-RIB-Out tables could take a fair amount of time.

    * Introduce CH hash tables - a scalable hash map implementation
      that boosts performance through improved cache locality.

    * Introduce new metrics that track the amount of time spent in
      various parts of the main event loop of the route decision engine.

    * Fix various non-criticial things uncovered by Coverity scanner.

Thanks to a commit by Andrew Hewus Fresh (afresh1@), fw_update(8) now checks the output of [runtime] dmesg(8) in addition to the [boot-time] file /var/run/dmesg.boot. The commit message explains the rationale:

CVSROOT:	/cvs
Module name:	src
Changes by:	afresh1@cvs.openbsd.org	2025/12/26 11:19:46

Modified files:
	usr.sbin/fw_update: fw_update.sh fw_update.8 

Log message:
Scan both dmesg.boot and dmesg(8) output for devices

This allows us to detect newly plugged in devices that need firmware
added while still making sure to detect devices available at boot
even if dmesg rolls over with noisy messages.

fixes and ok kn@
I think this is good deraadt@

In a fascinating retrospective titled The story of Propolice, longtime OpenBSD developer Miod Vallat (miod@) tells the story of the early stack protection work on OpenBSD.

This is also part of the early history of OpenBSD development, when Miod relates that the project

starts switching its mindset from ``our work is to make the code bug-free'' to ``in addition to making the code bug-free, we should make exploitation as difficult as possible''.

The article provides fair measure of detail about how the OpenBSD developers made the Propolice mechanism portable across all supported architectures (including the now-retired OpenBSD/vax).

As the article notes, the name Propolice is no longer commonly used, but it denotes an important step in the efforts to make OpenBSD and other systems run on secure and correct code.

The full article, titled The story of Propolice, is well worth your time for filling in gaps in the history of our favorite codebase.

OpenBSD developer Job Snijders (job@) has updated the rpki-client website to indicate the OpenBSD-associated project needs to raise [a total of] €300,000 before the start of 2026 to continue work.

If your company uses rpki-client, please consider working to arrange a donation!

In -current, Theo de Raadt (deraadt@) has started the transition to support for 52 disk partitions (on a subset of hardware architectures):

CVSROOT:	/cvs
Module name:	src
Changes by:	deraadt@cvs.openbsd.org	2025/11/13 13:59:14

Modified files:
	sys/dev/ata    : wd.c 
	sys/kern       : kern_pledge.c 
	sys/sys        : disklabel.h dkio.h 
	sys/scsi       : sd.c 
	sys/dev/isa    : fdreg.h 
	sys/arch/sparc64/dev: fd.c 

Log message:
Begin transition to 52-partition support.  The partition encoding used
to be lowest 4 bits of dev_t, and now becomes 6.  This supplies 64
partitions in struct disklabel.d_partitions[MAXPARTITIONSUNIT], but we
only use 52 of these slots (an architecture can be either 16 partition
or 52 partition, depending on MD define MAXPARTITIONS).  The
52-partition limit is due to single-character representation limit of
a-zA-Z.  We supply a backwards-compat ioctl for a while which can read
an disklabel structure.

David Gwynne (dlg@) has introduced source and state limiters, which provide a massive increase in the flexibily of pf traffic limiting:

CVSROOT:	/cvs
Module name:	src
Changes by:	dlg@cvs.openbsd.org	2025/11/10 21:06:20

Modified files:
	sbin/pfctl     : parse.y pfctl.8 pfctl.c pfctl_parser.c 
	                 pfctl_parser.h 
	share/man/man5 : pf.conf.5 
	sys/net        : pf.c pf_ioctl.c pf_table.c pfvar.h pfvar_priv.h 

Log message:
introduce source and state limiters in pf.

both source and state limiters can provide constraints on the number
of states that a set of rules can create, and optionally the rate
at which they are created. state limiters have a single limit, but
source limiters apply limits against a source address (or network).
the source address entries are dynamically created and destroyed,
and are also limited.

Several recent commits have improved sysupgrade(8) handling of low free disk space in /usr:

Firstly, Stuart Henderson (sthen@) modified the installer to increase free space prior to installing:

CVSROOT:	/cvs
Module name:	src
Changes by:	sthen@cvs.openbsd.org	2025/11/01 06:54:17

Modified files:
	distrib/miniroot: install.sub 

Log message:
Before extracting on an upgrade, remove share/relink/*, not just
share/relink/usr/lib/*. The old files aren't useful post-upgrade and
this increases the chance of successfully extracting base*.tgz files,
so that people low on space in /usr have a better chance of getting
into the system after a reboot.

"install.sub can delete the entire relink space" deraadt@

Following the previous reverted attempt [see earlier report], Robert Nagy (robert@) committed VA-API [hardware-assisted video - see previous report] support to the chromium and ungoogled-chromium ports. The iridium port can be expected to follow on next update.

Note that:

• Updated (binary) packages are not yet available at the time of writing.
• Intel GPUs requires ports graphics/intel-media-driver [and/]or graphics/intel-vaapi-driver.