From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE997C07E99 for ; Mon, 5 Jul 2021 21:15:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9361061483 for ; Mon, 5 Jul 2021 21:15:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229991AbhGEVSY (ORCPT ); Mon, 5 Jul 2021 17:18:24 -0400 Received: from vmicros1.altlinux.org ([194.107.17.57]:47730 "EHLO vmicros1.altlinux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229987AbhGEVSY (ORCPT ); Mon, 5 Jul 2021 17:18:24 -0400 Received: from imap.altlinux.org (imap.altlinux.org [194.107.17.38]) by vmicros1.altlinux.org (Postfix) with ESMTP id A936672C8B4; Tue, 6 Jul 2021 00:15:45 +0300 (MSK) Received: from altlinux.org (sole.flsd.net [185.75.180.6]) by imap.altlinux.org (Postfix) with ESMTPSA id 515654A46ED; Tue, 6 Jul 2021 00:15:45 +0300 (MSK) Date: Tue, 6 Jul 2021 00:15:45 +0300 From: Vitaly Chikunov To: Mimi Zohar Cc: Mimi Zohar , Dmitry Kasatkin , linux-integrity@vger.kernel.org Subject: Re: [PATCH v7 3/3] ima-evm-utils: Read keyid from the cert appended to the key file Message-ID: <20210705211545.s2hzroeulcw7bfbm@altlinux.org> References: <20210701011323.2377251-1-vt@altlinux.org> <20210701011323.2377251-4-vt@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org Mimi, On Mon, Jul 05, 2021 at 04:04:52PM -0400, Mimi Zohar wrote: > On Thu, 2021-07-01 at 04:13 +0300, Vitaly Chikunov wrote: > > > > +/** > > + * read_keyid_from_key() - Read 32-bit keyid from the key file > > + * @keyid_be: Pointer to 32-bit value in network order (BE, unaligned). > > + * @keyfile: PEM file with private key with optionally appended x509 cert. > > + * Return: 0 on success and keyid_be is written; > > + * -1 on error, logged error message, and keyid_be isn't written. > > + */ > > +static int read_keyid_from_key(uint32_t *keyid_be, const char *keyfile) > > (With the new option "--keyid-from-cert" is this patch really still > needed?) Yes. Key+cert is a nice option and should be handy for users. Key is stored together with the cert which will verify them. Otherwise key format doesn't store keyid which is error prone. > The function name is a bit off. Both imaevm_read_keyid() and this > function are getting the keyid from a cert. There's also quite a bit > of code duplication between them. Refactoring the code might help. > For example, perhaps imaevm_read_keyid() could be a wrapper for > read_keyid_from_cert(). They have important difference too. Thus, its hard to refactor them into nested function that looked good and simple. This is third attempt. And it's like solving a unsolvable puzzle. imaevm_read_keyid() reads from cert-only file where cert could be PEM or DER encoded. It's failure if there is no cert, because user intended to read a cert. imaevm_read_keyid() reads from private key optionally combined with a cert (both are PEM-only). It's not failure if there is no cert. We want to save "duplicated" call to PEM_read_X509() but really it causes more convoluted internal logic. I tried to de-duplicate them as much as possible while remaining understandability. > Otherwise renaming this function to read_keyid_from_keyfile(), > read_appended_keyid() or read_appended_keyid_from_cert(), which is > really wordy, would be better. Ok. read_keyid_from_keyfile looks good. > > thanks, > > Mimi