@moses_izumi @hikari @AnachronistJohn

#NetBSD definitely deserves some love for being one of the very few, and perhaps the most featureful Operating Systems that has a strong #NOAi stance.❤️‍🔥

I definitely want to start supporting them. I need to get on that.

Kinda postmortem:

1) The maximal log size before rotation and count of gzipped logs to store should be increased in the newsyslogd configuration. This should be applied to any service, which is looking into the void^WInternet. So, I will not loss log records, related to the start of attack…

2) Also, Asterisk log should be added to newsyslogd configuration first. It weren't added here, so *.log files became too big (> 1 Gb) and of course fail2ban ate a lot of memory while parsing these big logs. If they were rotated properly, then fail2ban will not eat so much memory, parsing small enough files.

3) Since start of attack in logs were lost, then I could only imagine possible root cause of an attack. By default, any IP, which once failed to provide the proper credentials to login somewhere in my kitchen server, is banned immediately and forever.
But somehow those attackers managed to use just 2 IPs to make an attack and they weren't banned before manual intervention

According to fail2ban logs they were banned, but they were obviously not banned by npf. So, I think, they started attack right in time when my blacklists were successfully updated and npf was reloading — as a result their IPs appeared as "banned" in the fail2ban, but the fail2ban failed to ban them via npf, so "IRL" their IPs still weren't banned. Time to revisit my script to update blacklists

4) Looks like I need to install some Intrusion Detection System (possibly snort since it is mature enough). It isn't good to rely only on one mechanism (fail2ban + blacklists + npf) to protect my precious machine.

#NetBSD #selfhosting #fail2ban #npf

Kinda postmortem:

1) The maximal log size before rotation and count of gzipped logs to store should be increased in the newsyslogd configuration. This should be applied to any service, which is looking into the void^WInternet. So, I will not loss log records, related to the start of attack…

2) Also, Asterisk log should be added to newsyslogd configuration first. It weren't added here, so *.log files became too big (> 1 Gb) and of course fail2ban ate a lot of memory while parsing these big logs. If they were rotated properly, then fail2ban will not eat so much memory, parsing small enough files.

3) Since start of attack in logs were lost, then I could only imagine possible root cause of an attack. By default, any IP, which once failed to provide the proper credentials to login somewhere in my kitchen server, is banned immediately and forever.
But somehow those attackers managed to use just 2 IPs to make an attack and they weren't banned before manual intervention

According to fail2ban logs they were banned, but they were obviously not banned by npf. So, I think, they started attack right in time when my blacklists were successfully updated and npf was reloading — as a result their IPs appeared as "banned" in the fail2ban, but the fail2ban failed to ban them via npf, so "IRL" their IPs still weren't banned. Time to revisit my script to update blacklists

4) Looks like I need to install some Intrusion Detection System (possibly snort since it is mature enough). It isn't good to rely only on one mechanism (fail2ban + blacklists + npf) to protect my precious machine.

#NetBSD #selfhosting #fail2ban #npf

By the way, our first two publications on evaluating #OpenBSD mitigations are out. Both of these papers evaluate some amd64 anti-ROP mitigations: specifically changing the register selection order and semantically equivalent rewriting of instructions that may produce a potential polymorphic gadget instruction. This tracks a paper by mortimer@ back in 2019 at AsiaBSDCon.

The TL;DR is "OpenBSD can shrink binaries a little and gain a little performance without any security loss simply by reverting these mitigations." The mitigations did not hold up to independent evaluation.

The first paper did an exact 1:1 port of these mitigations to FreeBSD and found that register reallocation eliminates only about 0.3% of unique gadgets, for a 0.5% increase in binary size (mortimer@ claimed 6% reduction and "entirely free"). It is useless at best but more likely actively detrimental, as it produces a false sense of security. It also found the instruction rewriting reduces unique gadgets by about 3.5% with a binary size increase of about 1.8% (mortimer@ claimed 5% reduction with 0.15% binary size increase).

