[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-keyrings
Subject:    Re: [RFC][PATCH 3/6] verification: Introduce verify_umd_signature() and verify_umd_message_sig()
From:       Jarkko Sakkinen <jarkko () kernel ! org>
Date:       2023-04-26 18:27:00
Message-ID: c5bfefc4653226e24195f5c87499c3292ecc15f5.camel () kernel ! org
[Download RAW message or body]

On Wed, 2023-04-26 at 21:25 +0300, Jarkko Sakkinen wrote:
> On Wed, 2023-04-26 at 13:42 +0200, Roberto Sassu wrote:
> > On Wed, 2023-04-26 at 03:28 +0300, Jarkko Sakkinen wrote:
> > > On Tue Apr 25, 2023 at 8:35 PM EEST, Roberto Sassu wrote:
> > > > From: Roberto Sassu <roberto.sassu@huawei.com>
> > > > 
> > > > Introduce verify_umd_signature() and verify_umd_message_sig(), to verify
> > > > UMD-parsed signatures from detached data. It aims to be used by kernel
> > > > subsystems wishing to verify the authenticity of system data, with
> > > > system-defined keyrings as trust anchor.
> > > 
> > > UMD is not generic knowledge. It is a term coined up in this patch set
> > > so please open code it to each patch.
> > 
> > Yes, Linus also commented on this:
> > 
> > https://lwn.net/ml/linux-kernel/CAHk-=wihqhksXHkcjuTrYmC-vajeRcNh3s6eeoJNxS7wp77dFQ@mail.gmail.com/
> > 
> > I will check if the full name is mentioned at least once. So far, it
> > seems that using umd for function names should be ok.
> 
> Also: "UMD-based parser for the asymmetric key type"
> 
> It is a tautology:
> 
> UMD is based on parser which based on UMD.
> 
> I.e. makes no sense.
> 
> Everyone hates three letter acronyms so I would consider not
> inventing a new one out of the void.
> 
> So the corrective step would be to rename Kconfig flags as
> USER_ASYMMETRIC_KEY_PARSER and USER_ASYMMETRIC_SIGNATURE_PARSER.

(or along the lines)

BR, Jarkko
[prev in list] [next in list] [prev in thread] [next in thread]