[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <14284.1459355506@warthog.procyon.org.uk>
Date: Wed, 30 Mar 2016 17:31:46 +0100
From: David Howells <dhowells@...hat.com>
To: Tadeusz Struk <tadeusz.struk@...el.com>
Cc: 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.
David
Powered by blists - more mailing lists