[PATCH] certs: Redirect openssl error message to null device

From: Stefan Berger <stefanb@linux.ibm.com>

Address the following issue detected by the kernel test robot when
there's no certificate file at the time when checking for the type
of key in the cert:

Can't open certs/signing_key.pem for reading, No such file or directory

The simplest solution is to redirect openssl's stderr output to /dev/null.

Fixes: 28d62d945ded ("certs: Trigger creation of RSA module signing key if it's not an RSA key")
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reported-by: kernel test robot <redacted>
---
 certs/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/certs/Makefile b/certs/Makefile
index 72758684d254..e7ae3bd3be4a 100644
--- a/certs/Makefile
+++ b/certs/Makefile

@@ -65,7 +65,7 @@ openssl_available       = $(shell openssl help 2>/dev/null && echo yes)
 ifeq ($(CONFIG_MODULE_SIG_KEY),"certs/signing_key.pem")
 
 ifeq ($(openssl_available),yes)
-X509TEXT=$(shell openssl x509 -in $(CONFIG_MODULE_SIG_KEY) -text)
+X509TEXT=$(shell openssl x509 -in $(CONFIG_MODULE_SIG_KEY) -text 2>/dev/null)
 
 $(if $(findstring rsaEncryption,$(X509TEXT)),,$(shell rm -f $(CONFIG_MODULE_SIG_KEY)))
 endif

-- 
2.31.1

On 6/25/21 8:29 AM, Stefan Berger wrote:

From: Stefan Berger <stefanb@linux.ibm.com>

Address the following issue detected by the kernel test robot when
there's no certificate file at the time when checking for the type
of key in the cert:

Can't open certs/signing_key.pem for reading, No such file or directory

The simplest solution is to redirect openssl's stderr output to /dev/null.

Fixes: 28d62d945ded ("certs: Trigger creation of RSA module signing key if it's not an RSA key")
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reported-by: kernel test robot <redacted>

Jarkko,

can you please squash this patch into the one it fixes. Unfortunately 
when rebasing you will have to fix the subsequent patch from this merge 
error

ifeq ($(openssl_available),yes)
<<<<<<< HEAD
X509TEXT=$(shell openssl x509 -in $(CONFIG_MODULE_SIG_KEY) -text 
2>/dev/null)
=======
X509TEXT=$(shell openssl x509 -in $(CONFIG_MODULE_SIG_KEY) -text)
endif
 >>>>>>> 87e968848116 (certs: Add support for using elliptic curve keys 
for signing modules)

to this:


ifeq ($(openssl_available),yes)
X509TEXT=$(shell openssl x509 -in $(CONFIG_MODULE_SIG_KEY) -text 
2>/dev/null)
endif

Thanks.

    Stefan

On Fri, Jun 25, 2021 at 08:32:37AM -0400, Stefan Berger wrote:

On 6/25/21 8:29 AM, Stefan Berger wrote:

quoted

From: Stefan Berger <stefanb@linux.ibm.com>

Address the following issue detected by the kernel test robot when
there's no certificate file at the time when checking for the type
of key in the cert:

Can't open certs/signing_key.pem for reading, No such file or directory

The simplest solution is to redirect openssl's stderr output to /dev/null.

Fixes: 28d62d945ded ("certs: Trigger creation of RSA module signing key if it's not an RSA key")
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reported-by: kernel test robot <redacted>

Jarkko,

can you please squash this patch into the one it fixes. Unfortunately when
rebasing you will have to fix the subsequent patch from this merge error

ifeq ($(openssl_available),yes)
<<<<<<< HEAD
X509TEXT=$(shell openssl x509 -in $(CONFIG_MODULE_SIG_KEY) -text
2>/dev/null)
=======
X509TEXT=$(shell openssl x509 -in $(CONFIG_MODULE_SIG_KEY) -text)
endif

quoted

quoted

quoted

quoted

quoted

quoted

quoted

87e968848116 (certs: Add support for using elliptic curve keys for

signing modules)

to this:


ifeq ($(openssl_available),yes)
X509TEXT=$(shell openssl x509 -in $(CONFIG_MODULE_SIG_KEY) -text
2>/dev/null)
endif

Thanks.

   Stefan

The problem is that I have already a pending pull request, and merge window
is soon closing.

I think it's a better idea that I just drop these patches and send a new
pull request, and you should construct a new version of the series. This
cannot be a blocker for the rest of the patches (or even potential
blocker). We can consider the current patches not ready for mainline.

/Jarkko

On 6/29/21 4:12 PM, Jarkko Sakkinen wrote:

The problem is that I have already a pending pull request, and merge window
is soon closing.

I think it's a better idea that I just drop these patches and send a new
pull request, and you should construct a new version of the series. This
cannot be a blocker for the rest of the patches (or even potential
blocker). We can consider the current patches not ready for mainline.

I posted v7 based on what you had queue for the PR with the changes that 
I document for v7.

  Stefan

/Jarkko