Date   

Re: Installing gfortran into native sysroot for libgfortran

Khem Raj
 

On Wed, Jul 6, 2022 at 5:51 PM Gregory Anders <greg@...> wrote:

Hello,

I'm trying to compile libgfortran for a Xilinx Zynq SoC, which uses the arm-xilinx-linux-gnueabi toolchain.
I have added

FORTRAN:forcevariable = ",fortran"

to my local.conf, which causes libgfortran to be built, but it fails in the configure stage with an error that
it cannot find arm-xilinx-linux-gnueabi-gfortran. When I check the recipe-sysroot-native directory of
libgfortran I indeed see that gfortran is not there (but -gcc, -g++, etc. are).

Now I've been poking around the gcc recipe files trying to figure out why gfortran is
not being installed, but I am coming up empty. I'm hoping someone on list know how to do this.
How can I have gfortran installed into the native sysroot for libgfortran?
in your fortran app recipe you have to add DEPENDS = "libgfortran"


Thanks,

Greg


Installing gfortran into native sysroot for libgfortran

Gregory Anders <greg@...>
 

Hello,

I'm trying to compile libgfortran for a Xilinx Zynq SoC, which uses the arm-xilinx-linux-gnueabi toolchain.
I have added

    FORTRAN:forcevariable = ",fortran"

to my local.conf, which causes libgfortran to be built, but it fails in the configure stage with an error that
it cannot find arm-xilinx-linux-gnueabi-gfortran. When I check the recipe-sysroot-native directory of
libgfortran I indeed see that gfortran is not there (but -gcc, -g++, etc. are).

Now I've been poking around the gcc recipe files trying to figure out why gfortran is
not being installed, but I am coming up empty. I'm hoping someone on list know how to do this.
How can I have gfortran installed into the native sysroot for libgfortran?

Thanks,

Greg


Re: Minutes: Yocto Project Weekly Triage Meeting 6/30/2022

Randy MacLeod
 

On 2022-06-30 11:21, Sakib Sajal wrote:

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

Attendees: Stephen Jolley, Steve Sakoman, Joshua Watt, Saul Wold, Alexandre Belloni, Michael Opdenacker, Pavel Zhukov, Richard Purdie, Aryaman Gupta, Randy Macleod, Mahdi Shourabi.

ARs:

Randy: asssign bug 14829

This issue is understood, documented and resolved so
I closed the defect with a short explanation.

../Randy


Notes:
N/A

Medium+ 4.1 Unassigned Enhancements/Bugs: 73 (Last week 74)

Medium+ 4.99 Unassigned Enhancements/Bugs: 44 (Last week 45)

AB Bugs: 46 (Last week 47)


-- 
# Randy MacLeod
# Wind River Linux


Re: [PATCH yocto-autobuilder-helper 2/2] config.json: remove non-gpl3 job

Ross Burton
 

On 6 Jul 2022, at 15:13, Alexander Kanavin <alex.kanavin@...> wrote:
Where and how the decision was made?
Maybe ‘deprecated’ isn’t quite the right word to use here.

However, meta-gpl2 is unmaintained. It has no active maintainers, and is worked on only when absolutely needed: in the last year there’s been one actual bug fix, the rest of the commits were related to metadata changes to core (license, override syntax, etc).

By definition all of the software in meta-gplv2 is obsolete and almost certainly has security issues, but nobody is maintaining it.

This has been bought up both here repeatedly, and in the Members calls. Nobody has shown willing to adopt the layer, fix any outstanding security issues, and maintain it.

We likely need to discuss this again before formally deprecating it, but this shouldn’t be a surprise to anyone. Is there anyone who actually cares enough about meta-gplv2 to maintain it? This should be taken to oe-arch.

Ross


Re: [PATCH yocto-autobuilder-helper 2/2] config.json: remove non-gpl3 job

Alexander Kanavin
 

Where and how the decision was made?

Alex

On Wed, 6 Jul 2022 at 16:04, Ross Burton <ross.burton@...> wrote:

meta-gplv2 is deprecated, so remove it from the autobuilder in master.

Signed-off-by: Ross Burton <ross.burton@...>
---
config.json | 11 -----------
1 file changed, 11 deletions(-)

diff --git a/config.json b/config.json
index 7f7c2ad..c16812b 100644
--- a/config.json
+++ b/config.json
@@ -753,17 +753,6 @@
"BBTARGETS" : "build-appliance-image"
}
},
- "non-gpl3" : {
- "NEEDREPOS" : ["poky", "meta-gplv2"],
- "MACHINE" : "qemux86",
- "BBTARGETS" : "core-image-minimal core-image-full-cmdline",
- "extravars" : [
- "require conf/distro/include/disable-gplv3.inc"
- ],
- "EXTRACMDS" : [
- "../../yocto-autobuilder-helper/scripts/check-gplv3"
- ]
- },
"no-x11" : {
"MACHINE" : "qemux86-64",
"BBTARGETS" : "core-image-full-cmdline core-image-weston world",
--
2.25.1




[PATCH yocto-autobuilder-helper 2/2] config.json: remove non-gpl3 job

Ross Burton
 

meta-gplv2 is deprecated, so remove it from the autobuilder in master.

Signed-off-by: Ross Burton <ross.burton@...>
---
config.json | 11 -----------
1 file changed, 11 deletions(-)

diff --git a/config.json b/config.json
index 7f7c2ad..c16812b 100644
--- a/config.json
+++ b/config.json
@@ -753,17 +753,6 @@
"BBTARGETS" : "build-appliance-image"
}
},
- "non-gpl3" : {
- "NEEDREPOS" : ["poky", "meta-gplv2"],
- "MACHINE" : "qemux86",
- "BBTARGETS" : "core-image-minimal core-image-full-cmdline",
- "extravars" : [
- "require conf/distro/include/disable-gplv3.inc"
- ],
- "EXTRACMDS" : [
- "../../yocto-autobuilder-helper/scripts/check-gplv3"
- ]
- },
"no-x11" : {
"MACHINE" : "qemux86-64",
"BBTARGETS" : "core-image-full-cmdline core-image-weston wor=
ld",
--=20
2.25.1


[PATCH yocto-autobuilder-helper 1/2] config.json: remove meta-gplv2 from the check-layer job

Ross Burton
 

The meta-gplv2 layer is deprecated in master, so remove it from the
check-layer job.

Signed-off-by: Ross Burton <ross.burton@...>
---
config.json | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/config.json b/config.json
index afae5e9..7f7c2ad 100644
--- a/config.json
+++ b/config.json
@@ -857,7 +857,7 @@
"TEMPLATE" : "reproducible"
},
"check-layer" : {
- "NEEDREPOS" : ["poky", "meta-gplv2", "meta-mingw"],
+ "NEEDREPOS" : ["poky", "meta-mingw"],
"step1" : {
"EXTRACMDS" : ["yocto-check-layer-wrapper ../meta-poky"]
},
@@ -866,9 +866,6 @@
},
"step3" : {
"EXTRACMDS" : ["yocto-check-layer-wrapper ../meta-mingw"=
]
- },
- "step4" : {
- "EXTRACMDS" : ["yocto-check-layer-wrapper ../meta-gplv2"=
]
}
},
"check-layer-nightly" : {
--=20
2.25.1


Re: cve check report package version mismatch #yocto

Ross Burton
 

Re-adding yocto@.


This brings me to the handling of the "Unpatched" CVEs in the project. I can get some idea for which version of the package may have the mitigation for the CVE but there is no "mitigated_version" variable which helps me figure out the updated path in an automated way. I'm guessing that such a variable must be present internally in the cve_check class for it to detemine if the existing package version is lower than the mitigated version. Can I change the configuration for this information to also be printed in the cve log? This can probably also be added to the documentation (I don't mind volunteering for that)
It’s not always a trivial “this version”, there’s a fairly complex expression in the CVE (see the CPE entry) which needs to be evaluated. Or there may not be a fixed release, or the CVE needs configuration changes.

