Openembedded Core Discussions
 help / color / mirror / Atom feed
From: <Mikko.Rapeli@bmw.de>
To: <jeanbouch418@gmail.com>
Cc: <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] Package revision
Date: Tue, 8 Feb 2022 09:07:41 +0000	[thread overview]
Message-ID: <YgIy25oxLbkTU7eZ@korppu> (raw)
In-Reply-To: <HSvl.1644275900393526587.WGPn@lists.openembedded.org>

Hi,

On Mon, Feb 07, 2022 at 03:18:20PM -0800, jbouchard wrote:
> I was wondering why the package revision are not increasing when a patch is apply to other project source, like this commit https://git.openembedded.org/openembedded-core/commit/?h=honister&id=2d3c5b078feb34cb729902292d2805c9288ebc4c. Most distribution tend to increase the package revision when such changes occur. This help to track vulnerability and bugs. I know CVE_CHECK can deal with CVE, but it is hard to track with external software.

Yocto is different from other Linux distributions. There is no binary compatibility
between binary packages. Every single yocto build can break everything in compatibility.
Thus recipe version numbers don't matter that much, and it's not important to update
them as long as the major version number is matching to the SW component which is used.

As user of yocto, you can configure yocto build system to produce unique and monotonically
increasing binary package version numbers using prserv. This will update PR when ever recipes
are recompiled.

https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#working-with-a-pr-service

For CVE checks, the metadata in CVE patches marks the issues as patched when yocto internal
CVE checker is used. External CVE security issue detection tooling must take into account
the patches which have already been applied. Any tooling will be useless if they don't take
this into account. For security analysis work, it is best to follow what yocto upstream
maintainers do and use the same tooling as the basis, then maybe add your custom stuff
on top, or in best case contribute things back to the project. It's quite a bit of work
to maintain a large yocto based Linux distro well so you are better off if you work
with the community and maintainers there.

Cheers,

-Mikko

      reply	other threads:[~2022-02-08  9:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-07 23:18 Package revision jbouchard
2022-02-08  9:07 ` Mikko.Rapeli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YgIy25oxLbkTU7eZ@korppu \
    --to=mikko.rapeli@bmw.de \
    --cc=jeanbouch418@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox