Mikko et al, I think that we all agree here that we need to fix that database corruption.
BTW The Oniro team has worked to fix many issues from the list you mention, including frequent communication with NVD. Alberto and team have been stressing the tool more than most people before, I think. This is a good thing. And that they find bugs in the process... I agree that the cve-check does not give perfect security (after all, not all security issues have CVEs, and there is a delay between the CVE creation and the NVD update). Using it is the best recommendation we have for the users so it is in interest of all of us to make sure the check is working reliably. We don't want unnoticed security issues in our appliances, don't we? :) So, let's concentrate on "how"/"who" in the process of fixing this issue... Kind regards, Marta On Wed, Oct 12, 2022 at 12:03 PM Mikko Rapeli <mikko.rap...@linaro.org> wrote: > > Hi, > > I did not mean that yocto CVE checker is useless, or that bugs like > this should not be fixed. Using it is part of the best practice > processes for making secure products with yocto (even if it's currently > not documented as such). > > But we should also document that the CVE checker makes a LOT of > assumptions which are frequently broken in real life. poky tries to work well > with CVE checker but many other layers and recipes may not work at all. > > Few reasons are: > > * recipe name may not match to a CPE product name in the NVD database, > and CVE_PRODUCT may not be set > > * recipe versions PV may not be compatible with upstream version > numbers and hance the version range checks may fail > > * data in NVD is frequently wrong about the version ranges of CVEs > > And there are more corner cases. All these fail silently. > > Now you found a problem with the NVD download scripting which I think > needs to be fixed. But even if it works, developers who need to run > security checks on real products need to do more than just rely on > CVE check output. > > Cheers, > > -Mikko > > On Wed, Oct 12, 2022 at 11:51:28AM +0200, Carlo Piana wrote: > > [sent from the wrong account, resent, sorry for the noise] > > > > ----- Messaggio originale ----- > > > Da: "Mikko Rapeli" <mikko.rap...@linaro.org> > > > A: "Marta Rybczynska" <rybczyn...@gmail.com> > > > Cc: "Alexander Kanavin" <alex.kana...@gmail.com>, "Alberto Pianon" > > > <albe...@pianon.eu>, "OE-core" > > > <openembedded-core@lists.openembedded.org>, "marta rybczynska" > > > <marta.rybczyn...@linaro.org>, "Richard Purdie" > > > <richard.pur...@linuxfoundation.org>, "Carlo Piana" <ca...@piana.eu> > > > Inviato: Mercoledì, 12 ottobre 2022 10:04:07 > > > Oggetto: Re: [OE-core] severe issue in CVE checker > > > > > Hi, > > > > > > Can the downloads be turned into normal do_fetch() SRC_URI downloads > > > including > > > caches in yocto infrastructure? > > > > > > There are many issues around CVE checking that it's really > > > a process where a lot of details and uncertainties just need to be > > > accepted. It's far from a perfect and users just need to accept this. > > > > > > > > > > [...] > > > > I beg to (strongly, if I may) differ. > > > > CVE is broken? This is no excuse of course to ignore a known insecurity. > > > > Is it better to include a process that, when fails, the fail goes > > unnoticed, than nothing? No, "nothing" is better than flawed here, speaking > > of security, since a false sense of security is worse than insecurity > > itself. > > > > If we put a CVE checker that just throws in a contradictory message (a > > warning and eventually a "success" one) and then silently moves on without > > any fuss, we leave users in a state of false belief that they have > > completed at least the CVE checks -- however insufficient this may be -- > > but in reality it's a test that never fails because the database is empty > > or outdated. I agree that for developers CVE checking, compliance, software > > component inventory are a PITA, but it's way more a PITA when an attacker > > exploits an unpatched known insecurity kept out in the wild, or when a > > copyright troll comes after you demanding (many!) millions in damages (I > > can't disclose who has received it, but I have seen it in real life), > > because you failed to notice that a GPL component went into a > > mass-distribution device. > > > > Once the function is advertised, the expected behaviour for a thing of that > > importance must be to visibly flag the issue and **stand in the way** until > > you acknowledge it, so that the warning cannot be missed. It is up to the > > duly informed user to say "Ok, it's nothing, I know it" and shrug the > > problem off. Not a decision taken for the user by others and hidden under > > the carpet. We have several clients relying on that CVE checking and just > > by coincidence we noticed that something did not add up. God only knows how > > many times did this happen before. > > > > One can think it's not their problem, this is open source after all. But > > being open source is not total relief from liability. If you create a hole > > in the road and cover it with foliage, the fact that you are not paid to > > pave the road and you are doing it as a service for the community does not > > shield you if a car takes a nose-dive into it. > > > > I am sorry to intrude in the discussion so bluntly, but I prefer that the > > legal implications are correctly perceived before making a decision. > > > > All the best, > > > > Carlo > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171663): https://lists.openembedded.org/g/openembedded-core/message/171663 Mute This Topic: https://lists.openembedded.org/mt/94276393/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
