docker 20.10.21 from master-next


Adrian Freihofer
 

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 \
"

* 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.
Im not 100% sure if mobyproject:moby covers also CVEs in libnetwork
and the cli which are separate repositories.
* The default PACKAGECONFIG could consider the seccomp DISTRO_FEATURE:
${@bb.utils.contains('DISTRO_FEATURES', 'seccomp', 'seccomp', '',)}

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.

Thank you and regards,
Adrian


Bruce Ashfield
 

On Mon, Nov 28, 2022 at 4:46 PM Adrian Freihofer
<adrian.freihofer@...> 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.


* 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


Adrian Freihofer
 

On Mon, 2022-11-28 at 23:28 -0500, Bruce Ashfield wrote:
On Mon, Nov 28, 2022 at 4:46 PM Adrian Freihofer
<adrian.freihofer@...> 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