[arch-dev-public] providing grsecurity in [community]

Daniel Micay danielmicay at gmail.com
Mon Apr 21 01:21:16 EDT 2014


On 21/04/14 12:40 AM, Gaetan Bisson wrote:
> [2014-04-20 20:22:59 -0400] Daniel Micay:
>> I don't really see any problem with moving a FOSS package with 52 votes
>> to [community]. Whether or not people like the project isn't really
>> relevant.
> 
> So you initially inquired about this on arch-dev-public because you knew
> it was a controversial issue, but when it turns out most answers are not
> what you hoped for you go ahead against them? Is that the logic here?

I brought it up on arch-dev-public because there were issues involving
other packages. I wasn't looking for approval to move a package for FOSS
software with 40 votes (>50 when it was moved) that I have significant
interest in. I certainly adjusted what I planned to do based on the
feedback here. I thought there might be interest in setting the PaX
exceptions so it could be enabled out-of-the-box but there was not.

There were very valid concerns about modules, which I think have been
resolved by the decision to only use DKMS. I've backed down from the
idea of ever incorporating the PaX exceptions into other packages and
will try to handle it entirely within linux-grsec via RBAC. Other
trusted users and developers will never have to put one bit of work into
supporting this, and that was the only other concern raised.

There are people who have a personal dislike of the software, as with
anything else, and I don't really care. Beyond the issues above, I don't
think anyone has raised a reason to keep this out of [community].

I don't there's there's any "slippery slope" here considering that using
DKMS makes this kind of thing self-contained. It could even be written
down as a policy somewhere that out-of-tree modules for non-[core]
kernel packages are only supported via DKMS. There's not currently
anything written down about this that I know of.

I certainly don't get the impression that "most answers" are against it
being in [community] at all. There was a strong consensus that PaX
exceptions do not belong in other packages, and I can respect that. I
currently have PaX enforcement disabled and will implement a less ideal
solution internal to the package.

The mailing list wasn't the only place where I've discussed this. It has
been a topic of conversation on various IRC channels, where numerous
trusted users and developers voiced support for it. I don't think a
vocal minority on the mailing list represents a consensus against it.

> What part of "do it in a separate repo for the time being" didn't you
> understand and/or like? That solution seemed to make everyone happy...

It didn't make me happy, nor did it seem to be a satisfactory answer to
Connor, Barthalion or various others on IRC. A certain developer (I'll
let them speak for themselves if they want to) suggested I just put it
in [community] instead of being so cautious about it.

> By the way, "Packager: Unknown Packager" looks bad.

I moved this from the unofficial repository on pkgbuild.com where I was
previously building and hosting it, if you're curious why that's messed
up. It will be fixed as soon as there's a new release or I start work on
the PaX issue which won't be long.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-dev-public/attachments/20140421/7ba0c1af/attachment.asc>


More information about the arch-dev-public mailing list