The rkpi-client project has made a new release, rkpi-client 9-7, available with important new features and bug fixes.

The announcement reads,

Subject:    rpki-client 9.7 released
From:       Sebastian Benoit <benno () openbsd ! org>
Date:       2026-01-13 21:05:05

rpki-client 9.7 has just been released and will be available in the
rpki-client directory of any OpenBSD mirror soon. It is recommended
that all users upgrade to this version for improved reliability.

rpki-client is a FREE, easy-to-use implementation of the Resource
Public Key Infrastructure (RPKI) for Relying Parties to facilitate
validation of BGP announcements. The program queries the global RPKI
repository system and validates untrusted network inputs. The program
outputs validated ROA payloads, BGPsec Router keys, and ASPA payloads
in configuration formats suitable for OpenBGPD and BIRD, and supports
emitting CSV and JSON for consumption by other routing stacks.

David Gwynne (dlg@) has removed LACP mode from the trunk(4) network driver. The commit message explains the reasoning:

CVSROOT:	/cvs
Module name:	src
Changes by:	dlg@cvs.openbsd.org	2026/01/11 21:38:15

Modified files:
	share/man/man4 : trunk.4 
	sys/conf       : files 
	sys/net        : if_trunk.c 

Log message:
remove lacp support from trunk(4)

lacp is better supported by aggr(4). users of lacp in trunk(4)
should migrate to aggr(4).

trunk(4) and the lacp support inside it is one of the last chunks
of code that still requires the netlock in the ethernet stack. the
last time i tried to fix this i ended up writing aggr(4), and nothing
about this code has improved since then. the other protos such as
failover and loadbalance are trivial in comparison and will be easy
to improve in the future.

discussed with and no objections from many

David also added an entry to the "Following current" FAQ with additional details and an example of migration to aggr(4).

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.