OpenBSD 7.5 released: Apr 5

[Theo de Raadt]

- OpenBSD 7.5 RELEASED -

April 5, 2024.

We are pleased to announce the official release of OpenBSD 7.5.
This is our 56th release.  We remain proud of OpenBSD's record of more
than twenty years with only two remote holes in the default install.

As in our previous releases, 7.5 provides significant improvements,
including new features, in nearly all areas of the system:

 - Various kernel improvements:
o Added bt(5) and btrace(8) support for binary modulo operator
  ('%').
o Added a TIMEOUT_MPSAFE flag to timeout(9).
o Added IBM encoded version of the "Spleen 8x16" font, usable as
  console font.
o Cleanup and machine-independent refactoring of three context
  switch paths outside of mi_switch(): when a process forks and the
  new proc needs to be scheduled by proc_trampoline, cpu_hatch: when
  booting APs, and sched_exit: when a proc exits.
o Made vscsi(4) 'vscsi_filtops' mpsafe and extended the
  'sc_state_mtx' mutex(9) to protect 'sc_klist' knotes list.
o Made out-of-swap checking more robust, preventing potential
  deadlocks.
o Eliminated the ioctl whitelist that bio(4) will tunnel for other
  devices, allowing bio to be used with other (non-raid) related
  devices.
o On msdos filesystems, ensure that a complete struct fsinfo is read
  even if the filesystem sectors are smaller.
o Implemented per-CPU caching for the page table page (vp) pool and
  the PTE descriptor (pted) pool in the arm64 pmap implementation.
  This significantly reduces the side-effects of lock contention on
  the kernel map lock and leads to significant speedups on machines
  with many CPU cores.
o Implemented acpi(4) RootPathString support in the LoadTable() AML
  function, fixing OpenBSD boot on an older version of Hyper-V.
o Fixed Linux NFS clients freezing after five minutes of inactivity.
o Fixed core file writing when a file map into memory has later been
  truncated to be smaller than the mapping.
o Disallow madvise(2) and msync(2) memory/mapping destructive
  operations on immutable memory regions. Instead return EPERM.
o Added new amd64-only sysctl machdep.retpoline which says whether
  the cpu requires the retpoline branch target injection mitigation.
o Added new accounting flag ABTCFI to acct(5) to indicate SIGILL +
  code ILL_BTCFI has occurred in the process.

 - SMP Improvements
o Some network timers run without kernel lock.
o TCP syn cache timer runs with shared net lock.
o bind(2) and connect(2) system calls can run in parallel.
o Packet counter for lo(4) loopback interface are MP safe.
o Split protocol control block table for UDP into IPv4 and IPv6
  tables to allow concurrent access.
o UDP packets can be sent in parallel by multiple threads.

 - Direct Rendering Manager and graphics drivers
o Updated drm(4) to Linux 6.6.19.
o New apldcp(4) and apldrm(4) drivers for Apple display coprocessor.

 - VMM/VMD improvements
o Fixed IRQ storm caused by edge-triggered devices such as the UART.
o Fixed block size calculation for vioscsi devices.
o Added io instruction length to vm exit information, allowing
  vmd(8) to perform validation in userspace.
o Adopted new imsg_get_*(3) api.
o Rewrote vionet devices to allow zero-copy data transfers between
  host and guest.
o Improved error messages related to getgrnam(3) usage and out of
  tap(4) device conditions.
o Fixed various things found by smatch static analyzer.
o Fixed various file descriptor lifecycle issues and leaks across
  fork(2)/ execve(2) usage.
o Added multi-threading support to vionet device emulation,
  improving latency.
o Fixed vmm(4) instability on Intel VMX hosts by updating GDTR & TR
  if vcpu moves host cpus.
o Added EPT flushing upon vmm(4) enabling VMX mode.
o Added branch predictor flushing if IBPB is supported.
o Corrected restoring GDTR and IDTR limits upon VMX guest exit.
o Corrected handling of CPUID 0xd subleaves
o Added additional use of VERW and register clobbering to mitigate
  RFDS vulnerabilities on Intel Atom cores.

 - Various new userland features:
