https://packages.debian.org/stretch/paxrat

upstream ceased open development: https://www.grsecurity.net/passing_the_baton_faq.php

upstream ceased open development: https://www.grsecurity.net/passing_the_baton_faq.php

Unfortunately the maintainer said that its a big maintenance burden for him but is open to outside help. I asked for this functionality to be added as optional for the source package.

In T203#8183, @HulaHoop wrote:

Opened feature request:

linux-grsec-base: Multiple Compiled Grsec Kernels for Virtualization Compatibility

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816309

Opened feature request:

The author (Collin Childs) is associated with Tor

Having had a glimpse at the code, it is still missing tons of required
features. Almost everything listed in T301. Anyhow. Good to know.

Coldkernel is a project that is better at what grsecurity-installer was meant to be:

There is no "no duplicate package" policy in that sense. There is a "no
duplicate source code" policy. [Compare: linux-image-686 vs
linux-image-686 are not considered duplicates either. Sharing the very
same source package.] Therefore linux-grsec-generic, linux-grsec-xen,
etc. should not be a policy issue.

Not gonna happen. It took this long to package grsec for Debian because of their no duplicate packages policy so the patch had to be adjusted to work with the Debian flavor of the linux kernel.

What about separate binary packages per hypervisor?

Could support for all hypervisors be enabled at the same time?

Could support for all hypervisors be enabled at the same time?

The problem is the Debian kernel is not compiled with any virtualization support.

What does not work? The package build/install or the grsecurity kernel itself?

You want softmode, right? So why use 'kernel.pax.softmode=0' instead of
'kernel.pax.softmode=1'?

What does not work? The package build/install or the grsecurity kernel
itself?

I tried manually testing the 05-grsec.conf settings with no success. Editing the original grsec.conf doesn't work too. (I tried with the kernel conf lock setting disabled). I don't know what to try now...

debian/rules debian/control misses systemd entries.

OK did the changes but need to test package.

HulaHoop (HulaHoop):

> needs a license header.

Its all gplv3. Do you have an example?

needs a license header.

This can very well go to the testers and also the stable repository just
as any package. As long as it's not installed by default there really is
no reason a against it since it requires a manual action to install that
won't be happening accidentally without reading documentation.

Some notes: When copying paxctld all my tabbing disappeared and the file looks hideous.

And how does corsac's repository help with that compared to Debian sid repository?

Yes. Let's go simple for start and then see where we get.

I'm almost done with the exceptions list. I merged some rules to cover Tor Browser and a few other binaries that weren't included. Changed some binary paths to reflect those on Debian...

Why are we back to using corsac's repository? Why not use Debian sid repository and apt pinning instead?

Yes. Merge the first two packages.

Yes. Merge the first two packages.

Package roadmap:

To obtain a binary package or source package to compile?

To land a grsec kernel ASAP we can use corsac's Jessie repo.

To land a grsec kernel ASAP we can use corsac's Jessie repo.

All we need is a dpkg hook and a conf file for paxctld (the latter mirrors the Arch Linux one)

My last comment is wrong. David's description is on point.

Can you shed light on paxctld vs paxrat?

Good question. I asked upstream because it depends on what direction they'll take:

Do you think paxrat will require a .d config file folder? Would we need a custom paxrat.conf?

Do you think paxrat will require a .d config file folder?

Do you think paxrat will require a .d config file folder? Would we need a custom paxrat.conf?