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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHmME9p+-TMR4mywPH2wasY52fyBVGPpYmBwmn9aF0MF+14W8Q@mail.gmail.com>
Date:   Mon, 3 Jan 2022 04:45:10 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Herbert Xu <herbert@...dor.apana.org.au>
Cc:     linux-kernel@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        linux-kbuild@...r.kernel.org, linux-crypto@...r.kernel.org
Subject: Re: [PATCH v6] lib/crypto: blake2s: include as built-in

On 1/3/22, Herbert Xu <herbert@...dor.apana.org.au> wrote:
> At this point I think we should push this through crypto.  The
> changes are too invasive with respect to the crypto Kconfig files.

Ugh, can we please not? That will really make things much harder and
more annoying for me. I have an early pull planned, and you'll quickly
be able to rebase on top of it. It also doesn't appear to conflict
with anything you have queued up. Please, I would really appreciate
some straight forward linearity here, and I don't think my taking it
will negatively impact the flow.

>
>> diff --git a/crypto/Kconfig b/crypto/Kconfig
>> index 285f82647d2b..b7a2e50dcbc8 100644
>> --- a/crypto/Kconfig
>> +++ b/crypto/Kconfig
>> @@ -702,7 +702,7 @@ config CRYPTO_BLAKE2S
>>  	  See https://blake2.net for further information.
>>
>>  config CRYPTO_BLAKE2S_X86
>> -	tristate "BLAKE2s digest algorithm (x86 accelerated version)"
>> +	bool "BLAKE2s digest algorithm (x86 accelerated version)"
>>  	depends on X86 && 64BIT
>>  	select CRYPTO_LIB_BLAKE2S_GENERIC
>>  	select CRYPTO_ARCH_HAVE_LIB_BLAKE2S
>
> This will break when CRYPTO is disabled because the x86 crypto
> glue code depends on the crypto subsystem.

That snippet is inside an 'if CRYPTO' block, so it can't be selected
without CRYPTO being enabled.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