o Made malloc(3) save backtraces to show in leak dump with depth of
  backtrace set via malloc option D (aka 1), 2, 3 or 4.
o Added support for cksum(1) -c checking base64 digests in reverse
  mode.
o Added kdump(1) [-p program] to filter dumps by basename.
o Made ps(1) accept numerical user IDs.
o Built and provide the tzdata.zi and leap-seconds.list files from
  zoneinfo. Some third-party software now expects these files to be
  installed. Provide the zonenow.tab file, a table where each row
  stands for a timezone where civil timestamps are predicted to
  agree from now on

Re: lcamtuf on the recent xz debacle

[Alexis]

Katherine Mcmillan  writes:

I have seen the following comment, or similar, in several 
articles now:

"On Friday, a lone Microsoft developer rocked the world when he
revealed a
backdoor
had been intentionally planted in xz Utils, an open source data
compression utility available on almost all installations of 
Linux and

other Unix-like operating systems."
https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/

There are a couple of problems with this statement, but I just 
want to
focus in on the "almost all installations of Linux and other 
Unix-like

operating systems" part.  From my understanding, it is certainly
almost all installations of Linux​, but the "and other Unix-like
operating systems" doesn't seem founded.  From what I 
understand, this
backdoor would not affect any flavour of *BSD, or of illumos for 
that
matter (ex. smartOS), or QNX, or Solaris.  Just for clarity, 
does
anyone know what "Unix-like operating systems" would be affected 
by

this?


The quoted passage states the platforms on which xz-utils is 
available; it doesn't explicitly say that all of those platforms 
are affected by this specific backdoor (though i acknowledge the 
passage can be read in a way that implies that). Indeed, not even 
all Linux platforms are affected: the backdoor specifically 
targets RPM- and DEB-based systems. In addition to the detailed 
writeup in Christian's message, there's also one by Russ Cox:


 https://research.swtch.com/xz-script