Basically, I don’t think it’s feasible to put a “fixed version” entry in the report that isn’t misleading. Whoever is reviewing the CVEs should actually read the CVE details and make a judgement on what to do.

Ross
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: cve check report package version mismatch #yocto

Marta Rybczynska
 

On Tue, Jul 5, 2022 at 2:31 PM <gauravsuman007@...> wrote:

I used the cve check class by including it in the local.conf and then ran the bitbake build process for my image. I got a log of all the detected CVEs in the packages used in the build. However, on closer inspection, I noticed that the packages used in the build are already higher version than when the CVE was patched. Here is an example:

LAYER: meta
PACKAGE NAME: libksba
PACKAGE VERSION: 1.6.0
CVE: CVE-2016-4355
CVE STATUS: Patched
Hello Gaurav,
The CVE STATUS "Patched" means that there was an issue in the past,
but it is either fixed or otherwise mitigated. Open issues are marked
as "Unpatched". If you'd like to see only Unpatched issues in the
report, please use CVE_CHECK_REPORT_PATCHED = "0" in your local.conf
or other place you have your OE configuration from.

Kind regards,
Marta


using Devtool upgrade with --no-patch subcommand #yocto #devtool

ksmanjunath681@...
 

Hi i am currently understanding devtool work flow with --no-patch command, i was able to use with recipes having only src_uri to repo url only, where has other recipes with 
SRC_URI appended with patch pointing to local location this is giving me error , :
 File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/scripts/devtool", line 334, in <module>
    ret = main()
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/scripts/devtool", line 321, in main
    ret = args.func(args, config, basepath, workspace)
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/scripts/lib/devtool/upgrade.py", line 552, in upgrade
    tinfoil, rd)
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/scripts/lib/devtool/upgrade.py", line 258, in _extract_new_source
    patches = oe.recipeutils.get_recipe_patches(crd)
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/meta/lib/oe/recipeutils.py", line 501, in get_recipe_patches
    patches = oe.patch.src_patches(d, expand=False)
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/meta/lib/oe/patch.py", line 814, in src_patches
    local = patch_path(url, fetch, workdir, expand)
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/meta/lib/oe/patch.py", line 788, in patch_path
    local = fetch.localpath(url)
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/bitbake/lib/bb/fetch2/__init__.py", line 1615, in localpath
    self.ud[url].setup_localpath(self.d)
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/bitbake/lib/bb/fetch2/__init__.py", line 1311, in setup_localpath
    self.localpath = self.method.localpath(self, d)
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/bitbake/lib/bb/fetch2/local.py", line 44, in localpath
    return self.localpaths(urldata, d)[-1]
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/bitbake/lib/bb/fetch2/local.py", line 55, in localpaths
    filespath = d.getVar('FILESPATH')
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/bitbake/lib/bb/data_smart.py", line 606, in getVar
    return self.getVarFlag(var, "_content", expand, noweakdefault, parsing)
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/bitbake/lib/bb/data_smart.py", line 804, in getVarFlag
    parser = self.expandWithRefs(value, cachename)
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/bitbake/lib/bb/data_smart.py", line 426, in expandWithRefs
    raise ExpansionError(varname, s, exc).with_traceback(tb) from exc
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/bitbake/lib/bb/data_smart.py", line 413, in expandWithRefs
    s = __expand_python_regexp__.sub(varparse.python_sub, s)
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/bitbake/lib/bb/data_smart.py", line 114, in python_sub
    return connector.expandPythonRef(self.varname, code, self.d)
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/bitbake/lib/bb/tinfoil.py", line 70, in expandPythonRef
    ret = self.tinfoil.run_command('dataStoreConnectorExpandPythonRef', ds, varname, expr)
 
    raise TinfoilCommandFailed(result[1])
bb.data_smart.ExpansionError: Failure expanding variable FILESPATH, expression was ${@base_set_filespath(["/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-meta-manju-tools/recipes-core/manju-utility/manju-utility-${PV}", "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-meta-s-manju-tools/recipes-core/manju-utility/manju-utility", "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-meta-s-tools/recipes-core/manju-utility/files"], d)} which triggered exception TinfoilCommandFailed: Traceback (most recent call last):
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/bitbake/lib/bb/command.py", line 74, in runCommand
    result = command_method(self, commandline)
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/bitbake/lib/bb/command.py", line 496, in dataStoreConnectorExpandPythonRef
    return varparse.python_sub(expr)
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/bitbake/lib/bb/data_smart.py", line 120, in python_sub
    codeobj = compile(code.strip(), varname, "eval")
  File "Var <FILESPATH>", line 1
    base_set_filespath(["/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-meta-manju-tools/recipes-core/manju-utility/manju-utility-${PV
                                                                                                                                                                                        ^
SyntaxError: EOL while scanning string literal
  File "/home/manju/Manjunath/AUH/pipeline/iteration_5/AUH_test/update_auh_flow/hgv-oss-yocto-poky/bitbake/lib/bb/tinfoil.py", line 466, in run_command
 

is there anything i am missing here .
 


Recommended boot method for system using rauc, intel and efi.

Anders Gnistrup
 

Hi all

I am building a yocto BSP for an Intel system. The system is using rauc for updating and contains three sections, rescue, A and B, where A/B is the actual SW running. Since the system is Intel based a decision how to organise the partitions layout is needed. Currently I am making a skeleton for the BSP.

This is the current layout
  • boot
  • rescue
  • A
  • B
In arm systems boot selection is handling via scripting/rauc/uboot in boot section. But in intel there are at least three options.
1) Legacy boot
This will create the layout above, but it will depend on legacy bios boot. This will require writing the MBR and pointing to the boot where grub scripting handles the rauc stuff. It seems like a bad solution to add MBR is the loop.

2) EFI entry always points to boot partition.
grub + scripting in the boot partition will do a similar operation like in the arm system. This solution gives quite a lot of flexibility, but will depend on SW.

