Megver83 wrote:

As I wrote in the dev list I plan to remove the following packages from the [kernels] repository:

• linux-libre-xen # XEN is disabled by default in 32-bits kernels(0) due to its instability, but comes by default in 64-bits kernels
• linux-libre-nand
• linux-libre-knock # It's patches are not working, but I'll try to save linux-libre-lts-knock, but if I can't I'll remove it
• linux-libre-audit # For paranoic verbosity

But as I don't want to be an asshole who just removes kernels, I also planned to add:

• linux-libre-hardened-apparmor: Kernel with hardened patches and apparmor enabled
• linux-libre-hardened-tomoyo: Same thing but with tomoyo enabled
• linux-libre-tomoyo: Kernel with tomoyo enabled
• linux-libre-lts-tomoyo: LTS Kernel with tomoyo enabled

These^ are good replacements to what linux-libre-grsec{-knock} was, plus having security in LTS kernels (linux-libre-lts-apparmor for now) is a good combination for servers.

Besides this, there's the issue of the PCK patch: it is a combination of ZEN and Knock, but as I said, knock is not working and linux-libre-pck is part of [libre], so it can't be so outdated (it's on 4.10.x still). I think we just have to abandon the PCK patch and replace linux-libre-pck with linux-libre-zen unless there's a worthy patch to improve even more the performance than how ZEN does (PF is part of ZEN, so I discarded it as an option).

I really want the opinion of the community before doing this, although I see that there is a low interest in the [kernels] repository, but it's worthy to maintain IMO.

(0) i686 and armv7h for instance

I understand your approach to kernels.
From the technical point of view, it is better to have worked kernels that really help the user.
Megver83, you have my point in favor, personally I know it's tedious to have the kernels updated.

From the technical point of view, it is better to have worked kernels that really help the user

Yes, I see that (for example) the audit kernel was a request from lukeshu some years ago, but he didn't say anything regarding that when I proposed its deprecation.

BTW, I could save linux-libre-lts-knock, I just need that Emulatorman fixes the knock patch for mainline, and I also requested adding the knock patches to linux-hardened so if Emulatorman fixes knock and it gets in linux-hardened, I can deprecate linux-libre-knock 'cause it would be already in linux-libre-hardened & linux-libre-pck (I'll update it with ZEN only for now, it can't be so outdated), but I would continue maintaining linux-libre-lts-knock because it's LTS.

UPDATE: The issue was closed, knock is not getting in linux-hardened

As there's no much interest in [kernels], I'll deprecate:

• linux-libre-apparmor
• linux-libre-xen
• linux-libre-nand
• linux-libre-audit
• linux-libre-knock(0)

And add this kernel:

• linux-libre-xtreme: A custom kernel with AppArmor, TOMOYO and Smack enabled plus hardened patches

So linux-libre-xtreme will centralize all security features, and linux-libre-lts-apparmor and linux-libre-lts-knock will be our lts security kernels.

(0) I'll try to get knock into linux-libre-xtreme, if it doesn't conflicts linux-hardened patch. Anyways once Emulatorman fixes the knock patch at least linux-libre-pck will include it as it used to, so there's no reason to keep linux-libre-knock with linux-libre-pck and linux-libre-lts-knock

deprecated linux-libre-lts-apparmor and knock, and added linux-libre-lts-xtreme
https://git.parabola.nu/abslibre.git/commit/?id=bc591e749a772ad62a661290ad4b45b1c115c9a1

this is my last movement, so now this issue is fully done