for this case the new changes only consider 1.1.1 from both 1.1.1i and 1.1.1b , do not takes the trailing "i" and "b" when comparing them , so these 2 version are treated as same version ( 1.1.1 ) when comparing them.
I expected this although knowing that compare version in this way can falsely report more CVE, but this can capture some corner case. >-----Original Message----- >From: Richard Purdie <[email protected]> >Sent: Tuesday, 26 January, 2021 6:10 AM >To: Lee, Chee Yang <[email protected]>; Steve Sakoman ><[email protected]>; [email protected]; yocto- >[email protected] >Subject: Re: [yocto-security] OE-core CVE metrics for master on Sun 24 Jan 2021 >07:15:01 AM HST > >I'm not sure its working. For example: > >https://nvd.nist.gov/vuln/detail/CVE-2019-1543 > >which says it applies to: > >1.1.0 to 1.1.0j >and >1.1.1 to 1.1.1b > >Master has 1.1.1i which is greater than 1.1.1b so we shouldn't be shown as at >risk >yet the CVE is listed. > >Cheers, > >Richard > >On Mon, 2021-01-25 at 02:39 +0000, Lee, Chee Yang wrote: >> The changes expose these, it ignored trailing character in this >> version compare ( "i" in this case for openssl_1.1.1i ) >> (CVE-2019-1543, CVE-2019-1547, CVE-2019-1549, CVE-2019-1551, >> CVE-2019-1552, CVE-2019-1563, CVE-2020-1967, CVE-2020-1971) behave >> this way because its difficult to define the trailing characters (like >> version 1.1b can be 1.1 beta or patched release 1.1b) >> >> >> NVD just updated these recently >> CVE-2013-0800, CVE-2020-14409, CVE-2020-14410 >> >> >> >> > -----Original Message----- >> > From: Richard Purdie <[email protected]> >> > Sent: Monday, 25 January, 2021 7:21 AM >> > To: Steve Sakoman <[email protected]>; openembedded- >> > [email protected]; [email protected] >> > Cc: Lee, Chee Yang <[email protected]> >> > Subject: Re: [yocto-security] OE-core CVE metrics for master on Sun >> > 24 Jan 2021 >> > 07:15:01 AM HST >> > >> > On Sun, 2021-01-24 at 07:18 -1000, Steve Sakoman wrote: >> > > Branch: master >> > > >> > > New this week: >> > > CVE-2013-0800: pixman >> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0800 * >> > > CVE-2019-1543: openssl >> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-1543 * >> > > CVE-2019-1547: openssl >> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-1547 * >> > > CVE-2019-1549: openssl >> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-1549 * >> > > CVE-2019-1551: openssl >> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-1551 * >> > > CVE-2019-1552: openssl >> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-1552 * >> > > CVE-2019-1563: openssl >> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-1563 * >> > > CVE-2020-14409: libsdl2 >> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-14409 * >> > > CVE-2020-14410: libsdl2 >> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-14410 * >> > > CVE-2020-1967: openssl >> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-1967 * >> > > CVE-2020-1971: openssl >> > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-1971 * >> > >> > Adding Chee Yang, did the recent cve-check change mean some version >> > comparisons regressed and exposed CVEs that shouldn't be in this >> > list, or were we making some we need to fix? Or did some other change >expose these? >> > >> > Cheers, >> > >> > Richard >> > >> > >> >> >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147240): https://lists.openembedded.org/g/openembedded-core/message/147240 Mute This Topic: https://lists.openembedded.org/mt/80091462/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
