Hello,
besides that calling rm on Linux is just snake oil, the patch below
still automatically hides the key used to sign modules and offers a
statistically good chance that the key sometimes might physically
disappear from the storage used to compile a kernel. So many people
still might cons
Am 23.01.2015 um 13:34 schrieb Alexander Holler:
4. With some scripting it should be possible to extract the public key
out of an existing binary kernel. So there is no real need to change the
already complicated build process which might make it even more
complicated.
BTW: With "more complica
Sorry, either I type too fast or I think too slow, so here is another
comment:
Am 23.01.2015 um 14:27 schrieb Alexander Holler:
Am 23.01.2015 um 13:56 schrieb David Howells:
One thing that you have to be careful of with your patch is that if
you turn
it on during development, this will drain
Am 23.01.2015 um 13:56 schrieb David Howells:
One thing that you have to be careful of with your patch is that if you turn
it on during development, this will drain the entropy pool from which you get
random numbers.
Hmm, I wonder how often people are compiling kernels and how much one
turn d
Alexander Holler wrote:
> 1. I have no idea about how distro maintainers do handle their private and
> public keys used to sign modules.
In Fedora and RHEL, at least, we use a one-off on-the-fly generated transient
key for each rpm build.
When a kernel is built by rpmbuild, the source directory
Am 23.01.2015 um 12:54 schrieb Alexander Holler:
Am 23.01.2015 um 12:43 schrieb Alexander Holler:
Am 23.01.2015 um 11:55 schrieb Michal Marek:
The .x509 file contains a certificate signed by the private key, but not
the private key. With some scripting, it can be used to verify the
module sig
Am 23.01.2015 um 12:43 schrieb Alexander Holler:
Am 23.01.2015 um 11:55 schrieb Michal Marek:
The .x509 file contains a certificate signed by the private key, but not
the private key. With some scripting, it can be used to verify the
module signatures.
Assuming that doesn't change (hopefull
Am 23.01.2015 um 11:55 schrieb Michal Marek:
On 2015-01-23 11:15, Alexander Holler wrote:
Am 23.01.2015 um 10:39 schrieb Alexander Holler:
Am 23.01.2015 um 10:24 schrieb Michal Marek:
+ @rm ./signing_key.priv
+ @rm ./signing_key.x509
Why do you need to delete the certificate?
On 2015-01-23 11:15, Alexander Holler wrote:
> Am 23.01.2015 um 10:39 schrieb Alexander Holler:
>> Am 23.01.2015 um 10:24 schrieb Michal Marek:
>>
+ @rm ./signing_key.priv
+ @rm ./signing_key.x509
>>>
>>> Why do you need to delete the certificate?
>>
>> No special reason.
>>
>> I'm just
Am 23.01.2015 um 10:39 schrieb Alexander Holler:
Am 23.01.2015 um 10:24 schrieb Michal Marek:
+ @rm ./signing_key.priv
+ @rm ./signing_key.x509
Why do you need to delete the certificate?
No special reason.
I'm just not sure (and too lazy to look it up) if it might contain the
p
Am 23.01.2015 um 10:24 schrieb Michal Marek:
>> +@rm ./signing_key.priv
>> +@rm ./signing_key.x509
>
> Why do you need to delete the certificate?
No special reason.
I'm just not sure (and too lazy to look it up) if it might contain the
private key too (like it's possible in pem files),
On 2015-01-23 02:20, Alexander Holler wrote:
> I usually throw away (delete) the key used to sign modules after having
> called make -jN (b)zImage modules && make -jN modules_install. Because I've
> got bored to always have to type rm signing_key.* afterwards, I've build
> this patch some time ago.
I usually throw away (delete) the key used to sign modules after having
called make -jN (b)zImage modules && make -jN modules_install. Because I've
got bored to always have to type rm signing_key.* afterwards, I've build
this patch some time ago.
As I'm not eager anymore to publish kernel patches,
13 matches
Mail list logo
