Re: [OE-core] [PATCH 2/2] openssl: set CVE_VERSION_SUFFIX

["Mikko Rapeli" <mikko.rapeli@bmw.de>]

Hi,

On Wed, Jan 27, 2021 at 05:01:38PM +0000, Richard Purdie wrote:
> On Wed, 2021-01-27 at 09:12 +0000, Mikko Rapeli wrote:
> > On Wed, Jan 27, 2021 at 05:03:54PM +0800, Lee Chee Yang wrote:
> > > From: Lee Chee Yang <chee.yang.lee@intel.com>
> > > 
> > > Signed-off-by: Lee Chee Yang <chee.yang.lee@intel.com>
> > > ---
> > >  meta/recipes-connectivity/openssl/openssl_1.1.1i.bb | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> > > index 52e96b7831..9ff80b3d4f 100644
> > > --- a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> > > +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> > > @@ -230,6 +230,8 @@ BBCLASSEXTEND = "native nativesdk"
> > >  
> > > 
> > > 
> > > 
> > >  CVE_PRODUCT = "openssl:openssl"
> > >  
> > > 
> > > 
> > > 
> > > +CVE_VERSION_SUFFIX = "alphabetical"
> > > +
> > 
> > I have to say that I don't like this. I'd prefer automation
> > which works like dpkg --compare-versions:
> > 
> >        --compare-versions ver1 op ver2
> >               Compare version numbers, where op is a binary operator. dpkg returns true (0) if the specified condition is satisfied,
> >               and  false  (1)  otherwise.  There  are two groups of operators, which differ in how they treat an empty ver1 or ver2.
> >               These treat an empty version as earlier than any version: lt le eq ne ge gt. These treat an  empty  version  as  later
> >               than any version: lt-nl le-nl ge-nl gt-nl. These are provided only for compatibility with control file syntax: < << <=
> >               = >= >> >. The < and > operators are obsolete and should not be used, due to confusing semantics. To illustrate: 0.1 <
> >               0.1 evaluates to true.
> 
> The trouble is we have no control over what versions end up in the CPEs
> and I suspect that even dpkg's version comparison doesn't work for some
> of our test cases?

For example:

$ dpkg --compare-versions 1.1.1i lt 1.1.1j && echo true
true

dpkg can tell that 1.1.1i older version than 1.1.1j.

$ dpkg --compare-versions 1.1.1i lt 1.1.1e || echo not older
not older

and dpkg can tell that 1.1.1i is not older than 1.1.1e.

Hope this helps,

-Mikko

> If it does, it would be useful to understand how they're managing to do
> that as I think some of the patterns conflict as I understand it.
> 
> Debian can make it work for their packages since they control what
> version they ultimately assign to them.

Yes but the tool does seem to work for most SW version identifiers in Debian and
can deduce which one is newer. openssl version numbers work correctly out of the box.

Cheers,

-Mikko