3) pure EFI+efibootmgr. This will eliminate the boot partition and grub scripting but since EFI file format must be VFAT (EFI standard) the rescue, A and B partition needs a split. That is:
  • Boot rescue
  • rescue
  • Boot A
  • A
  • Boot B
  • B
rescue/factury default needs to write the boot entries to EFI-nvram. During runtime efibootmgr+rauc selects the next boot, rescue, A or B.
The grub scripting is replaced by efibootmgr and EFI entries in NVRAM.

And now my questions
Q1
My yocto builder is using the wks plugin to define the partition layout, https://docs.yoctoproject.org/singleindex.html#command-bootloader.
When setting the bootloader command it seems that the --configfile argument shall be used since there is no info in the EFI-nvram. WKS seems to work OK without the --configfile argument when building an installer image. Building a fixed disk containing an installer rescue image seems to be a bit too much for the logic.

Q2
I can't decide between 2 or 3 and I need some guidelines/idea.
2 is SW based while 3 is using the EFI system. Basically, the grub scripting is partly replacing the EFI system but will introduce a more complex partitions layout, a more complex rauc bundle and a more complex installation/rescue. The rescue partition shall be able to reset the system to factory default i.e. either reset entries in EFI-nvram or reset grub environment. Currently I am most up for grub scripting, solution 2, since all info is on the sata disk and not a combination of EFI-nvram and sata disk. Further it seems that the yocto support for efibootmgr, EFI-nvram and rauc is a bit bleeding edge.

Regards
Anders Gnistrup


Re: Unable to fetch repository from GitLab. Checksum mismatch

Quentin Schulz
 

Hi Rashmi,

You only need to add ;protocol=https to your SRC_URI which starts with git://.

git:// in SRC_URI is NOT the protocol used to download the sources, it is the way Bitbake knows which fetcher to use (in that case, the git fetcher). If you replace it with http, it's going to be the HTTP fetcher, which uses curl. It is not what you want to use for git repos.

c.f. https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-fetching.html#git-fetcher-git

Hope this helps,
Cheers,
Quentin

On 7/5/22 17:51, rashmi pisal via lists.yoctoproject.org wrote:
Hello,
I am building a software image and it fails when fetching a repository form GitLab. https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ajstarks_openvg&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=Uy8eY6eBlqV_AsuEY-zJDusZsvsTvDx2FOD4Nhn0s-1R6JDqU0aLQCXt1Sje117Y&s=kJKsWKz_K582lp2OiBXmm-8OF2OXSN90rZSBapaIU84&e=
Initially I was using git:// protocol to fetch the files but due to the GItLab ended support of git:// I am using https:// protocol. I am getting following error. Any help is appreciated. Thank you.
==================================================================
NOTE: Running task 2097 of 5013 (/var/lib/jenkins/workspace/yocto-rebound/meta-openembedded/meta-oe/recipes-graphics/gphoto2/libgphoto2_2.5.8.bb:do_patch)
NOTE: recipe libgphoto2-2.5.8-r0: task do_patch: Started
NOTE: recipe libgphoto2-2.5.8-r0: task do_patch: Succeeded
NOTE: Running task 2098 of 5013 (/var/lib/jenkins/workspace/yocto-rebound/meta-openembedded/meta-oe/recipes-support/glog/glog_0.3.4.bb:do_patch)
NOTE: recipe glog-0.3.4-r0: task do_patch: Started
NOTE: recipe glog-0.3.4-r0: task do_patch: Succeeded
NOTE: Running task 2099 of 5013 (/var/lib/jenkins/workspace/yocto-rebound/meta/recipes-devtools/perl/perl_5.24.1.bb:do_packagedata)
NOTE: recipe perl-5.24.1-r0: task do_packagedata: Started
NOTE: recipe perl-5.24.1-r0: task do_packagedata: Succeeded
NOTE: Running task 2100 of 5013 (/var/lib/jenkins/workspace/yocto-rebound/meta-rebound/recipes-bsp/openvg/openvg.bb:do_fetch)
NOTE: recipe openvg-1.0-r0: task do_fetch: Started
WARNING: openvg-1.0-r0 do_fetch: Checksum mismatch for local file /var/lib/jenkins/workspace/yocto-rebound/build/downloads/openvg
Cleaning and trying again.
WARNING: openvg-1.0-r0 do_fetch: Renaming /var/lib/jenkins/workspace/yocto-rebound/build/downloads/openvg to /var/lib/jenkins/workspace/yocto-rebound/build/downloads/openvg_bad-checksum_ddfeecef70433040e18ee9e68481e7f3
WARNING: openvg-1.0-r0 do_fetch: Checksum failure encountered with download of https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ajstarks_openvg&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=Uy8eY6eBlqV_AsuEY-zJDusZsvsTvDx2FOD4Nhn0s-1R6JDqU0aLQCXt1Sje117Y&s=kJKsWKz_K582lp2OiBXmm-8OF2OXSN90rZSBapaIU84&e= - will attempt other sources if available
ERROR: openvg-1.0-r0 do_fetch: Fetcher failure for URL: 'https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ajstarks_openvg&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=Uy8eY6eBlqV_AsuEY-zJDusZsvsTvDx2FOD4Nhn0s-1R6JDqU0aLQCXt1Sje117Y&s=kJKsWKz_K582lp2OiBXmm-8OF2OXSN90rZSBapaIU84&e= '. Checksum mismatch!
File: '/var/lib/jenkins/workspace/yocto-rebound/build/downloads/openvg' has md5 checksum ddfeecef70433040e18ee9e68481e7f3 when a8b34f242afbf3cac74fc7d34a496b24 was expected
If this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe:
SRC_URI[md5sum] = "ddfeecef70433040e18ee9e68481e7f3"
SRC_URI[sha256sum] = "7c67772c69b23d5b4cd298c7ddbf02938c3d11de04747c3243435e1463169669"
Otherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified.
ERROR: openvg-1.0-r0 do_fetch: Fetcher failure for URL: 'https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ajstarks_openvg&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=Uy8eY6eBlqV_AsuEY-zJDusZsvsTvDx2FOD4Nhn0s-1R6JDqU0aLQCXt1Sje117Y&s=kJKsWKz_K582lp2OiBXmm-8OF2OXSN90rZSBapaIU84&e= '. Unable to fetch URL from any source.
ERROR: openvg-1.0-r0 do_fetch: Function failed: base_do_fetch
ERROR: Logfile of failure stored in: /var/lib/jenkins/workspace/yocto-rebound/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/openvg/1.0-r0/temp/log.do_fetch.30930
NOTE: recipe openvg-1.0-r0: task do_fetch: Failed
ERROR: Task (/var/lib/jenkins/workspace/yocto-rebound/meta-rebound/recipes-bsp/openvg/openvg.bb:do_fetch) failed with exit code '1'
NOTE: Running task 2101 of 5013 (/var/lib/jenkins/workspace/yocto-rebound/meta-gplv2/recipes-extended/gawk/gawk_3.1.5.bb:do_prepare_recipe_sysroot)
NOTE: recipe gawk-3.1.5-r2: task do_prepare_recipe_sysroot: Started
NOTE: recipe gawk-3.1.5-r2: task do_prepare_recipe_sysroot: Succeeded
NOTE: recipe opencv-3.3+gitAUTOINC+87c27a074d_2a9d1b22ed_a62e20676a_34e4206aef_fccf7cd6a4-r0: task do_fetch: Succeeded
NOTE: Tasks Summary: Attempted 2101 tasks of which 0 didn't need to be rerun and 1 failed.
====================================================================================


