(Open) Widevine support added to the chromium port In a move likely to be welcomed by users of streaming
video services,
Robert Nagy (
robert@)
has
added a
port for
OpenWV (a free and
open-source reimplementation of
Google's Widevine
CDM),
and
enabled
its use with the chromium port:
undeadly rss
On our favorite operating system and its siblings, that special case has been handled via the
But that special case has always felt a bit awkward to some, and now David Gwynne (
In the message titled pf: make af-to less magical, David explains the motivation,
af-to option and special case rules since back in the OpenBSD 5.1 days.
dlg@) is airing a patch on tech@ with a view to making af-to "less magical".
List: openbsd-tech
Subject: pf: make af-to less magical
From: David Gwynne <david () gwynne ! id ! au>
Date: 2026-01-16 2:11:57
Message-ID: aWmebWvdwBi6z98j () animata ! net
i only recently figured out that af-to is very special in pf, but i dont
think it should be.
currently af-to has the following restrictions:
1. it only works for incoming packets, ie, you can only use it on "pass
in" rules in pf.
2. it forces the translated packet to be forwarded.
a consequence of these, and 2 in particular, is that only one state is
created for an af-to connection over the firewall. this is unlike other
forwarded connections where there's generally two states created, one
when the packet comes in from the wire into the stack, and another when
the packet goes out from the stack to the wire.
OpenBSD-current now runs as guest under Apple Hypervisor
The commits read
helg@) and Stefan Fritsch (sf@), OpenBSD/arm64 now works as a guest operating system under the Apple Hypervisor.
List: openbsd-cvs
Subject: CVS: cvs.openbsd.org: src
From: Helg Bredow <helg () cvs ! openbsd ! org>
Date: 2026-01-12 18:15:33
CVSROOT: /cvs
Module name: src
Changes by: helg@cvs.openbsd.org 2026/01/12 11:15:33
Modified files:
sys/dev/pv : viogpu.c
Log message:
viogpu_wsmmap() returns a kva but instead should return a physical
address via bus_dmamem_mmap(9). Without this, QEMU would only show a
black screen when starting X11. On the Apple Hypervisor, the kernel
would panic.
MAXCPUS on OpenBSD/amd64-current is now 255
The first commit message reads,
mlarkin@) set the stage for, and next up, bumped the maximum number of processors supported on OpenBSD/amd64 from 64 to 255.
List: openbsd-cvs
Subject: CVS: cvs.openbsd.org: src
From: Mike Larkin <mlarkin () cvs ! openbsd ! org>
Date: 2026-01-14 21:25:26
CVSROOT: /cvs
Module name: src
Changes by: mlarkin@cvs.openbsd.org 2026/01/14 14:25:26
Modified files:
sys/arch/amd64/amd64: pmap.c
Log message:
Support more than 64 bits for amd64 TLB shootdown IPI masks
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.
LACP mode removed from trunk(4) David Gwynne ( David also added an
entry
to the "Following current" FAQ
with additional details
and an example of migration to
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
aggr(4).