Hi all,
Today's linux-next merge of the keys-next tree got a conflict in:
scripts/sign-file.c
between commit:
d7afd65b4acc7 ("sign-file: Use only the OpenSSL CMS API for signing")
from the modules tree and commit:
7ca1c9dcb7b0c ("modsign: Enable ML-DSA module signing")
from the keys-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc scripts/sign-file.c
index 16f2bf2e1e3ce,547b970972301..0000000000000
--- a/scripts/sign-file.c
+++ b/scripts/sign-file.c
@@@ -271,20 -314,46 +271,37 @@@ int main(int argc, char **argv
digest_algo = EVP_get_digestbyname(hash_algo);
ERR(!digest_algo, "EVP_get_digestbyname");
-#ifndef USE_PKCS7
-
+ unsigned int flags =
+ CMS_NOCERTS |
+ CMS_PARTIAL |
+ CMS_BINARY |
+ CMS_DETACHED |
+ CMS_STREAM |
+ CMS_NOSMIMECAP |
+ CMS_NO_SIGNING_TIME |
+ use_keyid;
+
+ if ((EVP_PKEY_is_a(private_key, "ML-DSA-44") ||
+ EVP_PKEY_is_a(private_key, "ML-DSA-65") ||
+ EVP_PKEY_is_a(private_key, "ML-DSA-87")) &&
+ OPENSSL_VERSION_MAJOR < 4) {
+ /* ML-DSA + CMS_NOATTR is not supported in openssl-3.5
+ * and before.
+ */
+ use_signed_attrs = 0;
+ }
+
+ flags |= use_signed_attrs;
+
/* Load the signature message from the digest buffer. */
- cms = CMS_sign(NULL, NULL, NULL, NULL,
- CMS_NOCERTS | CMS_PARTIAL | CMS_BINARY |
- CMS_DETACHED | CMS_STREAM);
+ cms = CMS_sign(NULL, NULL, NULL, NULL, flags);
ERR(!cms, "CMS_sign");
- ERR(!CMS_add1_signer(cms, x509, private_key, digest_algo,
- CMS_NOCERTS | CMS_BINARY |
- CMS_NOSMIMECAP | CMS_NOATTR |
- use_keyid),
+ ERR(!CMS_add1_signer(cms, x509, private_key, digest_algo, flags),
"CMS_add1_signer");
- ERR(CMS_final(cms, bm, NULL, CMS_NOCERTS | CMS_BINARY) != 1,
+ ERR(CMS_final(cms, bm, NULL, flags) != 1,
"CMS_final");
-#else
- pkcs7 = PKCS7_sign(x509, private_key, NULL, bm,
- PKCS7_NOCERTS | PKCS7_BINARY |
- PKCS7_DETACHED | use_signed_attrs);
- ERR(!pkcs7, "PKCS7_sign");
-#endif
-
if (save_sig) {
char *sig_file_name;
BIO *b;
On Fri, Jan 30, 2026 at 05:20:09PM +0000, Mark Brown wrote: > I fixed it up (see below) and can carry the fix as necessary. This > is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider cooperating > with the maintainer of the conflicting tree to minimise any particularly > complex conflicts. Also needs this (or something): From 6d9a82fe703a084c1dc0d5a1d184bea787aa7d9a Mon Sep 17 00:00:00 2001 From: Mark Brown <broonie@kernel.org> Date: Fri, 30 Jan 2026 17:56:06 +0000 Subject: [PATCH] keys: Merge fixup Signed-off-by: Mark Brown <broonie@kernel.org> --- scripts/sign-file.c | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/sign-file.c b/scripts/sign-file.c index a65c3e0c40b66..ef8a33ba9c529 100644 --- a/scripts/sign-file.c +++ b/scripts/sign-file.c @@ -206,6 +206,7 @@ int main(int argc, char **argv) bool raw_sig = false; unsigned char buf[4096]; unsigned long module_size, sig_size; + unsigned int use_signed_attrs = PKCS7_NOATTR; const EVP_MD *digest_algo; EVP_PKEY *private_key; CMS_ContentInfo *cms = NULL; -- 2.47.3
On Fri, Jan 30, 2026 at 10:12 AM Mark Brown <broonie@kernel.org> wrote: > > On Fri, Jan 30, 2026 at 05:20:09PM +0000, Mark Brown wrote: > > > I fixed it up (see below) and can carry the fix as necessary. This > > is now fixed as far as linux-next is concerned, but any non trivial > > conflicts should be mentioned to your upstream maintainer when your tree > > is submitted for merging. You may also want to consider cooperating > > with the maintainer of the conflicting tree to minimise any particularly > > complex conflicts. > > Also needs this (or something): > > From 6d9a82fe703a084c1dc0d5a1d184bea787aa7d9a Mon Sep 17 00:00:00 2001 > From: Mark Brown <broonie@kernel.org> > Date: Fri, 30 Jan 2026 17:56:06 +0000 > Subject: [PATCH] keys: Merge fixup > > Signed-off-by: Mark Brown <broonie@kernel.org> > --- > scripts/sign-file.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/scripts/sign-file.c b/scripts/sign-file.c > index a65c3e0c40b66..ef8a33ba9c529 100644 > --- a/scripts/sign-file.c > +++ b/scripts/sign-file.c > @@ -206,6 +206,7 @@ int main(int argc, char **argv) > bool raw_sig = false; > unsigned char buf[4096]; > unsigned long module_size, sig_size; > + unsigned int use_signed_attrs = PKCS7_NOATTR; This should be initialized to CMS_NOATTR. Sami
On Fri, Jan 30, 2026 at 10:13:42AM -0800, Sami Tolvanen wrote: > On Fri, Jan 30, 2026 at 10:12 AM Mark Brown <broonie@kernel.org> wrote: > > + unsigned int use_signed_attrs = PKCS7_NOATTR; > This should be initialized to CMS_NOATTR. Bah, I'll fix the fixup - thanks.
On Fri, Jan 30, 2026 at 9:20 AM Mark Brown <broonie@kernel.org> wrote:
>
> Hi all,
>
> Today's linux-next merge of the keys-next tree got a conflict in:
>
> scripts/sign-file.c
>
> between commit:
>
> d7afd65b4acc7 ("sign-file: Use only the OpenSSL CMS API for signing")
>
> from the modules tree and commit:
>
> 7ca1c9dcb7b0c ("modsign: Enable ML-DSA module signing")
>
> from the keys-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc scripts/sign-file.c
> index 16f2bf2e1e3ce,547b970972301..0000000000000
> --- a/scripts/sign-file.c
> +++ b/scripts/sign-file.c
> @@@ -271,20 -314,46 +271,37 @@@ int main(int argc, char **argv
> digest_algo = EVP_get_digestbyname(hash_algo);
> ERR(!digest_algo, "EVP_get_digestbyname");
>
> -#ifndef USE_PKCS7
> -
> + unsigned int flags =
> + CMS_NOCERTS |
> + CMS_PARTIAL |
> + CMS_BINARY |
> + CMS_DETACHED |
> + CMS_STREAM |
> + CMS_NOSMIMECAP |
> + CMS_NO_SIGNING_TIME |
> + use_keyid;
> +
> + if ((EVP_PKEY_is_a(private_key, "ML-DSA-44") ||
> + EVP_PKEY_is_a(private_key, "ML-DSA-65") ||
> + EVP_PKEY_is_a(private_key, "ML-DSA-87")) &&
> + OPENSSL_VERSION_MAJOR < 4) {
> + /* ML-DSA + CMS_NOATTR is not supported in openssl-3.5
> + * and before.
> + */
> + use_signed_attrs = 0;
> + }
> +
> + flags |= use_signed_attrs;
> +
> /* Load the signature message from the digest buffer. */
> - cms = CMS_sign(NULL, NULL, NULL, NULL,
> - CMS_NOCERTS | CMS_PARTIAL | CMS_BINARY |
> - CMS_DETACHED | CMS_STREAM);
> + cms = CMS_sign(NULL, NULL, NULL, NULL, flags);
> ERR(!cms, "CMS_sign");
>
> - ERR(!CMS_add1_signer(cms, x509, private_key, digest_algo,
> - CMS_NOCERTS | CMS_BINARY |
> - CMS_NOSMIMECAP | CMS_NOATTR |
> - use_keyid),
> + ERR(!CMS_add1_signer(cms, x509, private_key, digest_algo, flags),
> "CMS_add1_signer");
> - ERR(CMS_final(cms, bm, NULL, CMS_NOCERTS | CMS_BINARY) != 1,
> + ERR(CMS_final(cms, bm, NULL, flags) != 1,
> "CMS_final");
>
> -#else
> - pkcs7 = PKCS7_sign(x509, private_key, NULL, bm,
> - PKCS7_NOCERTS | PKCS7_BINARY |
> - PKCS7_DETACHED | use_signed_attrs);
> - ERR(!pkcs7, "PKCS7_sign");
> -#endif
> -
> if (save_sig) {
> char *sig_file_name;
> BIO *b;
Thanks, Mark. David, I see the patches in keys-next were updated just
a few hours ago. Would it make sense for you to rebase them on top of
next-20260129? Petr's patch removed the use_signed_attrs variable, so
we should ensure it's still initialized correctly. Otherwise the
resolution looks trivial.
Sami
On Fri, Jan 30, 2026 at 09:53:07AM -0800, Sami Tolvanen wrote: > Thanks, Mark. David, I see the patches in keys-next were updated just > a few hours ago. Would it make sense for you to rebase them on top of > next-20260129? Petr's patch removed the use_signed_attrs variable, so > we should ensure it's still initialized correctly. Otherwise the > resolution looks trivial. Please don't base anything on -next itself, that causes all kinds of problems and clearly isn't what you should be sending to Linus.
Mark Brown <broonie@kernel.org> wrote: > > Thanks, Mark. David, I see the patches in keys-next were updated just > > a few hours ago. Would it make sense for you to rebase them on top of > > next-20260129? Petr's patch removed the use_signed_attrs variable, so > > we should ensure it's still initialized correctly. Otherwise the > > resolution looks trivial. > > Please don't base anything on -next itself, that causes all kinds of > problems and clearly isn't what you should be sending to Linus. I was wondering if I should rebase on a merge between Eric's branch and Sami's branch and "pre-handle" the conflict. David
On Fri, Jan 30, 2026 at 09:50:36PM +0000, David Howells wrote: > Mark Brown <broonie@kernel.org> wrote: > > > Thanks, Mark. David, I see the patches in keys-next were updated just > > > a few hours ago. Would it make sense for you to rebase them on top of > > > next-20260129? Petr's patch removed the use_signed_attrs variable, so > > > we should ensure it's still initialized correctly. Otherwise the > > > resolution looks trivial. > > Please don't base anything on -next itself, that causes all kinds of > > problems and clearly isn't what you should be sending to Linus. > I was wondering if I should rebase on a merge between Eric's branch and Sami's > branch and "pre-handle" the conflict. That's not a problem for -next so long as neither of their branches get rebased and they're OK with that. Generally Linus prefers to do merges himself, though it's always a taste thing what makes most sense and in this case it's more that your new work is based on the merge of the two branches - they don't actually conflict at all IIRC.
On Fri, Jan 30, 2026 at 10:06 AM Mark Brown <broonie@kernel.org> wrote: > > On Fri, Jan 30, 2026 at 09:53:07AM -0800, Sami Tolvanen wrote: > > > Thanks, Mark. David, I see the patches in keys-next were updated just > > a few hours ago. Would it make sense for you to rebase them on top of > > next-20260129? Petr's patch removed the use_signed_attrs variable, so > > we should ensure it's still initialized correctly. Otherwise the > > resolution looks trivial. > > Please don't base anything on -next itself, that causes all kinds of > problems and clearly isn't what you should be sending to Linus. Sure, thanks for the clarification. Sami
Sami Tolvanen <samitolvanen@google.com> wrote: > Thanks, Mark. David, I see the patches in keys-next were updated just > a few hours ago. Would it make sense for you to rebase them on top of > next-20260129? Petr's patch removed the use_signed_attrs variable, so > we should ensure it's still initialized correctly. Otherwise the > resolution looks trivial. Wouldn't that mean having to rebase before sending to Linus? What's your branch that is being taken into linux-next? David
On Fri, Jan 30, 2026 at 9:57 AM David Howells <dhowells@redhat.com> wrote: > > Sami Tolvanen <samitolvanen@google.com> wrote: > > > Thanks, Mark. David, I see the patches in keys-next were updated just > > a few hours ago. Would it make sense for you to rebase them on top of > > next-20260129? Petr's patch removed the use_signed_attrs variable, so > > we should ensure it's still initialized correctly. Otherwise the > > resolution looks trivial. > > Wouldn't that mean having to rebase before sending to Linus? Do you plan to send these to Linus for 7.0-rc1? The patches already depend on libcrypto-next landing first, right? If the patches were last rebased 6h ago, I'm not sure if rebasing them on top of modules-next would significantly affect the linux-next soak time, but I'm fine either way. > What's your branch that is being taken into linux-next? https://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/log/?h=modules-next Sami
Sami Tolvanen <samitolvanen@google.com> wrote: > > Wouldn't that mean having to rebase before sending to Linus? > > Do you plan to send these to Linus for 7.0-rc1? Yes, hopefully. > The patches already depend on libcrypto-next landing first, right? Yes - if that was the only thing, I'd just ask Linus to pull them after that. > If the patches were last rebased 6h ago, I'm not sure if rebasing them on > top of modules-next would significantly affect the linux-next soak time, but > I'm fine either way. Rebasing on modules-next wouldn't work unless modules-next has Eric's branch merged in for the ML-DSA bits. I could maybe merge the two and rebase on that, but I think Linus isn't keen on that. David
On Fri, Jan 30, 2026 at 1:57 PM David Howells <dhowells@redhat.com> wrote: > > Sami Tolvanen <samitolvanen@google.com> wrote: > > > > Wouldn't that mean having to rebase before sending to Linus? > > > > Do you plan to send these to Linus for 7.0-rc1? > > Yes, hopefully. Ah, OK. I initially thought these might not be for the next release yet. In that case, it's probably just best to include the suggested resolution in the pull request and let Linus handle the conflict. Mark's changes looked correct to me. Sami
© 2016 - 2026 Red Hat, Inc.