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

[Massimiliano Torromeo]

In data martedì 22 aprile 2014 20:03:38, Allan McRae ha scritto:
> 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!

Several valid points worth discussion have been raised in this thread, even 
with the rough last bits I think it was worth evaluating. It's your choice if 
you want to unsubscribe from here of course...


> 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.
> 
> 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.

This is a very valid concern. Nobody raised it before though and in defence of 
Daniel I think the discussion was stagnating without such valid arguments 
having being pointed out.


> 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.

This is mostly true of every package. I packaged the user-space audit daemon 
and I was forced to remove it from [community] when audit support was removed 
from the [core] kernel. The point that support was expected for audit was as 
much valid as it would be for a different kernel.


> 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.

That does not contradict the assertion that by being in [community] the 
userbase would probably be much larger (debatable of course...) but most 
importantly having a separate repo does not solve the issue you pointed out.
The used kernel will still need to be specified in bug reports.

It is also true for kernels compiled from AUR.

What changes is the user expectation and on this I agree with you but most of 
the time that would translate in a simple matter of reassigning bugs to the 
kernel maintainer.


Maybe this is really not so simple and additional kernel will not be accepted 
in official binary repos but I think it would be a valuable "feature" for arch 
to have if we can make it work.

-- 
Massimiliano "mtorromeo" Torromeo
Arch Linux TU
GPG: 0xDA2EE423