We then did a separate implementation of the instruction rewriting mitigation to GCC in the second paper. Our GCC implementation does the older <xchg; op; xchg> dance, as that's what mortimer@'s paper described. This is way worse; producing about a 3% performance hit for no security benefit at all.

The only part of both mitigations worth saving is for basic arithmetic, OpenBSD LLVM now takes advantage of the fact that basic arithmetic has two forms. For example, the newer instruction rewriting mitigation turns
addq %rax, %rbx (48 01 c3)
into
{load} addq %rax, %rbx (48 03 d8)

The new instruction rewriting mitigation is genuinely free in terms of binary size and execution speed, but doesn't move the security needle, so this one can stay as it is harmless. Other rewritings still have the flaw of increasing binary size and reducing performance for no security benefit.

Anyhow feel free to read the papers:
https://ieeexplore.ieee.org/abstract/document/11458911
https://www.researchgate.net/publication/405728967_A_Final_Return_for_OpenBSD_Anti-Return-Oriented_Programming_Mitigations

#BSD #FreeBSD #NetBSD #DragonFlyBSD #Linux #Unix #security #cybersecurity

New #blog #post: Package Manager Tier List

https://rldane.space/package-manager-tier-list.html

1521 words

Note: this is a very off-the-cuff tier list, using speed as the main qualifier, but the article explains exceptions to that as it goes on.

cc: my wonderful #chorus: @joel @dm @sotolf @thedoctor @pixx @orbitalmartian @adamsdesk @krafter @roguefoam @clayton @giantspacesquid @Twizzay @stfn

(I will happily add/remove you from the chorus upon request! :)

#rlDaneWriting #blost #Linux #BSD #RunBSD #FreeBSD #OpenBSD #NetBSD #Debian #Arch #pacman #AUR #Fedora #homebrew #flatpak #snap #OpenSuSE #RPM

(Edit 2026-07-17: removed stray "DeadLikeMe" hashtag that had been left over from the previous post. Oops! ;)

NetBSD turns 33 this Sunday! 🚩

To celebrate 33 years of clean code, portability, and zero bloat, Challenging the rest of the fediverse to help hit this year's funding goals.

Also do drop a screenshot of your uptime, uname -a, or a pic of the weirdest hardware you've got running NetBSD right now. (RockPro64 NPF routers or Pi's hooked up to retro CRTs highly encouraged).

Throw some money at the developers keeping the real UNIX alive:

https://www.netbsd.org/donations/

#NetBSD #UNIX #RetroComputing #OpenSource #runbsd #FreeBSD #OpenBSD #Linux

Here's my setup: https://schmonz.com/2025/11/12/small-macs/

(Writing... muscles... loosening.)

#macos #linux #netbsd

You should know #pkgsrc 2025Q3 was released yesterday:

https://mail-index.netbsd.org/pkgsrc-users/2025/09/25/msg042016.html

#netbsd

I'd prefer #NetBSD: https://schmonz.com/2024/06/07/small-arms/

Staged latest shairport-sync for #pkgsrc. Builds on NetBSD, #macOS. Normally I'd commit, wait for evbearmv6hf-el binary package, forget.

Trying something new today: https://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/doc/HOWTO-use-crosscompile

A new #blog post appears!

I built a native GCC 14.2.0 for Mac OS X 10.4 Tiger PowerPC.

https://briancallahan.net/blog/20250329.html

#macos #macosx #tiger #powerpc #power #unix #bsd #freebsd #openbsd #netbsd #dragonflybsd #linux #solaris #illumos #gcc #llvm #clang #compiler #compilers #assembler #linker #toolchain #freesoftware #opensource #gnu

All right, pkgsrc 2025Q1 has just been announced on the mailing lists.

It's not even on pkgsrc.org yet! 😉

#pkgsrc #NetBSD