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
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 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
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
Nope,
David Woodhouse dw...@infradead.org 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
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:
>
>
>
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
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
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:
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
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
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:
>
>
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 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 problem with
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 dw...@infradead.org 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
David Woodhouse dw...@infradead.org 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,
David Howells dhowe...@redhat.com 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
On Mon, 2015-05-18 at 11:47 +0100, David Howells wrote:
David Woodhouse dw...@infradead.org 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:
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
On Mon, 2015-05-04 at 11:45 -0700, Linus Torvalds wrote:
On Sun, May 3, 2015 at 6:45 PM, Linus Torvalds
torva...@linux-foundation.org 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
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
Michal Marek mma...@suse.cz 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
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.
On 2015-05-08 15:05, David Howells wrote:
Michal Marek mma...@suse.cz wrote:
+@echo $@ [ req_distinguished_name ]
+@echo $@ O = Magrathea
+@echo $@ CN = Glacier signing key
+@echo $@ emailAddress = slartibartfast@magrathea.h2g2
This bit has changed upstream.
Right. In
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
Michal Marek mma...@suse.cz 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 line
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
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
Michal Marek mma...@suse.cz 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.
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
On 2015-05-07 13:00, David Howells wrote:
Michal Marek mma...@suse.cz 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
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
On 2015-05-05 17:41, Linus Torvalds wrote:
On Tue, May 5, 2015 at 8:22 AM, Michal Marek mma...@suse.cz 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
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
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
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
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.
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
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
On Tue, 2015-05-05 at 15:34 +0100, David Howells wrote:
Abelardo Ricart III aric...@memnix.com 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
On Tue, May 5, 2015 at 8:22 AM, Michal Marek mma...@suse.cz 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
On Tue, May 5, 2015 at 7:33 AM, David Howells dhowe...@redhat.com wrote:
Linus Torvalds torva...@linux-foundation.org wrote:
+define filechk_x509_list
+ echo $(X509_CERTIFICATES)
+endef
targets += $(obj)/.x509.list
-$(obj)/.x509.list:
- @echo $(X509_CERTIFICATES) $@
On 2015-05-04 20:45, Linus Torvalds wrote:
On Sun, May 3, 2015 at 6:45 PM, Linus Torvalds
torva...@linux-foundation.org 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
Linus Torvalds torva...@linux-foundation.org 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
David Howells dhowe...@redhat.com 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
Abelardo Ricart III aric...@memnix.com 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
Linus Torvalds torva...@linux-foundation.org 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
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
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
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
On Sun, 2015-05-03 at 22:16 -0700, Linus Torvalds wrote:
On May 3, 2015 21:42, Abelardo Ricart III aric...@memnix.com 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
On Sun, May 3, 2015 at 6:45 PM, Linus Torvalds
torva...@linux-foundation.org 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
On Sun, 2015-05-03 at 22:16 -0700, Linus Torvalds wrote:
On May 3, 2015 21:42, Abelardo Ricart III aric...@memnix.com 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
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
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
On Sun, 2015-05-03 at 18:45 -0700, Linus Torvalds wrote:
On Sat, May 2, 2015 at 2:46 AM, Abelardo Ricart III aric...@memnix.com
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
On Sat, May 2, 2015 at 2:46 AM, Abelardo Ricart III aric...@memnix.com 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
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
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
On Sat, May 2, 2015 at 6:12 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Fri, May 1, 2015 at 2:41 PM, Abelardo Ricart III aric...@memnix.com
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
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
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
On Fri, May 1, 2015 at 2:41 PM, Abelardo Ricart III aric...@memnix.com 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
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
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
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
On Thu, Apr 30, 2015 at 10:49 AM, Sedat Dilek sedat.di...@gmail.com 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.
On Thu, Apr 30, 2015 at 4:50 PM, David Howells dhowe...@redhat.com wrote:
Sedat Dilek sedat.di...@gmail.com 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
Sedat Dilek sedat.di...@gmail.com 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.
76 matches
Mail list logo
