Keyrings Archive mirror
 help / color / mirror / Atom feed
From: Petr Pavlu <petr.pavlu@suse.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: David Howells <dhowells@redhat.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Daniel Gomez <da.gomez@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Aaron Tomlin <atomlin@atomlin.com>,
	keyrings@vger.kernel.org, linux-modules@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] sign-file: Remove support for signing with PKCS#7
Date: Wed, 12 Nov 2025 14:51:24 +0100	[thread overview]
Message-ID: <e624c242-b297-4bb7-a76a-cbb18b027472@suse.com> (raw)
In-Reply-To: <922480ff44bda3b6ecfda1ae780c659644560f94.camel@HansenPartnership.com>

On 11/11/25 5:53 PM, James Bottomley wrote:
> On Tue, 2025-11-11 at 16:48 +0100, Petr Pavlu wrote:
>> The PKCS#7 code in sign-file allows for signing only with SHA-1.
>> Since SHA-1 support for module signing has been removed, drop PKCS#7
>> support in favor of using only CMS.
> 
> The change log is a bit alarmist.  CMS really *is* PKCS7 and most
> literature will refer to CMS as PKCS7.  What you're really deprecating
> is the use of the PKCS7_sign() API which can only produce SHA-1
> Signatures ... openssl is fully capable of producing any hash PKCS7
> signatures using a different PKCS7_... API set but the CMS_... API is
> newer.
> 
> The point being the module signature type is still set to PKEY_ID_PKCS7
> so it doesn't square with the commit log saying "drop PKCS#7 support".
> What you really mean is only use the openssl CMS_... API for producing
> PKCS7 signatures.

Ok, I plan to update the description to the following in v2:

sign-file: Use only the OpenSSL CMS API for signing

The USE_PKCS7 code in sign-file utilizes PKCS7_sign(), which allows signing
only with SHA-1. Since SHA-1 support for module signing has been removed,
drop the use of the OpenSSL PKCS7 API by the tool in favor of using only
the newer CMS API.

The use of the PKCS7 API is selected by the following:

 #if defined(LIBRESSL_VERSION_NUMBER) || \
 	OPENSSL_VERSION_NUMBER < 0x10000000L || \
 	defined(OPENSSL_NO_CMS)
 #define USE_PKCS7
 #endif

Looking at the individual ifdefs:

* LIBRESSL_VERSION_NUMBER: LibreSSL added the CMS API implementation from
  OpenSSL in 3.1.0, making the ifdef no longer relevant. This version was
  released on April 8, 2020.

* OPENSSL_VERSION_NUMBER < 0x10000000L: OpenSSL 1.0.0 was released on March
  29, 2010. Supporting earlier versions should no longer be necessary. The
  file Documentation/process/changes.rst already states that at least
  version 1.0.0 is required to build the kernel.

* OPENSSL_NO_CMS: OpenSSL can be configured with "no-cms" to disable CMS
  support. In this case, sign-file will no longer be usable. The CMS API
  support is now required.

In practice, since distributions now typically sign modules with SHA-2, for
which sign-file already required CMS API support, removing the USE_PKCS7
code shouldn't cause any issues.

-- 
Thanks,
Petr

  reply	other threads:[~2025-11-12 13:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-11 15:48 [PATCH 0/2] module: Remove SHA-1 support for module signing Petr Pavlu
2025-11-11 15:48 ` [PATCH 1/2] " Petr Pavlu
2025-11-11 22:37   ` Aaron Tomlin
2025-11-11 15:48 ` [PATCH 2/2] sign-file: Remove support for signing with PKCS#7 Petr Pavlu
2025-11-11 16:53   ` James Bottomley
2025-11-12 13:51     ` Petr Pavlu [this message]
2025-11-12 15:05       ` James Bottomley
2025-11-12 15:36       ` David Howells
2025-11-12 15:47         ` James Bottomley
2025-11-12 15:52           ` David Howells
2025-11-12 15:58             ` James Bottomley
2026-02-02 11:24   ` [PATCH] sign-file, pkcs7: Honour the hash parameter to sign-file David Howells
2026-02-02 11:27     ` David Howells
2026-02-02 12:25     ` Petr Pavlu
2026-02-02 17:01       ` Sami Tolvanen
2025-11-11 16:22 ` [PATCH 0/2] module: Remove SHA-1 support for module signing Sami Tolvanen
2025-12-22 20:24 ` Sami Tolvanen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e624c242-b297-4bb7-a76a-cbb18b027472@suse.com \
    --to=petr.pavlu@suse.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=atomlin@atomlin.com \
    --cc=da.gomez@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=samitolvanen@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).