Layer list's certificate expired
Andreas Müller
Hi,
On opening OE-layers browsers complain that certificate has expired yesterday 13.th of May. Just wanted to let you know. Cheers, Andreas
|
|
Yocto Technical Team Minutes, Engineering Sync, for May 11, 2021
Trevor Woerner
Yocto Technical Team Minutes, Engineering Sync, for May 11, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit == announcements == The upcoming Yocto Project Summit is taking place May 25-26 2021 details: https://www.yoctoproject.org/yocto-project-virtual-summit-2021/ registration: https://www.cvent.com/d/yjq4dr/4W?ct=868bfddd-ca91-46bb-aaa5-62d2b61b2501 == disclaimer == Best efforts are made to ensure the below is accurate and valid. However, errors sometimes happen. If any errors or omissions are found, please feel free to reply to this email with any corrections. == attendees == Trevor Woerner, Stephen Jolley, Armin Kuster, Scott Murray, Joshua Watt, Randy MacLeod, Bruce Ashfield, Tony Tascioglu (WR intern), Trevor Gamblin, Steve Sakoman, Alexander Belloni, Michael Halstead, Paul Barker, Ross Burton, Tim Orling, Saul Wold, Jere Viikari, Alejandro H == notes == - 3.2.4 in QA, out in a couple days (this will be the final 3.2 release, aka gatesgarth) - significant patches going into master, lots of version updates (thanks AlexK) - multiconfig changes in bitbake cause challenges - some CVEs showed up that could use help - smp for various qemu machines added/enabled - should we consider a different default qemu emulation (for arm?) - serial IRQ handling issues with qemu-ppc - gnome switched from gtk to ?? == general == AlexB: I’ve been looking into some of the intermittent AB issues, i believe a couple of them can be closed now. there appear to be a lot of duplicates (same issue, different manifestations) Randy: good to hear, how many issues? AlexB: we can look at them in the bug triage meeting. i’m guessing it’s getting better. there are very few that happen regularly, and many others happen only once. maybe 4 or 5 race conditions that are infrequent. the improtant ones are qemu not working properly and the io load issue(s). i’d like to get some graphs to visualize. there are issues related to running out of memory, so maybe the solution is to not run so many things at once Randy: we used to use top to analyse what’s going on, but it’s tedious. instead we can look at the tail of the cooker log that gives more information, but is missing the total view of what’s going on at a given time slice. we need a list of bitbake tasks and where to find their cooker logs. once we have that the next step is to figure out who is doing all the I/O. we’ve been looking at a tool called iotop, but i don’t think that’s what we want. RP: iotop is probably what we want, but requires root priv RP: x86 cpu machine arguments in qemu RP: i think all these RCU stalls we’re seeing is due to the cpu emulation we’re using (which is very old) when we enabled SMP it caused everything to fall over the edge and fail everywhere. maybe the qemu process is locked up, rather than the system being overloaded Randy: interesting theory RP: i have a patch in master-next to upgrade to ivy-bridge qemu emulation. i guess we’ll see what happens AlexB: i don’t think it’ll solve all issues. we’ve seen RCU stalls on other qemu machines, not just x86 (mips, arm64, arm) RP: i thought it was just x86 AlexB: i have the list, i can confirm that we’ve seen rcu stalls on qemuarm at least RP: maybe there’s a pattern where the logs stop, then we get the rcu stall kicking in. it could be we have 2 issues which are interfering with each other. i’m not ready to give up on the theory yet AlexB: it’s probably still useful to do regardless RP: yes, i think we need to do it anyway. it won’t solve the ptest failures on qemuarm, for example, but might help with others Ross: the qemu person i talked with said that on a heavily loaded system you'd expect some level of rcu stalls RP: but should rcu stalls take out qemu? Bruce: it should recover AlexB: i’m not sure that’s a kernel thing that would kill it JPEW: is it possible that because there’s too many rcu stalls that we end up running out of memory Bruce: we could turn rcu off and see if it recovers RP: we should check if it recovers, or if it’s hanging. there might be 2 patterns here. this morning there was a lockup but there was no stack trace JPEW: is there a way to force the kernel to process all rcu’s? ??: i think that’s what it’s doing AlexB: it’s the rcu stall detection. the cpu has been stalled for too long. it’s not an issue with rcu itself, it’s just that rcu is what’s noticed that the cpu has stopped responding Randy: so ideally it would be nice to detect this ourselves and shed load before the stalls happen JPEW: tweak stall detection time? ??: takes about 80 seconds AlexB: 20 seconds i think JPEW: 21 seconds, according to docs. looks like it can be set on kernel cmdline Randy: heavily loaded system for cpu and io, tweaking the params isn’t going to fix the issue RP: it might help guide the debugging, might get more info turning on smp Randy: been talking with TrevorG about job server. might get started next week Randy: Saul are you getting back to qemu machine protocol Saul: looking at it Randy: how do you test it Saul: don’t have a strong hold on it yet RP: there is a hanging qemu on the AB, and it should have had the qmp patches applied. so in theory there’s one there that we might be able to interrogate Saul: could you point me at it again? RP: qemu-x86-64 on the AB, it should still be running TW: topic ideas for OEDVM PaulB: is there a way to just join the developer’s meeting without attending the whole conference? Armin: lgtm.com bitbake/yp is listed there. i sent in some patches to improve the metrics Armin: see https://lgtm.com/projects/g/openembedded/bitbake?mode=list Armin: 31 errors, 80 warnings, 234 recommendations (currently) ScottM: maybe we could do a checkpatch type thing for python linting Armin: there is an integration with github, but requires corporate github AlexB: should we open newcomer bugs? Armin: we could, it tells you exactly where the problem is and what to do ScottM: we don’t have tests, so fixes could end up breaking more things AlexB: maybe we need test cases for bitbake/toaster/etc Randy: our build quality is amazing! currently 0.2% build failures (mostly running out of memory)
|
|
Re: Yocto with xtensa
On 5/12/21 11:45 PM, Jack Daniels wrote:
Hello Khem,I can think of few ways build your Xtensa firmware outside yocto and let yocto package it via recipes for prebuilts and build ARM system with yocto should work well second option is to integrate Xtensa support into OE and then use multiconfig feature to build firmware for heterogenous systems. this will be preferred and forward looking for future but it will be more work Thank you.
|
|
Re: [meta-zephyr][PATCH 1/1] zephyr-qemuboot.bbclass: Fix runqemu dependency on qemu native sysroot
Andrei Gherzan
Hi Ross, On Thu, 13 May 2021, at 13:37, Andrei Gherzan wrote:
https://lists.yoctoproject.org/g/yocto/message/53508 should fix it. -- Andrei Gherzan gpg: rsa4096/D4D94F67AD0E9640
|
|
[meta-zephyr][PATCH 2/2] zephyr-qemuboot.bbclass: Remove dependency on qemu-system-native
Andrei Gherzan
From: Andrei Gherzan <andrei.gherzan@huawei.com>
runqemu only really needs the sysroot for qemu-helper-native. Pulling other qemu dependency would get into a racing issue with rm_work. That can also be fixed by tweaking the do_addto_recipe_sysroot order in oe-core for qemu-system-native but that is just not needed for this specific dependency requirement. Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com> --- classes/zephyr-qemuboot.bbclass | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/classes/zephyr-qemuboot.bbclass b/classes/zephyr-qemuboot.bbclass index f508b45..c268e9e 100644 --- a/classes/zephyr-qemuboot.bbclass +++ b/classes/zephyr-qemuboot.bbclass @@ -36,19 +36,18 @@ python do_bootconf_write() { addtask do_bootconf_write before do_build after do_deploy -# The runqemu script requires the native sysroot populated for the qemu -# recipes. Usually, this is pulled in by a do_image dependency (see -# baremetal-helloworld_git, for example), but in this case, there is no such -# task, so we hook in the dependency to do_bootconf_write. This also ensures -# that builds from sstate will also have this requirement satisfied. +# The runqemu script requires the native sysroot populated for the +# qemu-helper-native recipes. Usually, this is pulled in by a do_image +# dependency (see baremetal-helloworld_git, for example), but in this case, +# there is no such task, so we hook in the dependency to do_bootconf_write. +# This also ensures that builds from sstate will also have this requirement +# satisfied. python () { - # do_addto_recipe_sysroot doesnt exist for all recipes, but we need it to have - # /usr/bin on recipe-sysroot (qemu) populated def extraimage_getdepends(task): deps = "" for dep in (d.getVar('EXTRA_IMAGEDEPENDS') or "").split(): # Make sure we only add it for qemu - if 'qemu' in dep: + if 'qemu-helper-native' in dep: deps += " %s:%s" % (dep, task) return deps d.appendVarFlag('do_bootconf_write', 'depends', extraimage_getdepends('do_addto_recipe_sysroot')) -- 2.31.1
|
|
[meta-zephyr][PATCH 1/2] zephyr-qemuboot.bbclass: Don't overwrite the entire elf dictionary key
Andrei Gherzan
From: Andrei Gherzan <andrei.gherzan@huawei.com>
The nios2_machdata_setfunc was overwriting the elf key in matchdata for arc done in arc_machdata_setfunc which in turn was overwriting the one from oe-core. This is making qemu-x86 builds (as an example) unbuildable: Exception: KeyError: 'i586' This patch makes sure that the changes complement the machdata dictionary as opposed to overwriting the entire "elf" key. Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com> --- classes/siteinfo-zephyr.bbclass | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/classes/siteinfo-zephyr.bbclass b/classes/siteinfo-zephyr.bbclass index d84fd3a..b84a9b2 100644 --- a/classes/siteinfo-zephyr.bbclass +++ b/classes/siteinfo-zephyr.bbclass @@ -1,4 +1,3 @@ - def arc_siteinfo_setfunc(archinfo, osinfo, targetinfo, d): archinfo['arc'] = "endian-little bit-32 " osinfo['linux'] = "common-linux common-glibc" @@ -8,7 +7,7 @@ def arc_siteinfo_setfunc(archinfo, osinfo, targetinfo, d): SITEINFO_EXTRA_DATAFUNCS += "arc_siteinfo_setfunc" def arc_machdata_setfunc(machdata, d): - machdata["elf"] = { "arc" : (195, 0, 0, True, 32), } + machdata["elf"]["arc"] = (195, 0, 0, True, 32) return machdata PACKAGEQA_EXTRA_MACHDEFFUNCS += "arc_machdata_setfunc" @@ -22,7 +21,7 @@ def iamcu_siteinfo_setfunc(archinfo, osinfo, targetinfo, d): SITEINFO_EXTRA_DATAFUNCS += "iamcu_siteinfo_setfunc" def nios2_machdata_setfunc(machdata, d): - machdata["elf"] = {"nios2": (113, 0, 0, True, 32), } + machdata["elf"]["nios2"] = (113, 0, 0, True, 32) return machdata -PACKAGEQA_EXTRA_MACHDEFFUNCS += "nios2_machdata_setfunc" \ No newline at end of file +PACKAGEQA_EXTRA_MACHDEFFUNCS += "nios2_machdata_setfunc" -- 2.31.1
|
|
Re: [meta-zephyr][PATCH 1/1] zephyr-qemuboot.bbclass: Fix runqemu dependency on qemu native sysroot
Andrei Gherzan
Hi,
On Thu, 13 May 2021, at 13:14, Ross Burton wrote: Debugged, the patch is broken.I'll look into it. -- Andrei Gherzan gpg: rsa4096/D4D94F67AD0E9640
|
|
Re: [meta-zephyr][PATCH 1/1] zephyr-qemuboot.bbclass: Fix runqemu dependency on qemu native sysroot
Ross Burton <ross@...>
Debugged, the patch is broken.
toggle quoted messageShow quoted text
Using a little tool I have: Task qemu-system-native-5.2.0-r0:do_addto_recipe_sysroot failed Active tasks are: virglrenderer-native-0.9.1-r0:do_rm_work binutils-cross-arm-2.36.1-r0:do_patch qemu-system-native-5.2.0-r0:do_addto_recipe_sysroot qemu-system-native-5.2.0-r0:do_rm_work libepoxy-native-1.5.5-r0:do_rm_work gcc-source-11.1.0-11.1.0-r0:do_unpack Note how qemu is simultaneously adding itself to the sysroot, whilst rm_work is running and deleting the sysroot. This patch isn't compatible with rm_work and should be reverted. Ross
On Thu, 13 May 2021 at 13:06, Ross Burton <ross@burtonini.com> wrote:
|
|
Re: [meta-zephyr][PATCH 1/1] zephyr-qemuboot.bbclass: Fix runqemu dependency on qemu native sysroot
Ross Burton <ross@...>
This is breaking our CI:
toggle quoted messageShow quoted text
ERROR: qemu-system-native-5.2.0-r0 do_addto_recipe_sysroot: Error executing a python function in exec_python_func() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_python_func() autogenerated', lineno: 2, function: <module> 0001: *** 0002:extend_recipe_sysroot(d) 0003: File: '/builds/yocto-poc/meta-arm/work/poky/meta/classes/staging.bbclass', lineno: 502, function: extend_recipe_sysroot 0498: continue 0499: 0500: msg_adding.append(c) 0501: *** 0502: os.symlink(c + "." + taskhash, depdir + "/" + c) 0503: 0504: manifest, d2 = oe.sstatesig.find_sstate_manifest(c, setscenedeps[dep][2], "populate_sysroot", d, multilibs) 0505: if d2 is not d: 0506: # If we don't do this, the recipe sysroot will be placed in the wrong WORKDIR for multilibs Exception: FileNotFoundError: [Errno 2] No such file or directory: 'zlib-native.0f0b3e4d16f9ad46dd8609d8c899a834104f5b572a4a5438ccccd1db88d67e97' -> '/builds/yocto-poc/meta-arm/work/build/tmp/work/aarch64-linux/qemu-system-native/5.2.0-r0/recipe-sysroot-native/installeddeps/zlib-native' ERROR: Logfile of failure stored in: /builds/yocto-poc/meta-arm/work/build/tmp/work/aarch64-linux/qemu-system-native/5.2.0-r0/temp/log.do_addto_recipe_sysroot.7593 ERROR: Task (/builds/yocto-poc/meta-arm/work/poky/meta/recipes-devtools/qemu/qemu-system-native_5.2.0.bb:do_addto_recipe_sysroot) failed with exit code '1' ERROR: qemu-system-native-5.2.0-r0 do_rm_work: Execution of '/builds/yocto-poc/meta-arm/work/build/tmp/work/aarch64-linux/qemu-system-native/5.2.0-r0/temp/run.do_rm_work.7583' failed with exit code 1: rm: cannot remove 'recipe-sysroot-native': Directory not empty Can this be reverted whilst this is debugged? Ross
On Fri, 7 May 2021 at 11:09, Andrei Gherzan <andrei@gherzan.com> wrote:
|
|
Re: Yocto with xtensa
Jack Daniels <onyx22574@...>
Hello Khem, Thank you for the information. Is it about adding support for the xtensa build system (toolchain)? Is it work for heterogeneous SoC (CPU/ARM + DSP/xtensa) as well? Thank you. BR/J
On Thu, May 13, 2021 at 1:07 AM Khem Raj <raj.khem@...> wrote: Hello Jack,
|
|
Re: Yocto Zeus : facing error regarding hostapd
#zeus
Zoran
Hello Rohit,
toggle quoted messageShow quoted text
It is a good find. I also googled for the error, and found this as an explanation: https://www.yoctoproject.org/pipermail/yocto/2019-February/044153.html I included Alex (Kanavin), who created the above mail. Maybe Alex can give more light on the problem? In the meantime, you should explore (by similarities) this pointer in very details: https://github.com/Xilinx/meta-virtualization/issues/4#issuecomment-590532621 Zoran _______
On Thu, May 13, 2021 at 8:25 AM rohit jadhav <rohitbjadhav1@gmail.com> wrote:
|
|
Re: Yocto Zeus : facing error regarding hostapd
#zeus
rohit jadhav
Hi Zoran, log.do_rootfs.31340is linked to log.do_rootfs I have checked with ls command, So both files are identical. While surfing I found similar thread but its for different package its as follows : Can you please help out with this for our Package Hostapd ? Thanks and Regards Rohit
On Thu, May 13, 2021 at 10:18 AM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote: From the log log.do_rootfs.31340 file, there are the following:
|
|
Re: [meta-raspberrypi][PATCH] 99-com.rules: fix error invalid substitution type
Changqing Li
On 5/13/21 11:48 AM, Khem Raj wrote:
[Please note: This e-mail is from an EXTERNAL e-mail address]ok Signed-off-by: Changqing Li <changqing.li@windriver.com>
|
|
Re: Yocto Zeus : facing error regarding hostapd
#zeus
Zoran
From the log log.do_rootfs.31340 file, there are the following:
toggle quoted messageShow quoted text
[1] ERROR: Postinstall scriptlets of ['hostapd'] have failed. HOSTAP stands for: HOST Access Point Daemon. I could not conclude too much from: https://en.wikipedia.org/wiki/Hostapd It is kind of a hot spot, as my best understanding is. [2] Details of the failure are in /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs. So, my best guess, looking into log.do_rootfs will tell us much more. Please, attach this one for our review as well. Thank you, Zoran _______
On Wed, May 12, 2021 at 5:29 PM rohit jadhav <rohitbjadhav1@gmail.com> wrote:
|
|
Re: [meta-raspberrypi][PATCH] 99-com.rules: fix error invalid substitution type
On 5/12/21 8:42 PM, Changqing Li wrote:
From: Changqing Li <changqing.li@windriver.com>Can you create a pull request on github for this please. Signed-off-by: Changqing Li <changqing.li@windriver.com>
|
|
[meta-raspberrypi][PATCH] 99-com.rules: fix error invalid substitution type
Changqing Li
From: Changqing Li <changqing.li@windriver.com>
fix below error: /etc/udev/rules.d/99-com.rules:10 Invalid value "/bin/sh -c 'ALIASES=/proc/device-tree/aliases; if cmp -s $ALIASES/uart0 $ALIASES/serial0; then echo 0;elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then echo 1; else exit 1; fi'" for PROGRAM (char 58: invalid substitution type) Signed-off-by: Changqing Li <changqing.li@windriver.com> --- recipes-core/udev/udev-rules-rpi/99-com.rules | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/recipes-core/udev/udev-rules-rpi/99-com.rules b/recipes-core/udev/udev-rules-rpi/99-com.rules index 6bf019b..ddd1e17 100644 --- a/recipes-core/udev/udev-rules-rpi/99-com.rules +++ b/recipes-core/udev/udev-rules-rpi/99-com.rules @@ -1,8 +1,8 @@ KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\ ALIASES=/proc/device-tree/aliases; \ - if cmp -s $ALIASES/uart0 $ALIASES/serial0; then \ + if cmp -s $$ALIASES/uart0 $$ALIASES/serial0; then \ echo 0;\ - elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then \ + elif cmp -s $$ALIASES/uart0 $$ALIASES/serial1; then \ echo 1; \ else \ exit 1; \ @@ -11,9 +11,9 @@ KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\ KERNEL=="ttyS0", PROGRAM="/bin/sh -c '\ ALIASES=/proc/device-tree/aliases; \ - if cmp -s $ALIASES/uart1 $ALIASES/serial0; then \ + if cmp -s $$ALIASES/uart1 $$ALIASES/serial0; then \ echo 0; \ - elif cmp -s $ALIASES/uart1 $ALIASES/serial1; then \ + elif cmp -s $$ALIASES/uart1 $$ALIASES/serial1; then \ echo 1; \ else \ exit 1; \ -- 2.17.1
|
|
[meta-security][PATCH 6/6] packagegroup-core-security: add aide and ossec
Signed-off-by: Armin Kuster <akuster808@gmail.com>
--- recipes-core/packagegroup/packagegroup-core-security.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb index 54b8297..0bddf64 100644 --- a/recipes-core/packagegroup/packagegroup-core-security.bb +++ b/recipes-core/packagegroup/packagegroup-core-security.bb @@ -70,6 +70,8 @@ SUMMARY_packagegroup-security-ids = "Security Intrusion Detection systems" RDEPENDS_packagegroup-security-ids = " \ samhain-standalone \ ${@bb.utils.contains_any("TUNE_FEATURES", "ppc7400 riscv32 riscv64", "", " suricata",d)} \ + ossec-hids \ + aide \ " SUMMARY_packagegroup-security-mac = "Security Mandatory Access Control systems" -- 2.25.1
|
|
[meta-security][PATCH 5/6] aide: Add another ids
Signed-off-by: Armin Kuster <akuster808@gmail.com>
--- recipes-ids/aide/aide/aide.conf | 94 +++++++++++++++++++++++++++++++++ recipes-ids/aide/aide_0.17.3.bb | 41 ++++++++++++++ 2 files changed, 135 insertions(+) create mode 100644 recipes-ids/aide/aide/aide.conf create mode 100644 recipes-ids/aide/aide_0.17.3.bb diff --git a/recipes-ids/aide/aide/aide.conf b/recipes-ids/aide/aide/aide.conf new file mode 100644 index 0000000..2c99e07 --- /dev/null +++ b/recipes-ids/aide/aide/aide.conf @@ -0,0 +1,94 @@ +# Example configuration file for AIDE. + +@@define DBDIR /usr/lib/aide +@@define LOGDIR /usr/lib/aide/logs + +# The location of the database to be read. +database_in=file:@@{DBDIR}/aide.db.gz + +# The location of the database to be written. +#database_out=sql:host:port:database:login_name:passwd:table +#database_out=file:aide.db.new +database_out=file:@@{DBDIR}/aide.db.gz + +# Whether to gzip the output to database +gzip_dbout=yes + +# Default. +log_level=warning + +report_url=file:@@{LOGDIR}/aide.log +report_url=stdout +#report_url=stderr +#NOT IMPLEMENTED report_url=mailto:root@foo.com +#NOT IMPLEMENTED report_url=syslog:LOG_AUTH + +# These are the default rules. +# +#p: permissions +#i: inode: +#n: number of links +#u: user +#g: group +#s: size +#b: block count +#m: mtime +#a: atime +#c: ctime +#S: check for growing size +#acl: Access Control Lists +#selinux SELinux security context +#xattrs: Extended file attributes +#md5: md5 checksum +#sha1: sha1 checksum +#sha256: sha256 checksum +#sha512: sha512 checksum +#rmd160: rmd160 checksum +#tiger: tiger checksum + +#haval: haval checksum (MHASH only) +#gost: gost checksum (MHASH only) +#crc32: crc32 checksum (MHASH only) +#whirlpool: whirlpool checksum (MHASH only) + +FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256 + +#R: p+i+n+u+g+s+m+c+acl+selinux+xattrs+md5 +#L: p+i+n+u+g+acl+selinux+xattrs +#E: Empty group +#>: Growing logfile p+u+g+i+n+S+acl+selinux+xattrs + +# You can create custom rules like this. +# With MHASH... +# ALLXTRAHASHES = sha1+rmd160+sha256+sha512+whirlpool+tiger+haval+gost+crc32 +ALLXTRAHASHES = sha1+rmd160+sha256+sha512+tiger +# Everything but access time (Ie. all changes) +EVERYTHING = R+ALLXTRAHASHES + +# Sane, with multiple hashes +# NORMAL = R+rmd160+sha256+whirlpool +NORMAL = FIPSR+sha512 + +# For directories, don't bother doing hashes +DIR = p+i+n+u+g+acl+selinux+xattrs + +# Access control only +PERMS = p+i+u+g+acl+selinux + +# Logfile are special, in that they often change +LOG = > + +# Just do sha256 and sha512 hashes +LSPP = FIPSR+sha512 + +# Some files get updated automatically, so the inode/ctime/mtime change +# but we want to know when the data inside them changes +DATAONLY = p+n+u+g+s+acl+selinux+xattrs+sha256 + +# Next decide what directories/files you want in the database. + +# Check only permissions, inode, user and group for /etc, but +# cover some important files closely. +/bin NORMAL +/sbin NORMAL +/lib NORMAL diff --git a/recipes-ids/aide/aide_0.17.3.bb b/recipes-ids/aide/aide_0.17.3.bb new file mode 100644 index 0000000..522cd85 --- /dev/null +++ b/recipes-ids/aide/aide_0.17.3.bb @@ -0,0 +1,41 @@ +SUMMARY = "Advanced Intrusion Detection Environment" +HOMEPAGE = "https://aide.github.io" +LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263" +LICENSE = "GPL-2.0" + +DEPENDS = "bison-native libpcre" + +SRC_URI = "https://github.com/aide/aide/releases/download/v${PV}/${BPN}-${PV}.tar.gz \ + file://aide.conf" + +SRC_URI[sha256sum] = "a2eb1883cafaad056fbe43ee1e8ae09fd36caa30a0bc8edfea5d47bd67c464f8" + +inherit autotools pkgconfig + +PACKAGECONFIG ??=" mhash zlib e2fsattrs \ + ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux audit', '', d)} \ + ${@bb.utils.contains('DISTRO_FEATURES', 'xattr', 'xattr', '', d)} \ + " +PACKAGECONFIG[selinux] = "--with-selinux, --without-selinux, libselinux, libselinux" +PACKAGECONFIG[zlib] = "--with-zlib, --without-zlib, zlib, zlib " +PACKAGECONFIG[xattr] = "--with-xattr, --without-xattr, attr, attr" +PACKAGECONFIG[curl] = "--with-curl, --without-curl, curl, libcurl" +PACKAGECONFIG[audit] = "--with-audit, --without-audit," +PACKAGECONFIG[gcrypt] = "--with-gcrypt, --without-gcrypt, libgcrypt, libgcrypt" +PACKAGECONFIG[mhash] = "--with-mhash, --without-mhash, libmhash, libmhash" +PACKAGECONFIG[e2fsattrs] = "--with-e2fsattrs, --without-e2fsattrs, e2fsprogs, e2fsprogs" + +do_install_append () { + install -d ${D}${libdir}/${PN}/logs + install -d ${D}${sysconfdir} + install ${WORKDIR}/aide.conf ${D}${sysconfdir}/ +} + +CONF_FILE = "${sysconfdir}/aide.conf" + +FILES_${PN} += "${libdir}/${PN} ${sysconfdir}/aide.conf" + +pkg_postinst_ontarget_${PN} () { + /usr/bin/aide -i +} +RDPENDS_${PN} = "bison, libpcre" -- 2.25.1
|
|
[meta-security][PATCH 4/6] Apparmor: fix multi config build issue.
Signed-off-by: Armin Kuster <akuster808@gmail.com>
--- recipes-mac/AppArmor/apparmor_3.0.bb | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/recipes-mac/AppArmor/apparmor_3.0.bb b/recipes-mac/AppArmor/apparmor_3.0.bb index 015205d..d9c3e4d 100644 --- a/recipes-mac/AppArmor/apparmor_3.0.bb +++ b/recipes-mac/AppArmor/apparmor_3.0.bb @@ -177,8 +177,9 @@ SYSTEMD_AUTO_ENABLE ?= "enable" PACKAGES += "mod-${PN}" -FILES_${PN} += "/lib/apparmor/ /lib/security/ ${sysconfdir}/apparmor ${PYTHON_SITEPACKAGES_DIR}" +FILES_${PN} += "/lib/apparmor/ /lib/security/ ${sysconfdir}/apparmor ${nonarch_libdir}/${PYTHON_DIR}/site-packages" FILES_mod-${PN} = "${libdir}/apache2/modules/*" +FILES_${PN}-dbg += "/lib/security/" DEPENDS_append_libc-musl = " fts " RDEPENDS_${PN}_libc-musl += "musl-utils" -- 2.25.1
|
|
[meta-security][PATCH 3/6] packagegroup-core-security: fix typo for mips
Signed-off-by: Armin Kuster <akuster808@gmail.com>
--- recipes-core/packagegroup/packagegroup-core-security.bb | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb index 6d2dd7c..54b8297 100644 --- a/recipes-core/packagegroup/packagegroup-core-security.bb +++ b/recipes-core/packagegroup/packagegroup-core-security.bb @@ -79,8 +79,7 @@ RDEPENDS_packagegroup-security-mac = " \ ${@bb.utils.contains("DISTRO_FEATURES", "smack", "smack", "",d)} \ " -RDEPENDS_packagegroup-security-mac_remove_mips64 = "apparmor" -RDEPENDS_packagegroup-security-mac_remove_mips64le = "apparmor" +RDEPENDS_packagegroup-security-mac_remove_mipsarch = "apparmor" RDEPENDS_packagegroup-meta-security-ptest-packages = "\ ptest-runner \ -- 2.25.1
|
|