(Who has also put together a timeline: 
https://research.swtch.com/xz-timeline)


However, even though _this _particular backdoor_ only affects (a 
subset of) Linux platforms, there's the broader concern that the 
_project_ was 'socially' backdoored - a project involving a piece 
of software that's available for a wide variety of platforms, and 
relatively deep in a number of stacks. (Although, on the technical 
side, the versions of xz-utils since the malfeasant got involved, 
but prior to the confirmed-backdoored versions, are being looked 
at carefully.)



Alexis.

Re: lcamtuf on the recent xz debacle

[Christian Weisgerber]

Katherine Mcmillan:

> Just for clarity, does anyone know what "Unix-like operating systems"
> would be affected by this?

None.  TLDR: The build process of the backdoor explicitly aborts
on platforms other than Linux x86-64.

As the maintainer of the archivers/xz port, I took a look at the
build stages of the malicious code, because I had already prepared
an update to 5.6.1 and run the code in question.

Two ostensible test files were committed to the xz repository
immediately before the 5.6.0 release and updated immediately before
5.6.1: bad-3-corrupt_lzma2.xz, which as the name suggests is a
malformed compressed file, and good-large_compressed.lzma, which
is a valid file and extracts to a mixture of easily compressible
repeated characters and uncompressible pseudo-random data.  By
themselves those files are completely harmless.

As is common practice, the xz repository only contains input files
like configure.ac and Makefile.am for the GNU autotools.  For the
release tarball, an autotools run generates the actual configure
script, Makefile.in, etc., so the result can be built with "./configure
&& make".

For the 5.6.0 and 5.6.1 release, the build-to-host.m4 macro package
that ships as part of GNU gettext was replaced by a modified version
that was copied into the release tarball and, importantly, was used
to generate a modified configure script.  Let's call this stage 0.

When you run the configure script, the stage 0 shell snippet is
executed.  The malicious code runs a pipe of commands that reads
the bad-3-corrupt_lzma2.xz file, swaps some byte values to turn it
into a valid file, extracts the file with xz (which must already
be installed), and feeds the content--let's call it stage 1--into
a shell.

In 5.6.1, the stage 1 script will abort right away if the operating
system doesn't identify as "Linux" with uname(1).  The script runs
another pipe of commands that decompresses good-large_compressed.lzma,
picks some chunks of the result, replaces some byte values to turn
it into a valid LZMA data stream, extracts the content--let's call
it stage 2--and feeds it into a shell.  The data manipulation in
stage 1 uses the head(1) command with the "-c" command flag, which
isn't available on OpenBSD.

In 5.6.1 there is another early attempt in the stage 2 script to
verify that the operating system is Linux, however the syntax is
broken so it doesn't actually do anything.  The stage 2 script runs
quite a number of tests to ensure that the environment in which it
executes is the one it expects: details of the directory tree,
details of the files generated by configure, that the platform is
x86-64 Linux, that the compiler is gcc and the linker GNU ld, that
the IFUNC feature is available, that is runs as part of a .deb or
.rpm package build.  If any single one of those tests fails, the
script aborts right away.  If everything checks out, stage 2 again
runs a series of data manipulation commands to extract from
good-large_compressed.lzma two object files and injects them into
the build to generate a manipulated liblzma.  Various checks that
stage 2 performs will fail on OpenBSD and again it relies on
"head -c" and now also on the GNU version of sed(1) to perform the
required data manipulations.

For the actual code inserted into liblzma on Linux x86-64, I have
to refer to the ongoing reverse engineering performed by the Linux
people.  It is my understanding that its code is triggered by an
IFUNC constructor during dynamic linking that checks that it is in
the address space of a /usr/sbin/sshd process and then proceeds to
redirect an RSA signature verification routine to its own malicious
code.  Liblzma ends up dynamically linked to sshd because of a
systemd-related extension added by many Linux packagers that pulls
in liblzma as an unrelated dependency.  The actual backdoor is
triggered by an SSH connection that authenticates with a certificate
that includes an RSA public key, part of which is a payload that
is checked against a fingerprint, then verified for a correct Ed448
signature with a key only the attacker knows, and then this content
is directly executed in a shell spawned by sshd for remote code
execution.

The build stage of the backdoor is well hidden.  The stage 0 shell
snippet looks at first glance like a plausible part of the poorly
readable autoconf/automake tooling.  The test files that hide the
further stages and actual backdoor code are unsuspicious by themselves.
5.6.1 added further tests to abort early on non-Linux platforms,
presumably so that nobody examining build problems would stumble
over anything suspicious.  I think the check for a .deb or .rpm
build is intended to inject the backdoor only during automated
package building, so people developing or debugging xz would not
accidentally discover it in the build directory.

I can identify four commits in the xz Git repository that are related
to the backdoor.  In chronological order:

2024-02-23 cf44e4b Tests: Add a few test files.
2024-03-09 

Re: lcamtuf on the recent xz debacle

[Eric Pruitt]

On Thu, Apr 04, 2024 at 09:17:18PM +, Katherine Mcmillan wrote:
> I have seen the following comment, or similar, in several articles now:
> "On Friday, a lone Microsoft developer rocked the world when he revealed a 
> backdoor
>  had been intentionally planted in xz Utils, an open source data compression 
> utility available on almost all installations of Linux and other Unix-like 
> operating systems." 
> https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/
> 
> There are a couple of problems with this statement, but I just want to focus 
> in on the "almost all installations of Linux and other Unix-like operating 
> systems" part.  From my understanding, it is certainly almost all 
> installations of Linux​, but the "and other Unix-like operating systems" 
> doesn't seem founded.  From what I understand, this backdoor would not affect 
> any flavour of *BSD, or of illumos for that matter (ex. smartOS), or QNX, or 
> Solaris.  Just for clarity, does anyone know what "Unix-like operating 
> systems" would be affected by this?

I think this might be an issue of how you're parsing the statement. It
sounds like you're reading this as the exploit being available on those
systems. However, when I read the line, I interpret as "xz Utils ...
[is] available on almost all installations of Linux and other Unix-like
operating systems," which is true. That does not necessarily suggest
that they're all affected by the vulnerability.

Eric

Re: lcamtuf on the recent xz debacle

[Eric S Pulley]

I says quite clearly in the second article you posted it can only work
in Linux... 

"...Linux distributions add a patch to link sshd to systemd, a program
that loads a variety of services during the system bootup. Systemd, in
turn, links to liblzma, and this allows xz Utils to exert control over
sshd."

-- 
ESP

On Thu, 4 Apr 2024 21:17:18 +
Katherine Mcmillan  wrote:

> Hello Peter and all,
> 
> I have seen the following comment, or similar, in several articles
> now: "On Friday, a lone Microsoft developer rocked the world when he
> revealed a
> backdoor
> had been intentionally planted in xz Utils, an open source data
> compression utility available on almost all installations of Linux
> and other Unix-like operating systems."
> https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/
> 
> There are a couple of problems with this statement, but I just want
> to focus in on the "almost all installations of Linux and other
> Unix-like operating systems" part.  From my understanding, it is
> certainly almost all installations of Linux​, but the "and other
> Unix-like operating systems" doesn't seem founded.  From what I
> understand, this backdoor would not affect any flavour of *BSD, or of
> illumos for that matter (ex. smartOS), or QNX, or Solaris.  Just for
> clarity, does anyone know what "Unix-like operating systems" would be
> affected by this?
> 
> Thank you,
> Katie
> 
> 
> From: owner-m...@openbsd.org  on behalf of
> Aaron Mason  Sent: 03 April 2024 19:17
> To: misc@openbsd.org 
> Subject: Re: lcamtuf on the recent xz debacle
> 
> Attention : courriel externe | external email
> 
> On Sat, Mar 30, 2024 at 9:32 PM Peter N. M. Hansteen
>  wrote:
> >
> > "This dependency existed not because of a deliberate design decision
> > by the developers of OpenSSH, but because of a kludge added by some
> > Linux distributions to integrate the tool with the operating
> > system’s newfangled orchestration service, systemd."
> >  
> 
> As if I needed another reason to intensely dislike systemd...
> 
> --
> Aaron Mason - Programmer, open source addict
> I've taken my software vows - for beta or for worse
> 

Re: lcamtuf on the recent xz debacle

[Markus Wernig]

On 4/4/24 23:17, Katherine Mcmillan wrote:

an open source data compression utility available on almost all installations of 
Linux and other Unix-like operating systems."


There are a couple of problems with this statement, but I just want to 
focus in on the "almost all installations of Linux and other Unix-like 
operating systems" part. 


The statement reads "available on almost all ...", which is correct, as 
far as I can tell. But yes, the backdoor code in the version that was 
discovered seems to have targeted only Linux.

Re: lcamtuf on the recent xz debacle

[Katherine Mcmillan]

Hello Peter and all,

I have seen the following comment, or similar, in several articles now:
"On Friday, a lone Microsoft developer rocked the world when he revealed a 
backdoor
 had been intentionally planted in xz Utils, an open source data compression 
utility available on almost all installations of Linux and other Unix-like 
operating systems." 
https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/

There are a couple of problems with this statement, but I just want to focus in 
on the "almost all installations of Linux and other Unix-like operating 
systems" part.  From my understanding, it is certainly almost all installations 
of Linux​, but the "and other Unix-like operating systems" doesn't seem 
founded.  From what I understand, this backdoor would not affect any flavour of 
*BSD, or of illumos for that matter (ex. smartOS), or QNX, or Solaris.  Just 
for clarity, does anyone know what "Unix-like operating systems" would be 
affected by this?

Thank you,
Katie


From: owner-m...@openbsd.org  on behalf of Aaron Mason 

Sent: 03 April 2024 19:17
To: misc@openbsd.org 
Subject: Re: lcamtuf on the recent xz debacle

Attention : courriel externe | external email

On Sat, Mar 30, 2024 at 9:32 PM Peter N. M. Hansteen  wrote:
>
> "This dependency existed not because of a deliberate design decision
> by the developers of OpenSSH, but because of a kludge added by some
> Linux distributions to integrate the tool with the operating
> system’s newfangled orchestration service, systemd."
>

As if I needed another reason to intensely dislike systemd...

--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse

Re: Starting Homebridge / nodejs daemon at boot

[Manuel Kuklinski]

Hi!

Am Dienstag 10 Oktober 2023 um 21:15:00 -0700, schrieb Renato Aguiar 0,3K:
> On Tue, Oct 10 2023, Manuel Kuklinski wrote:
> 
> > I can't get homebridge started at boot - it starts with the following
> > rc.d script if running as root after logging in, but fails to be present
> > at boot time
> 
> I posted a workaround for that in ports mailing list:
> https://marc.info/?l=openbsd-ports&m=169587505711635&w=2
> 
> -- 
> Renato Aguiar

I upgraded to 7.5 (thank you!) and everything is working flawlessly -
7.5 was already available on the official FTP servers.

Best wishes.

Re: wifi hotspot workaround

[Peter N. M. Hansteen]

On Thu, Apr 04, 2024 at 07:22:01PM +0500, ofthecentury wrote:
> Okkk, device hangups still occur. But there's some
> statistics at least in FreeBSD, by running
> `sysctl dev.ath`...anything like that in OpenBSD?

netstat -I $devicename with your choice of options will reveal at least some
information.

- P

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: wifi hotspot workaround

[ofthecentury]

Okkk, device hangups still occur. But there's some
statistics at least in FreeBSD, by running
`sysctl dev.ath`...anything like that in OpenBSD?

On Thu, Apr 4, 2024 at 6:54 PM ofthecentury  wrote:
>
> Here's the solution to the athn0 driver constant cop outs.
> I installed FreeBSD and running a wifi AP there seems smooth.
> It might still start being wonky and might not last, but for now
> there's been an immediate relief in symptoms, it seems.
> Aside being on a different implementation of the wireless network
> stack and the athn0 driver, what's different is that I use wpa3
> and hostapd on the FreeBSD install as well as no graphical
> drivers at all unlike in OpenBSD (the default in FreeBSD install).
> Hopefully, this might help someone to troubleshoot this.
>
> On Wed, Apr 3, 2024 at 10:32 AM ofthecentury  wrote:
> >
> > Frolicking through the net80211 jungle of the code, it looks like
> > the authenticated wifi client info is stored by the kernel and not exposed
> > to the userspace. But I'm still not 100% sure which source file does
> > it and what variable holds that. I see net80211 code that deals with
> > the association frames. Is that where an authenticated user would be
> > saved? Or is there something above net80211 that will handle that?
> >
> > On Wed, Apr 3, 2024 at 12:22 AM Peter J. Philipp  
> > wrote:
> > >
> > > On Tue, Apr 02, 2024 at 11:20:52PM +0500, ofthecentury wrote:
> > > > I'll take a look at those locations, thanks. It might just be arp
> > > > that's the authenticated client data store from the point of view of
> > > > the wireless interface.
> > >
> > > If you really want to debug what's going on I suggest you put another
> > > machine like a laptop into monitor mode and use the -Y flag with tcpdump
> > > to capture what's going on at a frequency.  Beware of beacons, they 
> > > clutter
> > > up the frequencies.
> > >
> > > > I do know German, I'll see if I can get the book, or if I even need it
> > > > after I poke around.
> > >
> > > Here is the ISBN along with all my techie books that I was going to donate
> > > away.  Thankfully noone wanted them because I was going to go to college
> > > but didn't have the highschool marks to get accepted at the course I 
> > > wanted
> > > to take.  http://mainrechner.de/Buecher2024/
> > >
> > > > My OpenWrt router got fried by a remote electric directional beam of a
> > > > digital weapon from an apartment across the wall a few years ago. Even
> > > > a simple digital thermometer near the router was getting broken and
> > > > showing weird stuff on display. How can this be legal? We must mandate
> > > > RF detectors in all homes for everyone's electronic device safety and
> > > > personal safety.
> > >
> > > Yes radio can get really nasty especially when it's directed with a 
> > > parabolic
> > > dish or phased array antenna.  I have images in my head, that the military
> > > has on trucks with huge parabolic dishes.  Those were intended to "zap" 
> > > civil
> > > unresters and make them disperse.  Whether they are torture or not is not
> > > in my scope, but I understand that when a human can get zapped at 60 feet 
> > > that
> > > a electronic device can get zapped as well.
> > >
> > > I don't know what your laws are where you live, but I tend to agree with 
> > > that
> > > statement.  Eventually there may be sensors on your cellphone/smartphone, 
> > > is
> > > what I suspect because I've seen google talks about measuring 
> > > radioactivity
> > > with geiger counters built into android phones, so it definitely is going
> > > around the heads of implementors.
> > >
> > > > I'm 100% cabled at home for a while now too, but trying to see if I
> > > > can make this hostap work in OpenBSD, since it's the golden standard
> > > > for security?
> > > >
> > > > Thanks again for your help.
> > >
> > > No problem, and my pleasure.  I once had this idea to make 3 types of 
> > > accesses
> > > in my home once.  One would be an open access point (like freifunk maybe),
> > > 2nd would be password protected with a QR code displaying the password 
> > > inside
> > > the apartment on a digital photo picture frame, changing the password 
> > > daily or
> > > semi-daily.  And finally one for private communications.  They could
> > > potentially all be on the same hardware but vlan'ed and firewalled to 
> > > sh*ts,
> > > including IPSEC.  Strangers at the door can use the open access point, 
> > > friends
> > > inside the apartment can use the encrypted 2nd access point and close 
> > > friends
> > > such as spouse or girlfriend would be allowed on the highest layer of 
> > > private
> > > Wifi.  The only problem is getting friends these days is hard for loners 
> > > like
> > > myself, so there is really no point for me.  But if I had frequent guests 
> > > and
> > > such I'd want such a system.
> > >
> > > I remember years ago OpenBSD devs were suggesting to "just buy a consumer 
> > > AP".
> > > But times can change.  Maybe in the future some 

Re: wifi hotspot workaround

[ofthecentury]

Here's the solution to the athn0 driver constant cop outs.
I installed FreeBSD and running a wifi AP there seems smooth.
It might still start being wonky and might not last, but for now
there's been an immediate relief in symptoms, it seems.
Aside being on a different implementation of the wireless network
stack and the athn0 driver, what's different is that I use wpa3
and hostapd on the FreeBSD install as well as no graphical
drivers at all unlike in OpenBSD (the default in FreeBSD install).
Hopefully, this might help someone to troubleshoot this.

On Wed, Apr 3, 2024 at 10:32 AM ofthecentury  wrote:
>
> Frolicking through the net80211 jungle of the code, it looks like
> the authenticated wifi client info is stored by the kernel and not exposed
> to the userspace. But I'm still not 100% sure which source file does
> it and what variable holds that. I see net80211 code that deals with
> the association frames. Is that where an authenticated user would be
> saved? Or is there something above net80211 that will handle that?
>
> On Wed, Apr 3, 2024 at 12:22 AM Peter J. Philipp  
> wrote:
> >
> > On Tue, Apr 02, 2024 at 11:20:52PM +0500, ofthecentury wrote:
> > > I'll take a look at those locations, thanks. It might just be arp
> > > that's the authenticated client data store from the point of view of
> > > the wireless interface.
> >
> > If you really want to debug what's going on I suggest you put another
> > machine like a laptop into monitor mode and use the -Y flag with tcpdump
> > to capture what's going on at a frequency.  Beware of beacons, they clutter
> > up the frequencies.
> >
> > > I do know German, I'll see if I can get the book, or if I even need it
> > > after I poke around.
> >
> > Here is the ISBN along with all my techie books that I was going to donate
> > away.  Thankfully noone wanted them because I was going to go to college
> > but didn't have the highschool marks to get accepted at the course I wanted
> > to take.  http://mainrechner.de/Buecher2024/
> >
> > > My OpenWrt router got fried by a remote electric directional beam of a
> > > digital weapon from an apartment across the wall a few years ago. Even
> > > a simple digital thermometer near the router was getting broken and
> > > showing weird stuff on display. How can this be legal? We must mandate
> > > RF detectors in all homes for everyone's electronic device safety and
> > > personal safety.
> >
> > Yes radio can get really nasty especially when it's directed with a 
> > parabolic
> > dish or phased array antenna.  I have images in my head, that the military
> > has on trucks with huge parabolic dishes.  Those were intended to "zap" 
> > civil
> > unresters and make them disperse.  Whether they are torture or not is not
> > in my scope, but I understand that when a human can get zapped at 60 feet 
> > that
> > a electronic device can get zapped as well.
> >
> > I don't know what your laws are where you live, but I tend to agree with 
> > that
> > statement.  Eventually there may be sensors on your cellphone/smartphone, is
> > what I suspect because I've seen google talks about measuring radioactivity
> > with geiger counters built into android phones, so it definitely is going
> > around the heads of implementors.
> >
> > > I'm 100% cabled at home for a while now too, but trying to see if I
> > > can make this hostap work in OpenBSD, since it's the golden standard
> > > for security?
> > >
> > > Thanks again for your help.
> >
> > No problem, and my pleasure.  I once had this idea to make 3 types of 
> > accesses
> > in my home once.  One would be an open access point (like freifunk maybe),
> > 2nd would be password protected with a QR code displaying the password 
> > inside
> > the apartment on a digital photo picture frame, changing the password daily 
> > or
> > semi-daily.  And finally one for private communications.  They could
> > potentially all be on the same hardware but vlan'ed and firewalled to sh*ts,
> > including IPSEC.  Strangers at the door can use the open access point, 
> > friends
> > inside the apartment can use the encrypted 2nd access point and close 
> > friends
> > such as spouse or girlfriend would be allowed on the highest layer of 
> > private
> > Wifi.  The only problem is getting friends these days is hard for loners 
> > like
> > myself, so there is really no point for me.  But if I had frequent guests 
> > and
> > such I'd want such a system.
> >
> > I remember years ago OpenBSD devs were suggesting to "just buy a consumer 
> > AP".
> > But times can change.  Maybe in the future some time :P, it's still 
> > unwritten.
> > Since I had wifi gear there was a guy named Bergamini who was very skilled 
> > in
> > writing drivers.  He left though, and since then the wifi stack afaik has 
> > been
> > nurtured mostly by Stefan Sperling and anyone else who has the skill to help
> > him.  I'm obviously missing some names but these are the people who 
> > impressed
> > me.  Since last week I've been wanting

Re: OpenBSD Errata: April 8, 2024 (xserver)

[Janne Johansson]

Den tors 4 apr. 2024 kl 07:31 skrev Mizsei Zoltán :
>
> The webpage https://www.openbsd.org/errata74.html
> lists this like "016: SECURITY FIX: April 8, 2024
> " but according to my calendar today is 04.04.
> Also it lists 7.5 as affected, but it doesnt even released yet, right?
> Whats going on here?

The 7.5 files were built weeks ago to allow packages for 7.5 to be
built in time for the release, and the 7.5 files contained this bug
which now has a fix prepared for it, even before the release is made.

-- 
May the most significant bit of your life be positive.