Date   

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())


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

Alexandre Belloni
 

Hello,

Both patches are missing your SoB, please add those. Also, It would be
great if you could add a From: as this makes it easier to get your patch
from the list. This should do the trick:

git config --global sendemail.from email@provider

Thanks!

On 04/07/2022 18:25:03+0200, 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://github.com/intel/cve-bin-tool/tree/main/cve_bin_tool/checkers
---
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://github.com/intel/cve-bin-tool/tree/main/cve_bin_tool/checkers
+# "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"
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://github.com/intel/cve-bin-tool"
+
+LICENSE = "GPL-3.0"
+LIC_FILES_CHKSUM = "file://LICENSE.md;md5=97a733ff40c50b4bfc74471e1f6ca88b"
+
+VERSION = "3.1"
+
+
+SRC_URI = "\
+ https://github.com/intel/cve-bin-tool/archive/refs/tags/v${VERSION}.tar.gz \
+ 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
+
+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"
+
+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
+
+from importlib import import_module
+from pathlib import Path
+
+import argparse
+import json
+import subprocess
+import toml
+
+
+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())
--
2.36.1


--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-4.0.2.rc1)

Teoh, Jay Shen
 

Hi All,

QA for yocto-4.0.2.rc1 is completed. This is the full report for this release:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.

No new issue found.

Thanks,
Jay

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Pokybuild User
Sent: Wednesday, 29 June, 2022 7:48 PM
To: yocto@...
Cc: qa-build-notification@...
Subject: [qa-build-notification] QA notification for completed autobuilder
build (yocto-4.0.2.rc1)


A build flagged for QA (yocto-4.0.2.rc1) was completed on the autobuilder
and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-4.0.2.rc1


Build hash information:

bitbake: b8fd6f5d9959d27176ea016c249cf6d35ac8ba03
meta-agl: c4cc627f4d65da8c3b0860c791d9b9687ba8f5d6
meta-arm: af928569b421431347c84f5941cee7aaa9f0ac74
meta-aws: 8b8eec4bde3b1ff00783503bd77b3a5fb7d904ec
meta-gplv2: d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
meta-intel: ef3aa3064b9bbfa19f600eafb1e7d3473f62af74
meta-mingw: a90614a6498c3345704e9611f2842eb933dc51c1
meta-openembedded: fcc7d7eae82be4c180f2e8fa3db90a8ab3be07b7
meta-virtualization: 320f44c6e9af463a85b58e0d87ca70273c6b87f6
oecore: eea52e0c3d24c79464f4afdbc3c397e1cb982231
poky: a5ea426b1da472fc8549459fff3c1b8c6e02f4b5



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...







M+ & H bugs with Milestone Movements WW27

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW27 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

13896

gtk-icon-cache.bbclass passes wrong parameter to update_gtk_icon_cache postinst intercept

randy.macleod@...

ross.burton@...

4.0.1

4.1 M2

 

14141

devtool modify fails with submodules

randy.macleod@...

ross.burton@...

4.0.1

4.1 M2

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW27!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

michael.opdenacker@...

3

randy.macleod@...

3

ross.burton@...

2

richard.purdie@...

2

Grand Total

10

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 4.1

Stephen Jolley
 

All,

Below is the list as of top 37 bug owners as of the end of WW27 of who have open medium or higher bugs and enhancements against YP 4.1.   There are 81 possible work days left until the final release candidates for YP 4.1 needs to be released.

Who

Count

michael.opdenacker@...

36

ross.burton@...

25

david.reyna@...

23

bruce.ashfield@...

21

randy.macleod@...

16

richard.purdie@...

10

saul.wold@...

10

JPEWhacker@...

9

sakib.sajal@...

9

tim.orling@...

7

Aryaman.Gupta@...

6

jon.mason@...

4

mhalstead@...

4

akuster808@...

3

sundeep.kokkonda@...

2

hongxu.jia@...

2

tvgamblin@...

2

Qi.Chen@...

2

pgowda.cve@...

2

pavel@...

2

alejandro@...

2

throos@...

1

behanw@...

1

luca.ceresoli@...

1

alexandre.belloni@...

1

shachar@...

1

mostthingsweb@...

1

martin.beeger@...

1

thomas.perrot@...

1

raj.khem@...

1

ola.x.nilsson@...

1

Martin.Jansa@...

1

Ahmed.Hossam@...

1

nicolas.dechesne@...

1

piotr.lobacz@...

1

open.source@...

1

aehs29@...

1

Grand Total

213

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 409 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now,  “4.1”, “4.2”, "4.99" and "Future", the more pressing/urgent issues being in "4.1" and then “4.2”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: dunfell do_image_wic error

Mauro Ziliani
 

Sorry for missing information


I get this error when I do


