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

[Daniel Micay]

On 22/04/14 06:03 AM, Allan McRae wrote:
> Lets not draw this out too much further.  I don't want to have to
> unsubscribe from another mailing list...  But I am still going to have
> my say!
> 
> 1) This was different than every other package in [community].  I know
> this because packages get added to [community] all the time without an
> email here.  And saying discussion about adding PaX extensions was makes
> it different is naive as anyone who has been around here a short time
> could tell you that was never going to happen.

I didn't expect much from that proposal but it was worth trying. It's
now clear to me that it's never going to happen. It was less of a pipe
dream than enabling SELinux support in many packages + shipping complex
policies via labels on files/directories :).

> 2) A few years back we specifically reduced the number of kernels in our
> repos to one.  Then the LTS kernel appeared.  Now this.  The problem
> with adding a non-vanilla kernel to the repos is now for kernel bug
> reports we have to verify which kernel is running.  If it is
> linux-grsec, we then need to figure out if the issue a generic linux
> one, or with the other patchset.  This is a burden to all our the kernel
> maintainers and not just the packager and is part of the reason the
> variety of kernels was reduced.

Output from `uname -a` or `dmesg` is a pretty basic requirement for a
kernel issue, especially since problems like /boot not being mounted and
new upgrades installed to the wrong place often happen. I don't mind
being the one who asks for this on any [linux] issues missing it.

I'll have to dig up the old discussion because I wasn't around for it.

> 3) Now this is in [community] there will be an expectation of providing
> all the extras that are supposed to come with this.  As decided, this
> will not be happening, but it will be expected and the question will
> need to be answered repeatedly.

Whether or not the kernel is in the repositories, I'm going to be
maintaining the userspace components in [community] so there is going to
an expectation of support (from me).

Rather than providing the PaX exceptions via file attributes, it can be
done via an RBAC policy. If I didn't think I could provide all of the
extras, I wouldn't be taking on the responsibility.

https://bugs.archlinux.org/task/39983

The downside of this solution from a user perspective is that it won't
work for the PaX subset alone (linux-pax, which I have no interest in)
so the hacks in the AUR will stay around. It also means extra pain for
me since it's not yet written, but no one else has to worry about that.

> 4) A separate repo would have given actual number for interest in this.
>  We all know the number of votes in the AUR is a crap metric and could
> have accumulated a long time ago.  It would also have allowed us to see
> how important the above issues are.  Despite assertions, many binary
> repos are well used by the Arch community.

If what ends up happening is that it sees little use and/or causes work
for other people, it can be dropped again. I don't think we're ever
going to find that out from an unofficial repository. At the very least
moving it to [community] is going to make a bunch of people angry about
it and we can get to a resolution faster.

> 5) There were objections to it being included in our binary repos.  This
> does not happen often, but we usually discuss further and come to a
> consensus about inclusion.  Ignoring those objections is not how our
> team works.  Given the relatively few people who responded to the
> thread, we have no real idea what the support was (and I can provide
> unsupported anecdotes for support against or for inclusion of the
> package as well as the next person can...)

I know there were objections, but as you said few people felt like
voicing their opinion here. A real vote would make sense but I don't see
value in arguing in circles with the same few people.

I'm not ignoring real issues that are raised, like the added work of
distinguishing between which kernel users are using. I'm willing to put
in whatever time is required to prevent this from increasing the
workload of people who aren't interested in it. If that means stepping
up and beginning to help with [linux] bug triage, I can do that.

> In conclusion, this should have waited before being put in the repo.  It
> might have ended up there anyway, it might not have.  And I can not be
> bothered figuring it out as it will not affect me in any way.

If the end result is that it ends up back in the AUR, that's fine. I
moved it because I didn't feel this was a productive discussion anymore.
Arguing about this on the mailing list for weeks is going to cause much
more pain than it simply being in [community].

-------------- 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/20140422/3b143dfd/attachment-0001.asc>