On Thu, Jul 6, 2017 at 5:34 AM, Natanael Copa <ncopa_at_alpinelinux.org> wrote:
> On Sun, 2 Jul 2017 18:37:50 +0100
> Cág <ca6c_at_bitmessage.ch> wrote:
>> Hi everyone,
>> I was reading news the other day and found this:
> The reason Linus calls it garbage is because its not split up, so it
> cannot be included upstream:
> Well, Linus also says he would prefer that Spender himself sent patches
> for inclusion:
>> In the comment section somebody linked this thread:
>> Bruce Perens warns about risks for grsecurity customers:
>> Earlier RMS said about GPL violation.
> Yeah, what they do is controversial. We don't break the GPL though.
>> Then there was this thing:
>> Looks like this person and some others that replied were banned by
> They got banned from grsecurity twitter. After that grsecurity left
> twitter, so he is banned from something that no longer exists.
I don't think this is very interesting -- everyone by now knows the
pros and cons of interacting with Brad.
>> Considering the abovementioned, was it a good thing to start using
>> their patches?
> When we started using their patches for more than 10 years ago, yes, it
> was a good thing. They solved security issues back then that is not
> solved in mainline until now. (the issue at hand that made it to media
> was solved by Grsecurity around 2010-2011 something?)
> They were early (first?) with ASLR. We have always built our userspace
> with PIE, bindnow and relro so we can fully utilize it.
> So I would definitively say it was a good thing to start using their
>> Is there a need in a hardened kernel overall?
> I think the link you provided answers that:
> Grsecurity finds and fixes many issues in kernel that nobody else
> notices/cares about (until it hits media as in the recent case)
Yes but a lot of the bugfixes they do are undisclosed, so nobody knows
about them, which is annoying.
> So the question is: do we need to be ahead other distros when it comes
> to kernel security?
> But there are some reasons to why we we should stop using it:
> - It is not good to depend on something unreliable (we don't know if we
> can access future patches - there is no guarantee that they will give
> us access even if we pay them)
> - No support
> - It requires much work to maintain the unofficial patch
> - Their business model (Alpine is open source)
> - They are difficult to co-operate with
> I want continue using it for as long as it is possible.
Personally, having looked at strcat's work, I am optimistic, and
basically I see a future where we can draw from KSPP, strcat's work,
and our own work to provide a hardened kernel for Alpine 3.7. I'm not
too worried about it.
Ironically, strcat's work on tuning the Linux ASLR implementation
scores better on paxtest than PaX, which I found interesting.
Received on Wed Jul 12 2017 - 02:18:18 UTC