Unable to fetch repository from GitLab. Checksum mismatch

rashmi pisal
 

Hello,

I am building a software image and it fails when fetching a repository form GitLab.  https://github.com/ajstarks/openvg

Initially I was using git:// protocol to fetch the files but due to the GItLab ended support of git:// I am using https:// protocol. I am getting following error. Any help is appreciated. Thank you.

==================================================================
NOTE: Running task 2097 of 5013 (/var/lib/jenkins/workspace/yocto-rebound/meta-openembedded/meta-oe/recipes-graphics/gphoto2/libgphoto2_2.5.8.bb:do_patch)
NOTE: recipe libgphoto2-2.5.8-r0: task do_patch: Started
NOTE: recipe libgphoto2-2.5.8-r0: task do_patch: Succeeded
NOTE: Running task 2098 of 5013 (/var/lib/jenkins/workspace/yocto-rebound/meta-openembedded/meta-oe/recipes-support/glog/glog_0.3.4.bb:do_patch)
NOTE: recipe glog-0.3.4-r0: task do_patch: Started
NOTE: recipe glog-0.3.4-r0: task do_patch: Succeeded
NOTE: Running task 2099 of 5013 (/var/lib/jenkins/workspace/yocto-rebound/meta/recipes-devtools/perl/perl_5.24.1.bb:do_packagedata)
NOTE: recipe perl-5.24.1-r0: task do_packagedata: Started
NOTE: recipe perl-5.24.1-r0: task do_packagedata: Succeeded
NOTE: Running task 2100 of 5013 (/var/lib/jenkins/workspace/yocto-rebound/meta-rebound/recipes-bsp/openvg/openvg.bb:do_fetch)
NOTE: recipe openvg-1.0-r0: task do_fetch: Started
WARNING: openvg-1.0-r0 do_fetch: Checksum mismatch for local file /var/lib/jenkins/workspace/yocto-rebound/build/downloads/openvg
Cleaning and trying again.
WARNING: openvg-1.0-r0 do_fetch: Renaming /var/lib/jenkins/workspace/yocto-rebound/build/downloads/openvg to /var/lib/jenkins/workspace/yocto-rebound/build/downloads/openvg_bad-checksum_ddfeecef70433040e18ee9e68481e7f3
WARNING: openvg-1.0-r0 do_fetch: Checksum failure encountered with download of https://github.com/ajstarks/openvg - will attempt other sources if available
ERROR: openvg-1.0-r0 do_fetch: Fetcher failure for URL: 'https://github.com/ajstarks/openvg'. Checksum mismatch!
File: '/var/lib/jenkins/workspace/yocto-rebound/build/downloads/openvg' has md5 checksum ddfeecef70433040e18ee9e68481e7f3 when a8b34f242afbf3cac74fc7d34a496b24 was expected
If this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe:
SRC_URI[md5sum] = "ddfeecef70433040e18ee9e68481e7f3"
SRC_URI[sha256sum] = "7c67772c69b23d5b4cd298c7ddbf02938c3d11de04747c3243435e1463169669"
Otherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified.

ERROR: openvg-1.0-r0 do_fetch: Fetcher failure for URL: 'https://github.com/ajstarks/openvg'. Unable to fetch URL from any source.
ERROR: openvg-1.0-r0 do_fetch: Function failed: base_do_fetch
ERROR: Logfile of failure stored in: /var/lib/jenkins/workspace/yocto-rebound/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/openvg/1.0-r0/temp/log.do_fetch.30930
NOTE: recipe openvg-1.0-r0: task do_fetch: Failed
ERROR: Task (/var/lib/jenkins/workspace/yocto-rebound/meta-rebound/recipes-bsp/openvg/openvg.bb:do_fetch) failed with exit code '1'
NOTE: Running task 2101 of 5013 (/var/lib/jenkins/workspace/yocto-rebound/meta-gplv2/recipes-extended/gawk/gawk_3.1.5.bb:do_prepare_recipe_sysroot)
NOTE: recipe gawk-3.1.5-r2: task do_prepare_recipe_sysroot: Started
NOTE: recipe gawk-3.1.5-r2: task do_prepare_recipe_sysroot: Succeeded
NOTE: recipe opencv-3.3+gitAUTOINC+87c27a074d_2a9d1b22ed_a62e20676a_34e4206aef_fccf7cd6a4-r0: task do_fetch: Succeeded
NOTE: Tasks Summary: Attempted 2101 tasks of which 0 didn't need to be rerun and 1 failed.
====================================================================================


Yocto Project Status 05 July 2022 (WW27)

Neal Caidin
 

Current Dev Position: YP 4.1 M2

Next Deadline: 11th July 2022 YP 4.1 M2 Build


Next Team Meetings:


Key Status/Updates:

  • Next week M2 is due to build so if anyone has changes for that milestone, please send ASAP.

  • YP 4.0.2 has been through QA and is likely to be released in the next few days.

  • A reproducibility issue was identified and raised a question on whether we could enable               an old QA check for these kinds of issues (‘buildpaths’ in insane.bbclass). Some bugs were fixed in the test but is has highlighted several reproducibility issues. Some have been fixed but others remain:

    • docs issues in lib32-vala, rpm, lib32-gtk-doc, vala, gtk-doc

    • musl issue in ltp

    • multilib issues in lib32-vala, vala, rpm (may overlap docs)

    • qemuarm64 kernel-devsrc issue (Bruce looking into)

    • meta-virt issues in xen-tools (Christopher looking into)

    • meta-gplv2 issues in mc, tar

    • lttng-modules .debug issue on beaglebone, edgerouter, and qemumips

  • Fixing these will allow us to enable buildpaths by default which should allow more people to spot reproducibility issues.

  • There is a discussion about layer setup tooling in the bitbake-layers discussion on the OE-Core list, input is welcome from those with an interest in this.

  • There is also a RFC series about improving the eSDK tooling workflows from Alex Kanavin which may be of interest.

  • Code to monitor the /proc/pressure interface has been added and there is a patch to optionally allow bitbake to reduce the number of processes running depending on system load, which it is hoped may help some of our autobuilder intermittent issues (thanks Aryaman and Randy).

  • Help is very much welcome in trying to resolve our autobuilder intermittent issues. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT


