On Wed, Apr 30, 2025 at 10:27:15AM +0800, Herbert Xu wrote: > On Tue, Apr 29, 2025 at 09:57:49AM -0700, Eric Biggers wrote: > > > > To be clear, the objections I have on your v2 patchset still hold. Your > > unsolicited changes to my patches add unnecessary complexity and redundancy, > > make the crypto_shash API even harder to use correctly, and also break the > > build > > for several architectures. If you're going to again use your maintainer > > privileges to push these out anyway over my objections, I'd appreciate it > > if you > > at least made your dubious changes as incremental patches using your own > > authorship so that they can be properly reviewed/blamed. > > Well the main problem is that your patch introduces a regression > in the shash sha256 code by making its export format differ from > other shash sha256 implementations (e.g., padlock-sha). > > So your first patch cannot stand as is. What I could do is split up > the first patch so that the lib/crypto sha stuff goes in by itself > followed by a separate patch replacing the crypto/sha256 code. > > > Please also note that I've sent a v4 which fixes the one real issue that my > > v1 > > patchset had: > > https://lore.kernel.org/r/20250428170040.423825-1-ebigg...@kernel.org > > Yes I've seen it but it still has the same issue of changing the > shash sha256 export format.
Nothing requires that the export formats be consistent, but also the fact that padlock-sha uses a weird format in the first place is an artificial problem that you introduced just a couple weeks ago. And even if we *must* use the same format as padlock-sha, that can be done by using your crypto_sha256_export_lib and crypto_sha256_import_lib, without all your other changes. - Eric
