On Mon, 2022-11-28 at 23:28 -0500, Bruce Ashfield wrote:
> On Mon, Nov 28, 2022 at 4:46 PM Adrian Freihofer
> <[email protected]> wrote:
> >
> > Hi Bruce
> >
> > Three comments regarding the docker 20.10.21 recipes on master-
> > next:
> >
> > * Could the DEPENDS be reduced to the follwoing list? I guess all
> > other dependencies (the go stuff) are taken from the vendor
> > folder
> > anyway. It's at least working for me like that:
> >
> > DEPENDS = " \
> > libtool-native \
> > libtool \
> > "
>
> There are some usecases that are using unvendored builds (even if
> docker is currently using a vendor/ directory). They aren't commonly
> tested, but I know they exist, so for now, I'll leave those in place.
>
> They are mainly just extra build time, or are you seeing a build
> failure and/or something installed on the rootfs.
It's just a matter of not having to deal with additional artifacts. All
good if there is a reason to keep them.
Regards,
Adrian
>
> >
> > * The CVE_PRODUCT should probably be changed to:
> >
> > CVE_PRODUCT = "mobyproject:moby"
> >
> > With docker e.g. CVE-2022-36109 is not reported by cve_check but
> > with mobyproject:moby it works as expected.
>
> I didn't add the CVE_PRODUCT part of the recipe, so let me dig into
> that a bit more. It definitely used to need to be 'docker', but I'll
> try and pinpoint where that changed.
>
> I'd rather it be an addition, than a replacement (as long as I can
> convince myself we won't mask any CVEs by leaving 'docker' in place).
>
> > Im not 100% sure if mobyproject:moby covers also CVEs in
> > libnetwork
> > and the cli which are separate repositories.
>
> It probably doesn't, since they are quite separate (but maybe the CVE
> tracking takes into account the subproject hashes associated with a
> release). But that is a general problem with all unvendored or multi
> repository go applications .. tracking CVEs is challenging.
>
> But just adding the projects to CVE_PRODUCT probably isn't enough,
> unless we individually version the components. I haven't looked at
> how
> the tools work, but I'll put it on my TODO list to have a closer
> look.
>
> > * The default PACKAGECONFIG could consider the seccomp
> > DISTRO_FEATURE:
> > ${@bb.utils.contains('DISTRO_FEATURES', 'seccomp', 'seccomp',
> > '',)}
>
> This was in place before seccomp moved to OE Core, and yes, large
> parts of meta-virt need seccomp now, so this isn't a big deal.
>
> >
> > Of course I can send you a patch but I guess you would prefer to
> > quickly do it on your own since you already started with the update
> > and
> > you usually reject patches against your current work in progress.
> > Hope
> > this is helpful. Otherwise let me know.
>
> Yes, I am in the middle of getting things updated, in fact, I have
> some more bumps coming up in addition to what is in master-next, I
> ran
> into some system level issues (again) and have been sorting through
> them.
>
> This approach works fine, and I'll take care of stacking some
> patches.
>
> Bruce
>
> >
> > Thank you and regards,
> > Adrian
> >
> >
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#7704):
https://lists.yoctoproject.org/g/meta-virtualization/message/7704
Mute This Topic: https://lists.yoctoproject.org/mt/95321879/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
