Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759993AbbEEQK2 (ORCPT ); Tue, 5 May 2015 12:10:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42149 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2993403AbbEEPbK (ORCPT ); Tue, 5 May 2015 11:31:10 -0400 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: <1430516505-4812-1-git-send-email-aricart@memnix.com> <1430559977.5803.12.camel@memnix.com> <16612.1430836386@warthog.procyon.org.uk> To: Linus Torvalds Cc: dhowells@redhat.com, Abelardo Ricart III , Michal Marek , Linux Kernel Mailing List , Sedat Dilek , keyrings@linux-nfs.org, Rusty Russell , LSM List , James Morris , Greg Kroah-Hartman Subject: Re: [PATCH] MODSIGN: Change default key details [ver #2] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17604.1430839842.1@warthog.procyon.org.uk> Date: Tue, 05 May 2015 16:30:42 +0100 Message-ID: <17605.1430839842@warthog.procyon.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1539 Lines: 34 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 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/