linux-kernel - Re: [PATCH] MODSIGN: Change default key details [ver #2]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 05 May 2015 16:30:42 +0100
From:	David Howells <dhowells@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	dhowells@...hat.com, Abelardo Ricart III <aricart@...nix.com>,
	Michal Marek <mmarek@...e.cz>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Sedat Dilek <sedat.dilek@...il.com>, keyrings@...ux-nfs.org,
	Rusty Russell <rusty@...tcorp.com.au>,
	LSM List <linux-security-module@...r.kernel.org>,
	James Morris <james.l.morris@...cle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] MODSIGN: Change default key details [ver #2]

Linus Torvalds <torvalds@...ux-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 "X509_CERTIFICATES" thing is
> unstable, and ends up being "./signing_key.x509" or "signing_key.x509"
> depending on whether that file existed or not. That needs fixing, so
> that we get stable output. So some filtering required.

Yeah, the stability thing is a bit of an irritation.  X509_CERTIFICATES might
also include "$(srcdir)/signing_key.x509".  This is one of the things that has
given me difficulties because the source and build trees are sometimes the
same and sometimes not (and then throw in a symlink somewhere in the path...).
I was trying to use $(realpath ...) to deal with this - but that doesn't work
if the path doesn't point to an extant file:-/

Does it make sense to produce an error if the source and build trees are not
coincident and we see an x509 cert of the same filename cropping up in both?

Also X509_CERTIFICATES might hold other certs - though these shouldn't really
be seen in the build dir.  I wonder if we should enforce that to make life
easier.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/