Ways to contribute:


YP 4.1 Milestone Dates:

  • YP 4.1 M2 build date 2022/07/11

  • YP 4.1 M2 Release date 2022/07/22

  • YP 4.1 M3 build date 2022/08/22

  • YP 4.1 M3 Release date 2022/09/02

  • YP 4.1 M4 build date 2022/10/03

  • YP 4.1 M4 Release date 2022/10/28


Upcoming dot releases:

  • YP 4.0.2 build date 2022/06/27 - pending TSC approval

  • YP 4.0.2 Release date 2022/07/08

  • YP 3.1.18 build date 2022/07/18

  • YP 3.1.18 Release date 2022/07/29

  • YP 4.0.3 build date 2022/08/08

  • YP 4.0.3 Release date 2022/08/19

  • YP 3.1.19 build date 2022/08/29

  • YP 3.1.19 Release date 2022/09/09

  • YP 4.0.4 build date 2022/09/19

  • YP 4.0.4 Release date 2022/09/30

  • YP 3.1.20 build date 2022/10/10

  • YP 3.1.20 Release date 2022/10/21

  • YP 4.0.5 build date 2022/10/31

  • YP 4.0.5 Release date 2022/11/11


Tracking Metrics:


The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC


The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status


[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]



Neal Caidin
Program Manager, Program Management & Operations
The Linux Foundation
+1 (919) 238-9104 (w/h)
+1 (919) 949-1861 (m)



Re: cve check report package version mismatch #yocto

Ross Burton
 

On 5 Jul 2022, at 13:31, gauravsuman007 via lists.yoctoproject.org <gauravsuman007=gmail.com@...> wrote:

I used the cve check class by including it in the local.conf and then ran the bitbake build process for my image. I got a log of all the detected CVEs in the packages used in the build. However, on closer inspection, I noticed that the packages used in the build are already higher version than when the CVE was patched. Here is an example:
• LAYER: meta
• PACKAGE NAME: libksba
• PACKAGE VERSION: 1.6.0
• CVE: CVE-2016-4355
• CVE STATUS: Patched
• CVE SUMMARY: Multiple integer overflows in ber-decoder.c in Libksba before 1.3.3 allow remote attackers to cause a denial of service (crash) via crafted BER data, which leads to a buffer overflow.
• CVSS v2 BASE SCORE: 5.0
• CVSS v3 BASE SCORE: 7.5
• VECTOR: NETWORK
• MORE INFORMATION: https://nvd.nist.gov/vuln/detail/CVE-2016-4355
As can be seen, the CVE was patched in version 1.3.3 of the libksba while the build is using the version 1.6.0.

Is there something wrong with what the cve-check is reporting or is it not bothering to match the version numbers before reporting a CVE? Or maybe my understanding of the report is incorrect?
I’m not sure I understand what your concern is. We have version 1.6.0, the CVE was fixed in 1.3.3, so the security issue has been patched.

The status is “patched” even if there’s not a literal patch in the recipe, it should be “mitigated” but we’d need to move to a new format to change the values.

Ross
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


cve check report package version mismatch #yocto

gauravsuman007@...
 

I used the cve check class by including it in the local.conf and then ran the bitbake build process for my image. I got a log of all the detected CVEs in the packages used in the build. However, on closer inspection, I noticed that the packages used in the build are already higher version than when the CVE was patched. Here is an example:
  • LAYER: meta
  • PACKAGE NAME: libksba
  • PACKAGE VERSION: 1.6.0
  • CVE: CVE-2016-4355
  • CVE STATUS: Patched
  • CVE SUMMARY: Multiple integer overflows in ber-decoder.c in Libksba before 1.3.3 allow remote attackers to cause a denial of service (crash) via crafted BER data, which leads to a buffer overflow.
  • CVSS v2 BASE SCORE: 5.0
  • CVSS v3 BASE SCORE: 7.5
  • VECTOR: NETWORK
  • MORE INFORMATION: https://nvd.nist.gov/vuln/detail/CVE-2016-4355
As can be seen, the CVE was patched in version 1.3.3 of the libksba while the build is using the version 1.6.0.

Is there something wrong with what the cve-check is reporting or is it not bothering to match the version numbers before reporting a CVE? Or maybe my understanding of the report is incorrect?

Would really appreciate a feedback on this, seeing as how the documentation on the cve checker is sparse.


Thanks,
Gaurav


Re: [PATCH yocto-autobuilder-helper] run-docs-build: allow build warnings again

Richard Purdie
 

On Tue, 2022-07-05 at 13:21 +0200, Quentin Schulz wrote:
Hi Richard, Michael,

On 7/4/22 16:23, Richard Purdie wrote:
On Mon, 2022-07-04 at 15:24 +0200, Quentin Schulz wrote:
Hi Michael,

On 6/22/22 17:32, Michael Opdenacker via lists.yoctoproject.org wrote:
From: Michael Opdenacker <michael.opdenacker@...>

This allows to switch to a more recent of Sphinx
which will generate warnings with old versions of docs.

This way, it's not immediately necessary to patch
all such versions.

This commit reverts
https://urldefense.proofpoint.com/v2/url?u=https-3A__git.yoctoproject.org_yocto-2Dautobuilder-2Dhelper_commit_-3Fid-3D8273124feb9da2ffe93fcee7c4529d5597e1684a&d=DwIDAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=je4C362aUVxZ2rdozdrQVTgzhi9iRYrxNfYtH5LHkXdlsay9SEphJ_ekBm4830_n&s=9u5-2R_NLEQy5w0pFgklKIUQnAvVLuHX1ASaeEBBJJ4&e=
which originally reverted
https://urldefense.proofpoint.com/v2/url?u=https-3A__git.yoctoproject.org_yocto-2Dautobuilder-2Dhelper_commit_-3Fid-3D931d409b255a85f2217ca093d8391a678ce00ddb&d=DwIDAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=je4C362aUVxZ2rdozdrQVTgzhi9iRYrxNfYtH5LHkXdlsay9SEphJ_ekBm4830_n&s=bTED2gTptfT6bSvLayy3fEpQJyUdbo5gLlt7ZGKkD1c&e=

