On Fri, 12 Mar 2021 09:01:36 +, David Howells said:
> Possibly I can add something like:
>
> clean-files := signing_key.pem x509.genkey
>
> inside the
>
> ifeq ($(CONFIG_MODULE_SIG_KEY),"certs/signing_key.pem")
> ...
> endif
Would that remove them on a 'make clean', or
Valdis Klētnieks wrote:
> So the root cause was: 'make mrproper doesn't clean certs/' out enough,
> and this chunk of certs/Makefile
> ...
> I admit not being sure how (or if) this should be fixed
It's tricky because CONFIG_MODULE_SIG_KEY may not point to a file, let alone a
file that was autoge
On Thu, 11 Mar 2021 12:04:19 +, David Howells said:
> EXTRACT_CERTS /usr/src/linux-next/"certs/signing_key.pem"
>
> but I don't know why. There are some odd quotes in your line also which may
> be related to the problem. The relevant config line looks the same:
>
> CONFIG_MODUL
David Howells wrote:
> I'll have to try with the aarch64 build, see if it's something in that that's
> the problem.
That works too... kind of. Building in the certs/ dir is fine - and all the
cert generation and extraction is done in the expected place, but the link
fails with errors like:
aar
Valdis Klētnieks wrote:
> So there's something weird going on with scripts/extract-cert when running
> as a userid other than the owner of the source tree.. I wonder if it's
> actually an OpenSSL issue...
I cloned next-20210311 as one user then built it as another user using:
LANG=C ni
On Thu, 11 Mar 2021 10:49:14 +, David Howells said:
> I wonder... Can you grab branch keys-cve-2020-26541-branch from:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/
>
> and try that? If that breaks, can you try dropping the top four commits?
[/usr/src/linux
I wonder... Can you grab branch keys-cve-2020-26541-branch from:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/
and try that? If that breaks, can you try dropping the top four commits?
David
On Thu, 11 Mar 2021 09:34:01 +, David Howells said:
> Valdis KlÄtnieks wrote:
>
> > What i *expected* was that multiple builds with different O= would each
> > generate themselves a unique signing key and put it in their own O=
> > directory
> > and stay out of each other's way.
>
> Hmmm...
Valdis Klētnieks wrote:
> What i *expected* was that multiple builds with different O= would each
> generate themselves a unique signing key and put it in their own O= directory
> and stay out of each other's way.
Hmmm... Works for me. I use separate build dirs all the time.
What version of t
So, I tried doing a 'make O=... allmodconfig', with a setup where the uid of
the build process had write permission to the O= directory, but intentionally
did *not* have write permission to the source tree (so they couldn't mess up
the tree - I got tired of having to repeatedly do 'make mrproper' b
10 matches
Mail list logo
