26/08/06 ⇒ OpenBGPD 9.2 released 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. https://undeadly.org/cgi?action=article;sid=20260807061435 https://www.openbgpd.org/

@CiotBSD OT = off topic

Thanks to everyone who pointed out Linux. Now that I'm paying attention this is clearly the systemd startup logging.

tl;dr I used wg(4), pf(4), and relayd(8), all OpenBSD native tools, to encrypt all inbound connections from a gateway VPS to my local home server. This also hides my local IP information and I managed it all without much hassle and pain. I recently stood up a VPS running OpenBSD 7.9 on Vultr. The VPS is hosted in Chicago, Illinois, USA. I then took OpenBSD's native WireGuard driver, wg(4), to establish an encrypted tunnel to my local home lab server. Using relayd(8), OpenBSD's native reverse proxy, I can now forward virtual host connections to my home lab server, which has httpd(8) as a web server frontend. I used pf.conf(5) to configure OpenBSD's native fireweall, pf(4), which was incredibly easy. The result is a secure gateway that routes all traffic via WireGuard to my local server, obfuscating its location and other IP information. This was done by simply configuring handful of system daemons. I've done some OpenBSD network configuration before, but this was the most work I've done. The best part, it wasn't that difficult, and all manual pages provided sufficient details to work with them. Once I get my site set up I'll write up the experience and step-by-step instructions and share the page here. New OpenBSD milestone unlocked; no intent to stop anytime soon Happy hacking, hackers!

@phessler FYI

@naltun said: tyvm ??? Hummm, maybe: "Thank you very much", isn'it?!

What title says More info here: https://github.com/outpaddling/desktop-installer/issues/30#issuecomment-4835472901

Hi! So I have a small VPS with OpenBSD on it and I anticipate that disk space will not be enough, so my question is, if I know that I will never compile the whole system from source, can I just repurpose the space allocated to /usr/obj and /usr/src and mount those partitions where they're needed? Or is this a really really bad idea? It would free up about 10GB (out of 40GB total).

Port knocking is mostly a bad idea. But people keep wanting to do it, for some false sense of security. If you don't consider it a security control but a way to keep garbage out of your logs, it might be valid. In my case I'm using an old USG Pro 4 running OpenBSD as my firewall and I'd prefer to avoid writing stuff to the logs, as I'd prefer the flash not to wear out sooner than needed, definitely not thanks to background radiation on the internet. https://dgl.cx/2026/06/ssh-port-knocking-with-openbsd

Sharing this [1] link as I dive into amd64 assembly programming on OpenBSD (it really came in handy!). This [2] Reddit thread also helped me understand the elf(5) requirements for programming assembly on OpenBSD. Happy hacking! [1] https://astharoshe.net/2020-06-28-Hello_assembler.html [2] https://www.reddit.com/r/openbsd/s/JN0hTLNKQF e: typo

@grahamperrin said: … The code originated from FreeBSD, which itself derived it from Cronyx Engineering Ltd.'s implementation written by Serge Vakulenko in 1994-1996. … I assume that FreeBSD is not affected. Surely (!?) But I dont known!

⇒ OpenBSD under QEMU Architecture specific notes for OpenBSD guests under QEMU, with working command lines where installation succeeds and failure points where it does not. https://kirill.korins.ky/articles/openbsd-under-qemu/

(06/10) ⇒ A Final Return for OpenBSD Anti-Return-Oriented Programming Mitigations Return-Oriented Programming (ROP) continues to be a serious attack taking advantage of flaws in memory unsafe languages, particularly buffer overflows, to launch arbitrary code execution attacks by chaining together pieces of already existing code in loaded binaries and shared libraries, called gadgets. With the continued reliance on x86_64 CPUs in cloud and personal servers, mitigations that can meaningfully reduce the success of ROP attacks without significant overhead continue to be attractive. We propose the porting of one such software-based anti-ROP mitigation proposed by OpenBSD: compile-time instruction rewriting to avoid opportunities for ROP exploitation. We bring this mitigation, originally developed for the custom OpenBSD implementation of the LLVM compiler suite, to GCC by way of a standalone utility that sits in between the compiler and the assembler and rewrites potential gadget instructions before assembly into object code. Our utility provides a minimal reduction in gadgets with some penalties in binary sizes and performance impacts. We compare our GCC-ported standalone utility to the original OpenBSD LLVM mitigation and discovered that our standalone utility is weaker compared to the original LLVM-based mitigation. However, due to the overall weak reduction in gadgets for both the LLVM-based and GCC-based implementations, we conclude that seemingly obvious mitigations may prove to be anything but, and caution providing security improvements without significant testing and evaluation. https://www.researchgate.net/publication/405728967_A_Final_Return_for_OpenBSD_Anti-Return-Oriented_Programming_Mitigations ping: https://bsd.network/@bcallah/116725877009964245 It seems to be my 200th post here…

(06/10) ⇒ OpenBSD stories—Trojaned OpenSSH This is a story I had been considering writing for a long time, as many wrong or stupid things have been said or written at the time it happened. Being on a quite sensitive subject, I have however opted to redact a few things, especially the identity of two OpenBSD developers, as well as some IP addresses and other minor details which could help identify them. They will be referred to as dev1 and dev2 in this story. It does not matter who they are, and they really are trustworthy. http://miod.online.fr/software/openbsd/stories/trojan.html Very interesting! Pleaseant to read…

@Jan ohhh, interesting! The only question left is whether it's possible to install it from Fuguita. At the very least, this should let you know which devices are being detected correctly.

The problem is this, and this will always be the answer a member gives you: if the port doesn't exist, create it; otherwise, do without it until someone else does it someday—if ever. That sets the tone; if that's okay with you, great… As you can see on: https://www.openbsd.org/mail.html ports@openbsd.org (Archive) Discussions about using and contributing to the ports tree. (Archive: https://marc.info/?l=openbsd-ports) Browse the archive and you'll see…

Thanks for sharing, I will need this soon!

I came across this [1] nice post detailing how to customize the ksh(1) experience. I came for the tab completions but it has some general ksh wisdom. Sharing it as ksh(1) is the default shell on OpenBSD and it's a great shell in general. [1] https://www.vincentdelft.be/post/post_20210102

[image: 1779402791145-3d230b19-00a3-4225-8320-d2fa5e496ccf-image.jpeg] Reporting Lumina as functional and in a good state. At least for the default locale.