linux-kernel - Re: [PATCH v14 4/5] pkcs7, x509: Add ML-DSA support

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]

Message-ID: <1903448.1769426738@warthog.procyon.org.uk>
Date: Mon, 26 Jan 2026 11:25:38 +0000
From: David Howells <dhowells@...hat.com>
To: Jarkko Sakkinen <jarkko@...nel.org>
Cc: dhowells@...hat.com, Lukas Wunner <lukas@...ner.de>,
    Ignat Korchagin <ignat@...udflare.com>,
    Herbert Xu <herbert@...dor.apana.org.au>,
    Eric Biggers <ebiggers@...nel.org>,
    Luis Chamberlain <mcgrof@...nel.org>,
    Petr Pavlu <petr.pavlu@...e.com>, Daniel Gomez <da.gomez@...nel.org>,
    Sami Tolvanen <samitolvanen@...gle.com>,
    "Jason A . Donenfeld" <Jason@...c4.com>,
    Ard Biesheuvel <ardb@...nel.org>,
    Stephan Mueller <smueller@...onox.de>, linux-crypto@...r.kernel.org,
    keyrings@...r.kernel.org, linux-modules@...r.kernel.org,
    linux-kernel@...r.kernel.org
Subject: Re: [PATCH v14 4/5] pkcs7, x509: Add ML-DSA support

Jarkko Sakkinen <jarkko@...nel.org> wrote:

> Why don't we have a constant for "none"?
> 
> $ git grep "\"none\"" security/
> security/apparmor/audit.c:      "none",
> security/apparmor/lib.c:        { "none", DEBUG_NONE },
> security/security.c:    [LOCKDOWN_NONE] = "none",
> 
> $ git grep "\"none\"" crypto
> crypto/asymmetric_keys/public_key.c:                                    hash_algo = "none";
> crypto/asymmetric_keys/public_key.c:                            hash_algo = "none";
> crypto/testmgr.h: * PKCS#1 RSA test vectors for hash algorithm "none"
> 
> IMHO, this a bad practice.

You'd think that the compiler and linker ought to be able to deal with
read-only string sharing within compilation units.  I don't particularly want
to deal with combining every "none" string within the kernel into one within
this patchset.

I could move back to using an enum of algorithms, I suppose - though again,
I'd rather not do that in this patchset.

David