Nemesis update- v26.06 (2026-06-01)

[ncmprhnsbl]

first release for 2026

ISOs available here: ISO Downloads
Modules here: Module Downloads
05-devel here: 05-devel Download
Kernel and crippled sources: Kernel Downloads

• Packages updated to 2026-06-01 (and mirrorlists set to corresponding package archive by default).

• Kernel updated to 7.0.11( thanks to Blaze for .config and build tips)

• Added pterid's aufs-dir-tools

• Cleaned up some duplicate packages thanks to aufs-clashes, part of pterid's scripts

• Fixed some missing terminfo and related broken links

• ar{tix,ch} have replaced vi with vim, but i've resisted this and continue to use the symlink to busybox vi for now.. of course if you want vim it should be easy enough to get

• iptables has been replaced with nftables for firewall ( see note below)

• Added 004-lxqt-wl-20260601.xm and 004-xfce-wl-20260601.xm, which can added to enable using wayland sessions for lxqt and xfce (experimental)

NOTE: if you're updating an existing install, be sure to edit config/services, changing iptables to nftables

[vinnie]

[M. Eerie]

YES!

Right on time.

Hopefully it includes the latest vulnerability discovered in the “libinput” library. If not, a delta patch might help.

And speaking of that, I’ve recently been thinking about the balance between stability and security. Seeing how vulnerabilities are discovered almost daily (some of them having existed for many years), perhaps we should enable a model that allows necessary patches to be incorporated into critical packages without waiting for new releases.

In the past few months, we’ve seen several high-severity CVEs affecting widely used dependencies (OpenSSL, glibc, system libraries, etc.). In some environments, the time between disclosure and patch deployment still feels too long—long enough for the window of exposure to become a real risk.

This raises a broader question: are our current update models still the right fit?

On the other side, rolling-release distributions like Arch Linux push updates continuously. Security patches tend to land much faster, sometimes within hours or days of upstream release. The tradeoff, of course, is the increased risk of breakage or integration issues if something slips through. For example, there are times when an update introduces bugs (although they are again fixed in the short term).

So I’m proposing the need for a hybrid model (“stable” base system + fast security channel for critical patches). Maybe prioritize CVEs over general update cycles... And this is where a delta-patch would come into play.

I'd like to hear what others think on this.


THANKS!

[ncmprhnsbl]

Hopefully it includes the latest vulnerability discovered in the “libinput” library.

looks like not.. but, going by patrick's message on the slackware changelog:

x/libinput-1.31.3-x86_64-1.txz: Upgraded.
This update fixes a security issue:
libinput-device-group unescaped phys output can inject udev properties
leading to arbitrary root code execution.
Note that since /dev/uinput and /dev/uhid are only accessible by root on
Slackware (and unlike some other distributions we make no exceptions), we
were not vulnerable to this flaw.
(* Security fix *)

it would seem to be not applicable, since artix/nemesis is the same..

This raises a broader question: are our current update models still the right fit?

On the other side, rolling-release distributions like Arch Linux push updates continuously. Security patches tend to land much faster, sometimes within hours or days of upstream release. The tradeoff, of course, is the increased risk of breakage or integration issues if something slips through. For example, there are times when an update introduces bugs (although they are again fixed in the short term).

So I’m proposing the need for a hybrid model (“stable” base system + fast security channel for critical patches). Maybe prioritize CVEs over general update cycles... And this is where a delta-patch would come into play.

I'd like to hear what others think on this.

sounds sensible .. could get a bit complicated with accumulated delta-patches .. but not impossible..

[M. Eerie]

by patrick's message on the slackware

But here we are in Artix land, aren't we?
This is the CVE

In any case, it certainly doesn't seem to affect us since permissions and ownership are fine:

Code: Select all

ls -l /dev/uinput
crw ------- 1 root root 10, 223 Jun 6 11:04 /dev/uinput

On the other hand:
libntfs-3g seems to be a dependency of ntfs-3g package. Shouldn't it have been included?


Edit:

ntfs-3g --version
ntfs-3g 2022.10.3 external FUSE 29

That version doesn't require the libntfs-3g dependency

[por01]

Is It Time To Leave Arch Linux? https://odysee.com/@DistroTube:2/is-it- ... ch-linux:f
DT, the big fan of Arch, tells that he is thinking about changing to an other system from the Arch because of the recent AUR incidents. My questions: Do the Artix code, binaries incorporated in Nemesis have any AUR stuff? Does Nemesis contain any AUR code or binary?

[ncmprhnsbl]

My questions: Do the Artix code, binaries incorporated in Nemesis have any AUR stuff?

in the sense that some of the custom packages built use PKGBUILDs that originate from AUR: yes
have i sourced them from AUR recently: no
did/do i use them without looking at them: no
did/do i modify them: in some cases: version bump or dependency adjustment or build parameter
do i know what i'm doing and can i be trusted: who knows? let's hope so D:

Does Nemesis contain any AUR code or binary?

these are not really things..
the AUR is a repository of PKGBUILDs (and sometimes patches), which are just recipes, in the form of a partial script, ie. variables and functions that makepkg uses to:
1. obtain the source
2. possibly apply patches and/or directly adjust the source
3. compile source
4. create package archive

i do include in 05-devel, a AUR 'helper': trizen, which searches and obtains PKGBUILDs/etc and wraps makepkg and pacman. it by default displays the PKGBUILD, which the user should examine and understand before continuing.
if not, don't.

i haven't followed the recent AUR attack closely, but from what i gather, ophan apps were targeted(since anyone can adopt an unmaintained app) and the vast majority (there are over 100000) are unaffected.
IMO, the recent 'revelation' that the AUR is unsafe is somewhat overlooking the fact that it was only ever as safe as the end user is sensible ..ie. it always was and will be "use at your own risk"