In another move that signals a new OpenBSD release is in the works, the OpenSSH project has released without fanfare its new version, OpenSSH 10.5.

The release notes read,

OpenSSH 10.5/10.5p1 (2026-08-11)

OpenSSH 10.5 was released on 2026-08-11. It is available from the
mirrors listed at https://www.openssh.com/.
OpenSSH is a 100% complete SSH protocol 2.0 implementation and
includes sftp client and server support.

Recently the OpenSSH team have received a large number of security
bug reports, many of which are findings from AI models or made with
AI assistance. While many AI reports are determined not to have
security impact when considered in the context of a realistic
threat model, we very much welcome these reports, especially when
combined with human triage, analysis, test-cases and particularly
when accompanied by proposed fixes.

A sure sign that a new OpenBSD will soon be ready is that a new OpenBGPD release appears. On August 6th, 2026, the project released OpenBGPD version 9.2.

The announcement reads,

List:       openbsd-announce
Subject:    OpenBGPD 9.2 released
From:       Claudio Jeker <claudio () openbsd ! org>
Date:       2026-08-06 13:22:26
Message-ID: anSKksatjxeom0lQ () diehard ! n-r-g ! com

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

This release includes the following changes to the previous release:

Returning readers of this site may have noticed that the pace of development in relayd(8) and httpd(8) has been picking up recently. Now Rafael Sadowski (rsadowski@) has a new blog post out titled Dead Software Walking: The ongoing evolution of relayd(8) and httpd(8) where he tells the story.

The article starts with

Start with WHY

As I mentioned in my OpenBSD 7.8 highlights post, development of relayd(8) and httpd(8) had stalled. Many diffs appeared on the tech@ mailing list from different contributors, but few were committed into the repository. The main reason was simple: Established OpenBSD developers weren’t interested in these daemons anymore. Call it momentum, or timing.

And he goes on to describe his motivation, and the numerous improvements that he and Kirill Korinsky (kirill@) added to those daemons once they got started.

Read the whole thing here: Dead Software Walking: The ongoing evolution of relayd(8) and httpd(8).

Thanks to the tireless work of among others Dave Voutila (dv@), development of the OpenBSD/amd64 virtualization system vmm(4)/vmd(8) continues to make progress.

Now breaking changes, but with with potential benefits in both process isolation and compartmentalization of functionality, are on the way. It almost goes without saying that this code needs testing.

In a message to the tech@ mailing list with the subject tests wanted: vmm(4)/vmd(8) fd-ification, Dave Voutila presents the code along with some explanation:

List:       openbsd-tech
Subject:    tests wanted: vmm(4)/vmd(8) fd-ification
From:       Dave Voutila <dv () sisu ! io>
Date:       2026-08-03 14:36:00
Message-ID: 87a4r3fezz.fsf () mars ! sisu ! io

Calling on vmm(4)/vmd(8) users to give this diff a test please!

This is a major breaking change I'm proposing to land soon. It changes
the vmm(4) design to create a new file type for each VM. When a VM is
created, the caller gets a new file descriptor for using ioctl(2) calls
against that VM.

Yes, you read that right. Modern development tools in the form of the LLVM compiler infrastructure is well on its way to supporting OpenBSD/sparc64 along with other more conventional architectures.

The support is now ready for testing, via a patch set presented by Kirill A. Korinsky (kirill@) in a message to the tech@ mailing list, with the subject LLVM toolchain for sparc64.

The message reads,

List:       openbsd-tech
Subject:    LLVM toolchain for sparc64
From:       Kirill A. Korinsky <kirill () korins ! ky>
Date:       2026-07-30 11:38:55
Message-ID: 87jyqcogfk.wl-kirill () korins ! ky

Folks,

I'd like to commit to devel/llvm/22 and gnu/llvm my cumulative patch for
support sparc64 by LLVM toolchain.

In a change likely to be widely welcomed, Rafael Sadowski (rsadowski@) committed support for custom HTTP headers in httpd(8). This obviates the need to use FastCGI support or relayd(8) to achieve things like adding SSL/TLS security headers.

The commit reads:

CVSROOT:	/cvs
Module name:	src
Changes by:	rsadowski@cvs.openbsd.org	2026/07/24 23:48:39

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

Log message:
httpd: add custom HTTP header support

Up until quite recently, relayd(8) did not actually support ECDSA keys and certificates, as described in the Relayd doesn't like ecdsa thread on the tech@ mailing list.

The problem is now solved.

In this commit by Rafael Sadowski (rsadowski@), code that originated in smtpd(8) adds the previously lacking support.

The commit message reads,

List:       openbsd-cvs
Subject:    CVS: cvs.openbsd.org: src
From:       Rafael Sadowski <rsadowski () cvs ! openbsd ! org>>
Date:       2026-07-20 17:41:07
Message-ID: 17bfa7826d307ce0 () cvs ! openbsd ! org

CVSROOT:	/cvs
Module name:	src
Changes by:	rsadowski@cvs.openbsd.org	2026/07/20 11:41:07

Modified files:
	usr.sbin/relayd: ca.c relay.c relayd.h ssl.c 

Version 0.127 of Game of Trees has been released (and the port updated). Complete release notes are as follows:

OpenBSD is moving closer to adding WPA3 support.

Stefan Sperling (stsp@) posted a message with the subject add WPA3 support to the tech mailling list with a patch that implements WPA3 in OpenBSD's net80211 subsystem including ifconfig(8), asking for testing and feedback.

He also noted that this effort is supported by the NLNet Foundaton (as noted in an earlier article).

The message reads,

List:       openbsd-tech
Subject:    add WPA3 support
From:       Stefan Sperling <stsp () stsp ! name>
Date:       2026-07-18 11:40:08
Message-ID: altmGGN9mVtJ1Eqd () yumyan ! stsp ! name

The patch below adds support for WPA3 to the net80211 subsystem.

This effort is supported by the NLnet Foundation's NGI0 Commons Fund.
Without such support, I would not have been able to invest the time
required to work on this. I am very grateful to be given this opportunity.