Signed-off-by: Michael Opdenacker <michael.opdenacker@...>
---
scripts/run-docs-build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/run-docs-build b/scripts/run-docs-build
index 648a29d..0f74520 100755
--- a/scripts/run-docs-build
+++ b/scripts/run-docs-build
@@ -63,7 +63,7 @@ for branch in 1.46 $(git branch --remote --contains "$first_sphinx_commit" --for
git checkout $branch
git checkout master releases.rst
make clean
- make publish
+ SPHINXOPTS="-j auto" make publish

if [ "$branch" = "master-next" ]; then
branch="next"
@@ -136,7 +136,7 @@ for branch in dunfell $(git branch --remote --contains "$first_sphinx_commit" --
fi

make clean
- make publish
+ SPHINXOPTS="-j auto" make publish
What about doing this for all branches except master? To have at least
some checks and not completely disable the warnings.

I'm a bit afraid we'll just not care about warnings anymore since they
won't fail the autobuilder anymore. I also understand it's not really
sustainable to leave them on for old docs since they won't be maintained
at one point in time but we still very mnuch would like to be able to
build them.

Not sure what's the best solution here right now unfortunately :/
Enabling them for master could be a compromise, I'd take such a patch
(Michael is away for a while).
Some warnings are actually valid. Such is the case for the one that
warranted
https://git.yoctoproject.org/yocto-docs/commit/?id=9a797dedf6708da3e7ce789c5c8735e5d891cde4.
The issue is that we build the docs from old versions with the same
version of sphinx. Therefore, this patch fixes the issue in master but
should also be backported to all other impacted versions, even the
unmaintained ones. See
https://docs.yoctoproject.org/dunfell/dev-manual/dev-manual-common-tasks.html#recipe-syntax,
instead of a link we now have a path between quotes.

There are two ways to fix that one warning:
- add intersphinx_disabled_reftypes=[] in conf.py manually from the
run-docs-build script, c.f.
https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html#confval-intersphinx_disabled_reftypes
- patch all (tagged and branch) releases from 3.2 to current master in
scripts/docs-build-patches,

I prefer the second option because it feels less hacky, but that means
MANY times the same file added to docs-build-patches directory.

The same could be done for the patch I just sent for yocto-docs to use
the %s substitution characters for the cve extlinks to fix a warning. We
could just apply this patch to affected releases (kirkstone-4.0.1 tag +
kirkstone branch). I could technically request a backport to yocto-docs
kirkstone branch, the only thing I don't like is bumping the min version
requirement for sphinx for a release that was already released, but if
that's okay with you, we could avoid having to add patches in the
autobuilder for every new tagged release of kirkstone.

I'm honestly not sure there's a lot of benefit in disabling the warnings
for now, or enabling them only for select releases. I understand that
this increases the maintenance burden on unmaintained branches every
time we update the sphinx binary in the docs buildtools. However, we
missed this new broken link for almost a month now, which shows we don't
look at successful docs build logs from the autobuilder.
Perhaps it is time we split the master build from the stable releases
and used different buildtools tarballs for them?

That has it's own set of challenges of course too.

Cheers,

Richard


[meta-mingw] [PATCH] wayland: explicitly disable tests

Alexander Kanavin
 

This addresses the failure with wayland 1.21:
| ../wayland-1.21.0/tests/meson.build:2:1: ERROR: Problem encountered: -Dtests=true requires -Dlibraries=true

Signed-off-by: Alexander Kanavin <alex@...>
---
recipes-graphics/wayland/wayland_%.bbappend | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/recipes-graphics/wayland/wayland_%.bbappend b/recipes-graphics/wayland/wayland_%.bbappend
index e8ca57d..e4792b9 100644
--- a/recipes-graphics/wayland/wayland_%.bbappend
+++ b/recipes-graphics/wayland/wayland_%.bbappend
@@ -2,6 +2,5 @@
# compatible with i686 MinGW
PACKAGECONFIG:remove:mingw32:i686 = "dtd-validation"

-EXTRA_OECONF:class-nativesdk:mingw32 = "--disable-documentation --disable-libraries"
-EXTRA_OEMESON:class-nativesdk:mingw32 = "-Ddocumentation=false -Dlibraries=false"
+EXTRA_OEMESON:class-nativesdk:mingw32 = "-Ddocumentation=false -Dlibraries=false -Dtests=false"

--
2.30.2


Re: [PATCH yocto-autobuilder-helper] run-docs-build: allow build warnings again

Quentin Schulz
 

Hi Richard, Michael,

On 7/4/22 16:23, Richard Purdie wrote:
On Mon, 2022-07-04 at 15:24 +0200, Quentin Schulz wrote:
Hi Michael,

On 6/22/22 17:32, Michael Opdenacker via lists.yoctoproject.org wrote:
From: Michael Opdenacker <michael.opdenacker@...>

This allows to switch to a more recent of Sphinx
which will generate warnings with old versions of docs.

This way, it's not immediately necessary to patch
all such versions.

This commit reverts
https://urldefense.proofpoint.com/v2/url?u=https-3A__git.yoctoproject.org_yocto-2Dautobuilder-2Dhelper_commit_-3Fid-3D8273124feb9da2ffe93fcee7c4529d5597e1684a&d=DwIDAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=je4C362aUVxZ2rdozdrQVTgzhi9iRYrxNfYtH5LHkXdlsay9SEphJ_ekBm4830_n&s=9u5-2R_NLEQy5w0pFgklKIUQnAvVLuHX1ASaeEBBJJ4&e=
which originally reverted
https://urldefense.proofpoint.com/v2/url?u=https-3A__git.yoctoproject.org_yocto-2Dautobuilder-2Dhelper_commit_-3Fid-3D931d409b255a85f2217ca093d8391a678ce00ddb&d=DwIDAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=je4C362aUVxZ2rdozdrQVTgzhi9iRYrxNfYtH5LHkXdlsay9SEphJ_ekBm4830_n&s=bTED2gTptfT6bSvLayy3fEpQJyUdbo5gLlt7ZGKkD1c&e=

Signed-off-by: Michael Opdenacker <michael.opdenacker@...>
---
scripts/run-docs-build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/run-docs-build b/scripts/run-docs-build
index 648a29d..0f74520 100755
--- a/scripts/run-docs-build
+++ b/scripts/run-docs-build
@@ -63,7 +63,7 @@ for branch in 1.46 $(git branch --remote --contains "$first_sphinx_commit" --for
git checkout $branch
git checkout master releases.rst
make clean
- make publish
+ SPHINXOPTS="-j auto" make publish
if [ "$branch" = "master-next" ]; then
branch="next"
@@ -136,7 +136,7 @@ for branch in dunfell $(git branch --remote --contains "$first_sphinx_commit" --
fi
make clean
- make publish
+ SPHINXOPTS="-j auto" make publish
What about doing this for all branches except master? To have at least
some checks and not completely disable the warnings.

I'm a bit afraid we'll just not care about warnings anymore since they
won't fail the autobuilder anymore. I also understand it's not really
sustainable to leave them on for old docs since they won't be maintained
at one point in time but we still very mnuch would like to be able to
build them.

Not sure what's the best solution here right now unfortunately :/
Enabling them for master could be a compromise, I'd take such a patch
(Michael is away for a while).
Some warnings are actually valid. Such is the case for the one that warranted https://git.yoctoproject.org/yocto-docs/commit/?id=9a797dedf6708da3e7ce789c5c8735e5d891cde4. The issue is that we build the docs from old versions with the same version of sphinx. Therefore, this patch fixes the issue in master but should also be backported to all other impacted versions, even the unmaintained ones. See https://docs.yoctoproject.org/dunfell/dev-manual/dev-manual-common-tasks.html#recipe-syntax, instead of a link we now have a path between quotes.

There are two ways to fix that one warning:
- add intersphinx_disabled_reftypes=[] in conf.py manually from the run-docs-build script, c.f. https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html#confval-intersphinx_disabled_reftypes
- patch all (tagged and branch) releases from 3.2 to current master in scripts/docs-build-patches,

I prefer the second option because it feels less hacky, but that means MANY times the same file added to docs-build-patches directory.

The same could be done for the patch I just sent for yocto-docs to use the %s substitution characters for the cve extlinks to fix a warning. We could just apply this patch to affected releases (kirkstone-4.0.1 tag + kirkstone branch). I could technically request a backport to yocto-docs kirkstone branch, the only thing I don't like is bumping the min version requirement for sphinx for a release that was already released, but if that's okay with you, we could avoid having to add patches in the autobuilder for every new tagged release of kirkstone.

I'm honestly not sure there's a lot of benefit in disabling the warnings for now, or enabling them only for select releases. I understand that this increases the maintenance burden on unmaintained branches every time we update the sphinx binary in the docs buildtools. However, we missed this new broken link for almost a month now, which shows we don't look at successful docs build logs from the autobuilder.

Cheers,
Quentin


Re: [PATCH 1/2] image-without-static-linkage: add class

Quentin Schulz
 

Hi Johannes,

Thanks for the patch.

On 7/4/22 18:25, Johannes Schilling via lists.yoctoproject.org wrote:
This class provides a new image QA check that tries to detect static
linkage of a set of well-known libraries, leveraging the detectors from
cve-bin-tool[0].
To use in your project, provide a config file as described in the header
comment of the class, and inherit image-without-static-linkage in your
image recipe.
[0] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_intel_cve-2Dbin-2Dtool_tree_main_cve-5Fbin-5Ftool_checkers&d=DwIFAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=Hh9S5cawTgVqdeYOsBqc8rVaNr9ZaBpIWiDZ_AmMvLe1nDPvairY_aW0wkexnXFC&s=9KPe08w-rv38bJzJx3MOSvKRgtdKbTkKVUTuKQhTIZk&e=
---
classes/image-without-static-linkage.bbclass | 65 +++++++++
.../python/python3-packaging_%.bbappend | 1 +
.../cve-bin-tool/cve-bin-tool-native.bb | 34 +++++
.../files/cve-bin-tool-static-linkage-checker | 126 ++++++++++++++++++
4 files changed, 226 insertions(+)
create mode 100644 classes/image-without-static-linkage.bbclass
create mode 100644 recipes-devtools/python/python3-packaging_%.bbappend
create mode 100644 recipes-security/cve-bin-tool/cve-bin-tool-native.bb
create mode 100644 recipes-security/cve-bin-tool/files/cve-bin-tool-static-linkage-checker
diff --git a/classes/image-without-static-linkage.bbclass b/classes/image-without-static-linkage.bbclass
new file mode 100644
index 0000000..c6f2013
--- /dev/null
+++ b/classes/image-without-static-linkage.bbclass
@@ -0,0 +1,65 @@
+# Provide a QA check for statically linked copies of libraries.
+#
+# You need to provide a config file in TOML format and point the
+# variable `STATIC_LINKAGE_CHECK_CONFIG_FILE` to it.
+#
+# The file format is as follows
+# ```
+# [checkers]
+# modules = [
+# # list of checker module names of cve-bin-tool checkers lib to
+# # enable, i.e. file names in the cve_bin_tool/checkers subfolder.
+# # https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_intel_cve-2Dbin-2Dtool_tree_main_cve-5Fbin-5Ftool_checkers&d=DwIFAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=Hh9S5cawTgVqdeYOsBqc8rVaNr9ZaBpIWiDZ_AmMvLe1nDPvairY_aW0wkexnXFC&s=9KPe08w-rv38bJzJx3MOSvKRgtdKbTkKVUTuKQhTIZk&e=
+# "librsvg",
+# "zlib",
+# ]
+#
+# [exceptions]
+# ignore_dirs = [
+# # list of directories, everything under these is completely ignored
+# "/var/lib/opkg",
+# ]
+#
+# [exceptions.ignore_checks]
+# # for each binary path, a list of checkers from the global list to
+# # ignore for this binary (allowlist)
+# "/bin/ary/name" = [ "zlib" ],
+# ```
+
+IMAGE_QA_COMMANDS += "image_check_static_linkage"
+
+DEPENDS += "cve-bin-tool-native"
+
+inherit python3native
+
+
+STATIC_LINKAGE_CUSTOM_ERROR_MESSAGE ??= ""
+
+python image_check_static_linkage() {
+ import json
+ from pathlib import Path
+ import subprocess
+
+ from oe.utils import ImageQAFailed
+
+ check_result = subprocess.check_output(["cve-bin-tool-static-linkage-checker",
+ "--config", d.getVar("STATIC_LINKAGE_CHECK_CONFIG_FILE"),
+ d.getVar("IMAGE_ROOTFS"),
+ ])
+ check_result = json.loads(check_result)
+
+ deploy_dir = Path(d.getVar("DEPLOYDIR"))
+ deploy_dir.mkdir(parents=True, exist_ok=True)
+ image_basename = d.getVar("IMAGE_BASENAME")
+ stats_filename = "static_linkage_stats-" + image_basename + ".json"
+ with open(deploy_dir / stats_filename, "w") as stats_out:
+ json.dump(check_result, stats_out)
+
+ binaries_with_violations = {k: v for k, v in check_result.items() if v}
+ if binaries_with_violations:
+ msg = "Static linkage check: found {} violations".format(len(binaries_with_violations))
+ for violator, violations in binaries_with_violations.items():
+ msg += "\n{}: {}".format(violator, violations)
+
+ raise ImageQAFailed(msg, image_check_static_linkage)
+} > diff --git a/recipes-devtools/python/python3-packaging_%.bbappend
b/recipes-devtools/python/python3-packaging_%.bbappend
new file mode 100644
index 0000000..d6f5869
--- /dev/null
+++ b/recipes-devtools/python/python3-packaging_%.bbappend
@@ -0,0 +1 @@
+BBCLASSEXTEND += "native"
I would say to put this change directly in python3-packaging recipe, no need for a bbappend.

diff --git a/recipes-security/cve-bin-tool/cve-bin-tool-native.bb b/recipes-security/cve-bin-tool/cve-bin-tool-native.bb
new file mode 100644
index 0000000..3efbdf7
--- /dev/null
+++ b/recipes-security/cve-bin-tool/cve-bin-tool-native.bb
@@ -0,0 +1,34 @@
+SUMMARY = "Scanner for statically linked library copies"
+HOMEPAGE = "https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_intel_cve-2Dbin-2Dtool&d=DwIFAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=Hh9S5cawTgVqdeYOsBqc8rVaNr9ZaBpIWiDZ_AmMvLe1nDPvairY_aW0wkexnXFC&s=EeXrVAokCJc_mQJv65wsyoKKTcNPVZNUJoMzfnfECxg&e= "
+
+LICENSE = "GPL-3.0"
+LIC_FILES_CHKSUM = "file://LICENSE.md;md5=97a733ff40c50b4bfc74471e1f6ca88b"
+
+VERSION = "3.1"
+
+
+SRC_URI = "\
+ https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_intel_cve-2Dbin-2Dtool_archive_refs_tags_v-24-257BVERSION-257D.tar.gz&d=DwIFAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=Hh9S5cawTgVqdeYOsBqc8rVaNr9ZaBpIWiDZ_AmMvLe1nDPvairY_aW0wkexnXFC&s=Zsl7OBDrfnYUlSJUhoyVM9PfYwURRjvVRUVBqfi3hFM&e= \
+ file://cve-bin-tool-static-linkage-checker \
+"
+
+SRC_URI[md5sum] = "af6958f8be7f7ce0d2b5ddffa34a1aee"
+SRC_URI[sha256sum] = "c4faaa401a2605a0d3f3c947deaf01cb56b4da927bfc29b5e959cde243bf5daf"
+
+inherit python3native native
+
+S = "${WORKDIR}/cve-bin-tool-3.1"
+inherit setuptools3
+

I guess you could have all inherit in the same line (and also, pretty sure native class should be inherited last).

+RDEPENDS_${PN} = "\
RDEPENDS:${PN}

+ python3-rich-native \
+ python3-packaging-native \
+"
+
+do_install:append() {
+ install -m 0755 "${WORKDIR}/cve-bin-tool-static-linkage-checker" "${D}${bindir}"
+}
+FILES-${PN}:append = "${bindir}/cve-bin-tool-static-linkage-checker"
+
FILES:${PN}:append (also why append and not a simple += ?)

+do_configure[noexec] = "1"
+do_compile[noexec] = "1" > diff --git
a/recipes-security/cve-bin-tool/files/cve-bin-tool-static-linkage-checker b/recipes-security/cve-bin-tool/files/cve-bin-tool-static-linkage-checker
new file mode 100644
index 0000000..7da1b3b
--- /dev/null
+++ b/recipes-security/cve-bin-tool/files/cve-bin-tool-static-linkage-checker
@@ -0,0 +1,126 @@
+#!/usr/bin/env python3
+
We at least need SPDX license tag here.

+from importlib import import_module
+from pathlib import Path
+
+import argparse
+import json
+import subprocess
+import toml
+
This isn't a core module (yet?) as far as I could tell, so you're missing a DEPENDS/RDEPENDS on the python recipe/package that provides this python module.

On a side note, I'm not entirely sure we would like to maintain a wrapper script specific to OE/Yocto in here. Is there any chance of seeing this or some variant upstreamed to cve-bin-tool git repo instead?

Cheers,
Quentin

+
+def parse_args():
+ """
+ Parse command line arguments.
+ """
+ parser = argparse.ArgumentParser(
+ prog=sys.argv[0],
+ description="Checker for staticly linked copies of libraries",
+ )
+
+ parser.add_argument(
+ "directory",
+ help="Path to the directory to scan",
+ )
+
+ parser.add_argument(
+ "--config",
+ help="Path to the config file",
+ required=True,
+ )
+
+ return parser.parse_args()
+
+
+def list_input_files(rootdir):
+ """
+ Iterate over the input rootfs and find any file that is an executable ELF file, yielding their
+ names for the next step to iterate over.
+ """
+ import sys
+ with subprocess.Popen(
+ ["find", rootdir, "-type", "f", "-executable", "-printf", "/%P\\n"],
+ stdout=subprocess.PIPE,
+ ) as find:
+ for line in find.stdout:
+ executable_filename = line.decode().strip()
+ file_out = subprocess.check_output(["file", rootdir + executable_filename]).decode()
+ if "ELF " not in file_out:
+ continue
+
+ yield executable_filename
+
+
+# PurePath.is_relative_to was only added in python 3.9
+def _path_is_relative_to(subdir, base):
+ try:
+ subdir.relative_to(base)
+ return True
+ except ValueError:
+ return False
+
+
+def check_file(root_dir, filename, checkers, exceptions):
+ """
+ Check an executable file for traces of static linkage using all the checkers specified and
+ applying all exceptions specified.
+ """
+ full_filepath = root_dir + filename
+ strings_out = subprocess.check_output(["strings", full_filepath]).decode()
+
+ filepath = Path(filename)
+ if any(
+ _path_is_relative_to(Path(ex), filepath) for ex in exceptions["ignore_dirs"]
+ ):
+ return []
+
+ found_lib_versions = []
+ for checker_name, checker in checkers.items():
+ if filename in exceptions["ignore_checks"]:
+ if checker_name in exceptions["ignore_checks"][filename]:
+ continue
+
+ vi = checker().get_version(strings_out, filename)
+ if vi and vi["is_or_contains"] == "contains" and vi["version"] != "UNKNOWN":
+ found_lib_versions.append({checker_name: vi["version"]})
+
+ return found_lib_versions
+
+
+def _load_checker_class(mod_name):
+ """
+ Load a checker class given the module name.
+
+ The class and module name can be generated from each other (the setup.py file for cve-bin-tool
+ does the same), e.g. module `libjpeg_turbo` contains checker class `LibjpegTurboChecker`.
+ """
+ class_name = "".join(mod_name.replace("_", " ").title().split()) + "Checker"
+
+ mod = import_module(f"cve_bin_tool.checkers.{mod_name}")
+ return getattr(mod, class_name)
+
+
+def main():
+ """
+ Main entry point.
+ """
+ args = parse_args()
+ config = toml.load(args.config)
+
+ all_checkers = {
+ modname: _load_checker_class(modname)
+ for modname in config["checkers"]["modules"]
+ }
+
+ violations = {
+ f: check_file(args.directory, f, all_checkers, config["exceptions"])
+ for f in list_input_files(args.directory)
+ }
+
+ print(json.dumps(violations))
+
+
+if __name__ == "__main__":
+ import sys
+
+ sys.exit(main())

781 - 800 of 58199