On Wed, 2015-05-20 at 11:51 +0100, David Howells wrote:
> If you're going to do this, make it two, please. One for the key
> actually used to sign modules and one for a block of auxiliary keys.
I've done the former already. The plan is to do the latter as a separate
option, yes.
--
David Woodho
David Woodhouse wrote:
> I am increasingly convinced we should just ditch that entire
> can of worms and take a single file named in a Kconfig option.
If you're going to do this, make it two, please. One for the key actually
used to sign modules and one for a block of auxiliary keys.
David
--
On Fri, 2015-05-01 at 17:41 -0400, Abelardo Ricart III wrote:
>
> From module-signing.txt:
>
> > Under normal conditions, the kernel build will automatically generate a new
> > keypair using openssl if one does not exist in the files:
> >
> >signing_key.priv
> >signing_key.x509
>
On Tue, 2015-05-19 at 15:14 +0100, David Howells wrote:
>
> > Right. In this very thread :-). But are you fine with using *.auto for
> > the generated files? I'll send a rebased series.
>
> Can you send me your patches and I'll add them to this:
>
>
> http://git.kernel.org/cgit/linux/ke
Hi Michal,
> Right. In this very thread :-). But are you fine with using *.auto for
> the generated files? I'll send a rebased series.
Can you send me your patches and I'll add them to this:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=modsign-pkcs7
Then I c
On Mon, 2015-05-18 at 12:13 +0100, David Woodhouse wrote:
> On Mon, 2015-05-18 at 11:47 +0100, David Howells wrote:
> > David Woodhouse wrote:
> > You could make it so that the make process picks up .pem files and converts
> > them to DER-encoded .x509 files.
>
> I don't actually care whether i
On Thu, 2015-05-07 at 14:15 +0200, Michal Marek wrote:
> > I like
> > Linus's use of the filechk macro on the second - but we shouldn't overwrite
> > keys someone has manually placed in the tree if the key generation template
> > changes due to git pull altering kernel/Makefile.
>
> That's the pro
On Mon, 2015-05-18 at 11:47 +0100, David Howells wrote:
> David Woodhouse wrote:
>
> > Why not just take multiple certs in PEM form in a single file, rather
> > than automatically including *.x509 in DER form? Wouldn't that be a
> > whole lot easier?
>
> No, for the following reasons:
>
> (1)
David Howells wrote:
> We could even make the kernel handle PEM. It shouldn't be very much overhead
> since it's just a wrapping/encoding of the DER, right?
OTOH, PEM is ~33% larger than DER, so we probably want to stick with DER
embedded in the kernel.
David
--
To unsubscribe from this list:
David Woodhouse wrote:
> Why not just take multiple certs in PEM form in a single file, rather
> than automatically including *.x509 in DER form? Wouldn't that be a
> whole lot easier?
No, for the following reasons:
(1) Unless we want the kernel to be able to handle PEM form, they have to be
On Mon, 2015-05-04 at 11:45 -0700, Linus Torvalds wrote:
> On Sun, May 3, 2015 at 6:45 PM, Linus Torvalds
> wrote:
> >
> > I'd much rather see "x509.genkey" be generated with a move-if-changed
> > pattern, so that it only changes if (a) it didn't exist before or (b)
> > it actually has new content
Michal Marek wrote:
> Right. In this very thread :-). But are you fine with using *.auto for
> the generated files? I'll send a rebased series.
Sure, yes.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On 2015-05-08 15:05, David Howells wrote:
> Michal Marek wrote:
>
>> +@echo >>$@ "[ req_distinguished_name ]"
>> +@echo >>$@ "O = Magrathea"
>> +@echo >>$@ "CN = Glacier signing key"
>> +@echo >>$@ "emailAddress = slartibartfast@magrathea.h2g2"
>
> This bit has changed upstream.
Michal Marek wrote:
> + @echo >>$@ "[ req_distinguished_name ]"
> + @echo >>$@ "O = Magrathea"
> + @echo >>$@ "CN = Glacier signing key"
> + @echo >>$@ "emailAddress = slartibartfast@magrathea.h2g2"
This bit has changed upstream.
David
--
To unsubscribe from this list: send the
On Thu, May 07, 2015 at 02:15:46PM +0200, Michal Marek wrote:
> That's the problem with allowing a file to be either user-supplied or
> generated. We can use separate files for the user-supplied/generated
> cases like below and solve this for good. Not signed off yet, because it
> is only lightly t
On 2015-05-07 13:00, David Howells wrote:
> Michal Marek wrote:
>
>> are you fine with these two patches?
>>
>> https://lkml.org/lkml/2015/2/20/546
>> https://lkml.org/lkml/2015/5/4/614
>
> Yeah, I think so. Your reasoning on the first one is sound - but is it
> possible for $(objtree) to !
Michal Marek wrote:
> are you fine with these two patches?
>
> https://lkml.org/lkml/2015/2/20/546
> https://lkml.org/lkml/2015/5/4/614
Yeah, I think so. Your reasoning on the first one is sound - but is it
possible for $(objtree) to != $(srctree) even when they're coincident. I like
Linu
On 2015-05-05 17:41, Linus Torvalds wrote:
> On Tue, May 5, 2015 at 8:22 AM, Michal Marek wrote:
>> On 2015-05-04 20:45, Linus Torvalds wrote:
>>>
>>> That still leaves the problem that the X509_CERTIFICATES variable
>>> itself seems to be badly defined [..]
>>
>> This will be fixed once https://l
On Tue, 2015-05-05 at 15:34 +0100, David Howells wrote:
> Abelardo Ricart III wrote:
>
> > Here's a (barely tested) patch to show what I mean with the config option.
> > The
> > default case is to always generate a new key at build
> > (MODULE_SIG_BUILDGEN=y)
> > and fallback on generating keys
Abelardo Ricart III wrote:
> Here's a (barely tested) patch to show what I mean with the config option. The
> default case is to always generate a new key at build (MODULE_SIG_BUILDGEN=y)
> and fallback on generating keys during build only if one doesn't exist
> (MODULE_SIG_BUILDGEN=n).
Does it
David Howells wrote:
> > + $(call filechk,x509_list)
Ah... I'd missed that there was a comma, not an underscore there.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ke
Linus Torvalds wrote:
> +define filechk_x509_list
> + echo $(X509_CERTIFICATES)
> +endef
> targets += $(obj)/.x509.list
> -$(obj)/.x509.list:
> - @echo $(X509_CERTIFICATES) >$@
> +$(obj)/.x509.list: Makefile FORCE
> + $(call filechk,x509_list)
How does that actually work?
David
--
On Tue, May 5, 2015 at 7:33 AM, David Howells wrote:
> Linus Torvalds wrote:
>
>> +define filechk_x509_list
>> + echo $(X509_CERTIFICATES)
>> +endef
>> targets += $(obj)/.x509.list
>> -$(obj)/.x509.list:
>> - @echo $(X509_CERTIFICATES) >$@
>> +$(obj)/.x509.list: Makefile FORCE
>> + $
On 2015-05-04 20:45, Linus Torvalds wrote:
> On Sun, May 3, 2015 at 6:45 PM, Linus Torvalds
> wrote:
>>
>> I'd much rather see "x509.genkey" be generated with a move-if-changed
>> pattern, so that it only changes if (a) it didn't exist before or (b)
>> it actually has new content.
>
> Hmm. Someth
Linus Torvalds wrote:
> ...
> So the end result is that we run that "filechk_x509_list" script,
> compare the output to the old target, and update the target iff it is
> different. That would seem to be exactly what we want.
Yep.
> That said, as mentioned, the whole "X509_CERTIFICATES" thing i
On Tue, May 5, 2015 at 8:22 AM, Michal Marek wrote:
> On 2015-05-04 20:45, Linus Torvalds wrote:
>>
>> That still leaves the problem that the X509_CERTIFICATES variable
>> itself seems to be badly defined [..]
>
> This will be fixed once https://lkml.org/lkml/2015/2/20/546 is merged
> (the two pat
On Sun, 2015-05-03 at 22:16 -0700, Linus Torvalds wrote:
> On May 3, 2015 21:42, "Abelardo Ricart III" wrote:
> >
> > That's correct. I was under the impression that having the Makefile generate
> > the signing keys was something that was done just to prevent a build failure
> > with CONFIG_MODULE
On Sun, May 3, 2015 at 6:45 PM, Linus Torvalds
wrote:
>
> I'd much rather see "x509.genkey" be generated with a move-if-changed
> pattern, so that it only changes if (a) it didn't exist before or (b)
> it actually has new content.
Hmm. Something like the attached, to make the .x509.list file be
p
On Sun, 2015-05-03 at 22:16 -0700, Linus Torvalds wrote:
> On May 3, 2015 21:42, "Abelardo Ricart III" wrote:
> >
> > That's correct. I was under the impression that having the Makefile generate
> > the signing keys was something that was done just to prevent a build failure
> > with CONFIG_MODULE
On Sun, 2015-05-03 at 18:45 -0700, Linus Torvalds wrote:
> On Sat, May 2, 2015 at 2:46 AM, Abelardo Ricart III
> wrote:
> > endif
> >
> > -signing_key.priv signing_key.x509: x509.genkey
> > +signing_key.priv signing_key.x509: | x509.genkey
>
> Hmm. Thinking some more about this, I'm not entirel
On Sat, May 2, 2015 at 2:46 AM, Abelardo Ricart III wrote:
> endif
>
> -signing_key.priv signing_key.x509: x509.genkey
> +signing_key.priv signing_key.x509: | x509.genkey
Hmm. Thinking some more about this, I'm not entirely convinced.
With this change, if we change kernel/Makefile to have a dif
On Fri, 2015-05-01 at 21:12 -0700, Linus Torvalds wrote:
> So we shouldn't warn about this. The "generate random key" should be
> the normal action for just about everybody but actual preduction
> vendor builds. It's definitely not an error condition.
Since this patch fixes the unexpected build be
On Sat, May 2, 2015 at 6:12 AM, Linus Torvalds
wrote:
> On Fri, May 1, 2015 at 2:41 PM, Abelardo Ricart III
> wrote:
>>
>> Here's my two-line patch strictly defining the build order, for your perusal.
>
> Ok, so this looks possible and sounds like it could explain the issues.
>
> But I'd like so
On Fri, May 1, 2015 at 2:41 PM, Abelardo Ricart III wrote:
>
> Here's my two-line patch strictly defining the build order, for your perusal.
Ok, so this looks possible and sounds like it could explain the issues.
But I'd like somebody who is much more familiar with these kinds of
subtleties in '
Forgive me if this git send-email blows up in my face somehow, as I hadn't been
subscribed to this list before this reply.
I had some similar and probably related behavior I submitted a patch to the
kbuild guys for that fell on deaf ears. Basically, I think an order-only
prerequisite would make
On Thu, Apr 30, 2015 at 10:49 AM, Sedat Dilek wrote:
>>
>> Yeah. I've had other reports, but I can't see anything obvious. I have a
>> suspicion there may be something not declared quite right in the makefile -
>> or
>> even a race in make -jN, but I don't know how to reproduce it.
>
> Ah OK, (
On Thu, Apr 30, 2015 at 4:50 PM, David Howells wrote:
> Sedat Dilek wrote:
>
>> This happened a 2nd time with a different kernel-series!
>> Not sure why this was the case.
>> It did not happen when rebuilding with the same kernel-config again.
>> Not sure if parallel-make-jobs might be a cause fo
Sedat Dilek wrote:
> This happened a 2nd time with a different kernel-series!
> Not sure why this was the case.
> It did not happen when rebuilding with the same kernel-config again.
> Not sure if parallel-make-jobs might be a cause for this (see attached
> build-script).
Yeah. I've had other r
Change default key details to be more obviously unspecified.
Reported-by: Linus Torvalds
Signed-off-by: David Howells
Acked-by: James Morris
---
Documentation/module-signing.txt |6 +++---
kernel/Makefile |6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
di
39 matches
Mail list logo
