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.

Omar Polo (op@) has announced that OpenSMTPD 7.8.0p0 has been released.

Read on for salient changes from the release announcement:

Brent Cook has announced that LibreSSL 4.1.2 and 4.2.1 have been released.

The release notes read:

Would it be useful for our system security to let daemons use the bpf(4) interface to filter on the sockets they handle?

In a recent message to tech@ titled bpf filtering on arbitrary sockets, Damien Miller (djm@) presents a preliminary patch and explains,

List:       openbsd-tech
Subject:    bpf filtering on arbitrary sockets
From:       Damien Miller <djm () mindrot ! org>
Date:       2025-10-30 5:03:00

Hi,

This is an idea that came up while talking with dlg@ about network
daemons.

Quite a few programs and daemons use SOCK_RAW to send link-level packets
after pledge(). E.g. usr.sbin/relayd/check_icmp.c wants to send ICMP
packets.

The problem with this is that, if they get compromised, they still hold
a very powerful socket that can send pretty much arbitrary packets. If
one of these programs gets compromised then the attacker can pretty
easily pivot through the existing raw socket.

As some readers tell us whenever they have the chance, the veb(4) virtual Ethernet bridge device is an OpenBSD feature that can make certain setups a lot more manageable than otherwise possible.

Now David Gwynne (dlg@) is fielding a patch on tech@ that would make veb(4) even more capable, by making the device vlan(4) aware.

In the message to tech@, David explains:

List:       openbsd-tech
Subject:    make veb(4) VLAN aware
From:       David Gwynne <david () gwynne ! id ! au>
Date:       2025-10-29 5:54:42

veb(4) is currently vlan unaware, meaning that it assumes that there's a
single "namespace" for the mac addresses used by packets handled by the
bridge. by default it blocks vlan (and svlan) packets, but if you allow
it carry vlan packets it ignores the vlan tag when doing the mac address
lookups.

adding vlan awareness means that every mac address the bridge learns
is now associated with a vlan identifier (vid). ie, the same mac
in two different vlans will get separate entries in the forwarding
database.