Hi Carlo,
I'm a mere contributor, opinions are my own. I do not represent the
project's official view on this. Also, I am not a lawyer.
On 10/12/22 11:51, Carlo "Kappa" Piana wrote:
[sent from the wrong account, resent, sorry for the noise]
----- Messaggio originale -----
Da: "Mikko Rapeli" <[email protected]>
A: "Marta Rybczynska" <[email protected]>
Cc: "Alexander Kanavin" <[email protected]>, "Alberto Pianon" <[email protected]>,
"OE-core"
<[email protected]>, "marta rybczynska"
<[email protected]>, "Richard Purdie"
<[email protected]>, "Carlo Piana" <[email protected]>
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.
Thank you for reporting this. You already got an answer from the people
who worked on it. This is now known and hopefully we can fix it soon, it
depends on the contributors though (which you can become by sending a
patch :) ).
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.
You should not rely on this tool (or for that matter ANY tool from ANY
project) without human review from specialists (be they lawyers and/or
security researchers) on its output. If you need guarantees, get a
company to do it for you or hire teams of people. It will be expensive, yes.
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.
It actually does. It is the very essence of the open-source licenses
we're using. Mainly, MIT, c.f.
https://docs.yoctoproject.org/overview-manual/development-environment.html#licensing
By using our project, you're basically signing a waver form saying
"whatever happens I asked for it and cannot hold the project liable".
This applies to all (most?) pieces of SW that this project builds too.
https://opensource.org/licenses/mit-license.php states:
"THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."
It is YOUR duty to check whatever you're using is compliant
license-wise. It is absolutely possible a recipe we have advertises
being GPL-2.0-only and being actually GPL-3.0-or-later, we are human, we
make mistakes. Moreover, we are NOT lawyers, so we can misunderstand to
which files some licenses apply in a project for example.
Also, it's not because a piece of SW says it is licensed under a
specific license that it legally is (hello license poisoning for
example). We cannot as a project afford to look into all the pieces of
software we allow you to build to check if they are legally compliant
with whatever they say they are licensed under. This is a job for your
legal department. Also, since we allow third party layers to be used
with our core layers, it's not something we technically can do.
Now, about CVE checks, the same applies. We provide tools to make it
easier for you to check that some CVEs are fixed or not. It is legally
non-binding (see paragraphs above) and your legal and security
departments are the only ones able to "guarantee" CVEs are fixed or not.
The tools we provide are automated tools and as every software in the
world not perfect or free of bugs. We rely on people to report those
bugs (like you did, thank you for that) and/or fix them to improve those
tools. If you need to certify your project does not contain CVEs or CVEs
it is vulnerable to aren't usable, get a security research team to look
at your images.
I can understand that you are disappointed to see our project is not
bug-free but there's a big misunderstanding in what the project is
providing you with and what you can expect from it.
Yes, legal and security teams are expensive. But they provide
"guarantees" that we'll never provide (see open-source licenses).
Cheers,
Quentin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171664):
https://lists.openembedded.org/g/openembedded-core/message/171664
Mute This Topic: https://lists.openembedded.org/mt/94276393/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
