On Wed, Oct 18, 2017 at 11:27 AM, Matthew Garrett wrote:
> Hi Jessica,
>
> It seems that there's distribution interest in this - any feedback?
Hi,
I think we'd still benefit from this being available, so just checking
whether you had any further feelings on it.
Hi Jessica,
It seems that there's distribution interest in this - any feedback?
On Tue, 2017-08-29 at 13:22 -0700, Matthew Garrett wrote:
> > On Tue, Aug 29, 2017 at 10:56 AM, Jessica Yu wrote:
> > I understand what the patch is doing, what I don't yet understand is
> > _why_ you would want to remove the unsigned module taint when
> > CONFIG_MODULE_SIG is enabled. Which distr
On Tue, Aug 29, 2017 at 10:56 AM, Jessica Yu wrote:
> I understand what the patch is doing, what I don't yet understand is
> _why_ you would want to remove the unsigned module taint when
> CONFIG_MODULE_SIG is enabled. Which distributions are asking for this
> exactly, and for what use cases? I fi
+++ Matthew Garrett [14/08/17 12:50 -0400]:
On Thu, Aug 10, 2017 at 4:43 PM, Jessica Yu wrote:
I think I'm missing some context here. Could you provide some more
background and help me understand why we want to go into all this
trouble just to avoid a taint? Was there a recent bug report, mail
On Thu, Aug 10, 2017 at 4:43 PM, Jessica Yu wrote:
> I think I'm missing some context here. Could you provide some more
> background and help me understand why we want to go into all this
> trouble just to avoid a taint? Was there a recent bug report, mailing
> list discussion, etc. that spurred
+++ Matthew Garrett [04/08/17 11:07 -0700]:
Distributions may wish to provide kernels that permit loading of
unsigned modules based on certain policy decisions. Right now that
results in the kernel being tainted whenever an unsigned module is
loaded, which may not be desirable. Add a config optio
7 matches
Mail list logo
