[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <43df2c05083399f050990dda6260c049.squirrel@twosheds.infradead.org>
Date: Wed, 30 Mar 2016 16:45:55 -0000
From: "David Woodhouse" <dwmw2@...radead.org>
To: "David Howells" <dhowells@...hat.com>
Cc: "Tadeusz Struk" <tadeusz.struk@...el.com>, dhowells@...hat.com,
herbert@...dor.apana.org.au, smueller@...onox.de,
linux-api@...r.kernel.org, marcel@...tmann.org,
linux-kernel@...r.kernel.org, keyrings@...r.kernel.org,
linux-crypto@...r.kernel.org, dwmw2@...radead.org,
davem@...emloft.net
Subject: Re: [PATCH v3 7/7] crypto: AF_ALG - add support for key_id
> Tadeusz Struk <tadeusz.struk@...el.com> wrote:
>
>> + keyring = request_key(&key_type_asymmetric, key_name, NULL);
>> +
>> + err = -ENOKEY;
>> + if (IS_ERR(keyring))
>> + goto out;
>> +
>> + pkey = keyring->payload.data[asym_crypto];
>
> NAK. This is liable to crash in future. You may not assume that you know
> what keyring->payload.data[asym_crypto] points to.
>
> You may not use struct public_key outside of crypto/asymmetric_key/. It's
> the
> internal data of the software subtype. I'll move it out of the global
> header
> to remove the temptation;-).
>
> You must use accessor functions such as verify_signature(). Feel free to
> add
> further accessor functions such as query_asym_capabilities(),
> create_signature(), encrypt_blob() and decrypt_blob() or something like
> that.
Grr. This is not the first time this has been pointed out. And it
shouldn't have *needed* to be pointed out in the first place.
Please do not ignore review feedback.
Or common sense.
--
dwmw2
Powered by blists - more mailing lists