bitbake core-image-minimal


MZ

On 04/07/22 21:17, Mauro Ziliani wrote:
Hi all.

I update dunfell to last version.


But now I get a python exception error on do_image_wic task



| Traceback (most recent call last):
|   File "/home/yocto/sources/poky/scripts/lib/wic/filemap.py", line 457, in get_mapped_ranges
|     first_prev, last_prev = next(iterator)
| StopIteration
|
| The above exception was the direct cause of the following exception:
|
| Traceback (most recent call last):
|   File "/home/yocto/sources/poky/scripts/wic", line 542, in <module>
|     sys.exit(main(sys.argv[1:]))
|   File "/home/yocto/sources/poky/scripts/wic", line 537, in main
|     return hlp.invoke_subcommand(args, parser, hlp.wic_help_usage, subcommands)
|   File "/home/yocto/sources/poky/scripts/lib/wic/help.py", line 83, in invoke_subcommand
|     subcmd[0](args, usage)
|   File "/home/yocto/sources/poky/scripts/wic", line 219, in wic_create_subcommand
|     engine.wic_create(wks_file, rootfs_dir, bootimg_dir, kernel_dir,
|   File "/home/yocto/sources/poky/scripts/lib/wic/engine.py", line 190, in wic_create
|     plugin.do_create()
|   File "/home/yocto/sources/poky/scripts/lib/wic/plugins/imager/direct.py", line 96, in do_create
|     self.create()
|   File "/home/yocto/sources/poky/scripts/lib/wic/plugins/imager/direct.py", line 180, in create
|     self._image.prepare(self)
|   File "/home/yocto/sources/poky/scripts/lib/wic/plugins/imager/direct.py", line 354, in prepare
|     part.prepare(imager, imager.workdir, imager.oe_builddir,
|   File "/home/yocto/sources/poky/scripts/lib/wic/partition.py", line 182, in prepare
|     plugin.do_prepare_partition(self, srcparams_dict, creator,
|   File "/home/yocto/sources/poky/scripts/lib/wic/plugins/source/rawcopy.py", line 68, in do_prepare_partition
|     sparse_copy(src, dst)
|   File "/home/yocto/sources/poky/scripts/lib/wic/filemap.py", line 539, in sparse_copy
|     for first, last in fmap.get_mapped_ranges(0, fmap.blocks_cnt):
| RuntimeError: generator raised StopIteration

MZ



dunfell do_image_wic error

Mauro Ziliani
 

Hi all.

I update dunfell to last version.


But now I get a python exception error on do_image_wic task



| Traceback (most recent call last):
|   File "/home/yocto/sources/poky/scripts/lib/wic/filemap.py", line 457, in get_mapped_ranges
|     first_prev, last_prev = next(iterator)
| StopIteration
|
| The above exception was the direct cause of the following exception:
|
| Traceback (most recent call last):
|   File "/home/yocto/sources/poky/scripts/wic", line 542, in <module>
|     sys.exit(main(sys.argv[1:]))
|   File "/home/yocto/sources/poky/scripts/wic", line 537, in main
|     return hlp.invoke_subcommand(args, parser, hlp.wic_help_usage, subcommands)
|   File "/home/yocto/sources/poky/scripts/lib/wic/help.py", line 83, in invoke_subcommand
|     subcmd[0](args, usage)
|   File "/home/yocto/sources/poky/scripts/wic", line 219, in wic_create_subcommand
|     engine.wic_create(wks_file, rootfs_dir, bootimg_dir, kernel_dir,
|   File "/home/yocto/sources/poky/scripts/lib/wic/engine.py", line 190, in wic_create
|     plugin.do_create()
|   File "/home/yocto/sources/poky/scripts/lib/wic/plugins/imager/direct.py", line 96, in do_create
|     self.create()
|   File "/home/yocto/sources/poky/scripts/lib/wic/plugins/imager/direct.py", line 180, in create
|     self._image.prepare(self)
|   File "/home/yocto/sources/poky/scripts/lib/wic/plugins/imager/direct.py", line 354, in prepare
|     part.prepare(imager, imager.workdir, imager.oe_builddir,
|   File "/home/yocto/sources/poky/scripts/lib/wic/partition.py", line 182, in prepare
|     plugin.do_prepare_partition(self, srcparams_dict, creator,
|   File "/home/yocto/sources/poky/scripts/lib/wic/plugins/source/rawcopy.py", line 68, in do_prepare_partition
|     sparse_copy(src, dst)
|   File "/home/yocto/sources/poky/scripts/lib/wic/filemap.py", line 539, in sparse_copy
|     for first, last in fmap.get_mapped_ranges(0, fmap.blocks_cnt):
| RuntimeError: generator raised StopIteration

MZ

1261 - 1280 of 58671