While this package might be dangerous in people that do not know what they do.
With the latest very hight number of critical vulnerabilities in the Kernel i do think having it for people who want (like arch moto is) to build a better security, this package is a must.
As it allow to block not used modules in the kernel.
I do hope to see this request accepted.
I feel like solely based on how you describe the tool the AUR is an appropriate place for it.
It feels like a tool that you either integrate into your process directly as a security-focused distroâŚor having easily available (whether through AUR or just running the script) is sufficient.
while i understand the point, iâm not sure that the answer âgo to AURâ is always true, as an old user of arch i can say that 90% of my crash on my arch time where due to AUR.
Itâs why i would prefer this kind of âcriticalâ app (as it touch on kernel module config) tu be in repo and not on AUR.
Itâs a shell script that generates a config file. It will work the same whether itâs in tbe AUR or in the main repo. And people that arenât clear on what it does probably shouldnât use it anyway.
If you run this, you should also be able to read and audit a basic PKGBUILD
I use modulejail. I like it. I think it fills a void in system security, especially in the current climate.
However, I would never, ever, recommend it be included in any distroâs repos. Remember, inclusion in a repo implies that the distro both trusts the application, and is willing to support it. Itâs the support area where the problem lies.
Remember that modulejail blacklists all modules that are not currently in use when it is run.
I have a laptop old enough to have a built-in DVD-RW. I use it mostly for testing, but also occasionally to rip CDs. Recently when I tried to rip a new purchase, the drive wouldnât work. I have no traditional CD player, so I was anxious to hear this one.
Rather than think and troubleshoot, I got out a portable USB one and plugged it into my main system. Same result, now on two machines. After some cursing and headscratching, it hit me. Neither drive had been in use when I ran modulejail. I cleared its blacklist, rebooted, accessed the drives, then re-ran it. Both drives worked just fine afterwards. I added their modules to the whitelist.
I had to do the same with my VPN. UDP, and by extension Wireguard, is blocked on the Wi-Fi at work. I usually switch manually to OpenVPN over TCP when I use my personal laptop there. Of course, after having run modulejail while using Wireguard at home, OpenVPN and tun were blacklisted.
Extrapolate from two examples by an 30-year experienced Linuxhead to a forum full of people who canât even do a search first, or provide an inxi -zv8 when reporting issues and youâll see what a support headache this could become.
No, modulejail is a tool for advanced users who can and will troubleshoot their own issues, and therefore it should not be in any distroâs repos. I would include the Chaotic-AUR repo in that.
Finally, thus far (2026-05-31), the security issues AI has found in modules (where modulejail could prevent an exploit) all require physical keyboard access to the system in question and have not been remote-access security issues.
This makes modulejail a more limited and esoteric security function which could be handled much more easily with proper login/password and physical security. That also makes it of little benefit to the ordinary user of CachyOS, unless of course, their family and friends are running exploits on their home PC⌠Thus, it is not âcriticalâ as you assert.
The author of modulejail describes it as a tool to buy time between exploit discovery and patching. The Linux ecosystem is really, really good at quickly patching security issues. Rolling-releases are really good at getting those patches out quickly. Adding to a releaseâs support load could slow that process down.
So, yes I use it (even though I have no actual use case), but I donât recommend it to either ordinary users, or to distros to include their repos.
Sorry. Go to the AUR.
i disagree on the fact repo = the distro trust it.
For majority of people what in the repo is what the distro think can be USEFULL for their user.
What is preinstalled is what the distro want / trust.
I meanâŚyouâre objectively wrong here. The only meaningful differences between the repos and AUR are
Cachy installs an AUR helper (paru) and GUI package manager (Shelly) that can access the AUR because that might be useful to some users.
No, what is preinstalled is what delivers the OOTB experience that they want to deliver.
This isnât even opinion. Youâre just objectively wrong.
sure try to continue to be mister iâm always right does not change my request, and if you donât like it i donât care.
You donât even need the AUR package. You can just download the .deb or the .rpm package from the Github page. Extract it and inside /usr/bin you will find modulejail. itâs an script. Run it to your heart desire. The only caveat is that you will have to keep track of the updates yourself.
The hilarious part of your request is that it exists because you donât trust the AUR and want more-trusted packaging
Cachy already makes it available to install with a single command, because they think it might be useful to you. You are explicitly asking for a package with a higher trust level.
So what it does is blacklist kernel modules?
Thats a function that already exists.
Just write your blacklist to the appropriate file, ex;
/etc/modprobe.d/blacklist.conf
blacklist module
I see no reason to need to support some random foreign GUI application for this.
PS.
Sorry. In the repo must mean that it is trusted.
You do not have untrusted applications in the repositories.
The repos contain packages that were inspected and built by the team and then served .. as an official package from the official repos.
If its in the repos you are supposed to be able to trust it.
You know .. things like the linux kernel. Or Plasma packages.
Not ârandom AUR package XYZ that has not been reviewedâ - thats what a foreign package is. And what the AUR is for.
And why its the users responsibility to review AUR PKGBUILDs before using them.
PPS.
I also just looked and found modulejail is a total of 3 weeks old.
With somehow hundreds of stars.
Again for an application that is largely not even needed.
Smells extra fishy to me.
actually the app have a purpose, you launch all the thing you need and run it.
It will scan the ACTUAL module that are running, and blacklist everything else.
Itâs not something easily done manually, and if you think about it that much star in 2 or 3 week is normal.
Since this app is a direct answer to the 4 or 5 massive vulnerability of last monthâŚ
Edit : so the juste write ⌠if you know the tousand of module in the kernel and mannually do it, good for you but itâs an massive amount of work for something this app automate
No it really is not.
A brand new, unknown, software garnering 300 stars in its first 3 weeks of existence is pretty odd.
I am not sure this is actually desirable, especially for newbies.
So an over-reaction using âAIâ that has somehow become weirdly popular?
This just makes it sound like it was done even more hastily and/or for purposes of capitalizing on recent worries .. especially of new users.
It may be mentioned that those things required access, were swiftly patched and had very easy workarounds for those that really needed them.
It really isnt though. Ex;
Full modules;
modprobe -c | awk '/Dumping indexes now/{p=1; next} p{print $NF}' | sort -u > ~/modtreefull.txt
Only used modules;
awk '{print $1}' /proc/modules | sort -u > ~/modtreeused.txt
The modules that exist but are not used;
comm -23 <(cat ~/modtreefull.txt) <(cat ~/modtreeused.txt) > ~/modtreeunused.txt
Blacklist them all (insert+copy);
awk '$0="blacklist "$0' ~/modtreeunused.txt > ~/modtreeunusedblacklist.txt
Actually put the blacklist file in place;
sudo cp ~/modtreeunusedblacklist.txt /etc/modprobe.d/autoblacklist.conf
But I still would probably not suggest the average users do such a thing for various reasons.