Skip to contentSkip to conversation

Your daily results for 2024-07-28

Buildroot [email protected] 1 participant 2 messages Jul 29, 2024 – Jul 30, 2024 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

[email protected]

author
#1 lore raw

All,

+Christian for his go expertise

On 2024-07-29 04:55 -0000, Thomas Petazzoni spake thusly:

Quoted 2 lines
   mips64    |       host-skopeo-1.13.3       | http://autobuild.buildroot.net/results/9dacb15da7dcf4fb97cd2eaf17c5cb3c88290390
  mips64el   |       host-skopeo-1.13.3       | http://autobuild.buildroot.net/results/e4dbb5c7eb1c952718c2efa9bcd2211681ac950a

The root cause for these build failures is that the gpgme wrapper in go needs CGO support, but the failing configurations both disable CGO, because the target architecture does not support CGO linking support.

We handle CGO in a slightly convoluted manner:

* if the go compiler supports the tqrget
- if there is no CGO linking, then we set HOST_GO_CGO_ENABLED=1
- otherwise we set HOST_GO_CGO_ENABLED=0
* if the go compiler does not support the target, then we set HOST_GO_CGO_ENABLED=1

And then we build go packages, target or host variants alike, with:

    CGO_ENABLED=$(HOST_GO_CGO_ENABLED)

Furthermore, HOST_GO_CGO_ENABLED is also used when building go-src. The same go compiler is then used to build either target or host packages.

AFAICS, there is no way to tell the go compiler to build with CGO linking for the host but without for the target; its an all-or-nothing situation, and thus the limitation of the target do leak onto the host support.

There is a Kconfig knob that drives whether CGO is enabled, which is BR2_PACKAGE_HOST_GO_TARGET_CGO_LINKING_SUPPORTS. However, as its name suggests, it is for the target. And when go does not even support the target, that will not be enabled either.

So, what I see as a solution, is two-fold:

1. introduce BR2_PACKAGE_HOST_GO_HOST_CGO_LINKING_SUPPORTS, defined as follows:

config BR2_PACKAGE_HOST_GO_HOST_CGO_LINKING_SUPPORTS
bool
default y if BR2_PACKAGE_HOST_GO_TARGET_CGO_LINKING_SUPPORTS default y if !BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS

2. make skopeo depend on that new symbol

Thoughts?

Quoted 2 lines

-------------------------------+----------+----------------------------------------------+--------------+--------------
skopeo | DISTRO | https://release-monitoring.org/project/09216 | 1.13.3 | 1.15.2

I'll see at updating skopeo as time permits in the week...

Quoted 1 line

skopeo | CVE-2019-10214 | https://security-tracker.debian.org/tracker/CVE-2019-10214

That CVE applies to containers/image, and is matched for un-versioned skopeo (notice the dash '-' in the CPE ID):

    https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:skopeo_project:skopeo:-:*:*:*:*:*:*:*

and does not apply to any versioned skopeo (any and 1.13.3 for example; notice the star '*' or the version instead of the dash in the CPE ID):

    https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:skopeo_project:skopeo:*:*:*:*:*:*:*:*
    https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:skopeo_project:skopeo:1.13.3:*:*:*:*:*:*:*

This was fixed in containers/image in upstream commit a3d69a4a (Use the same HTTP client for contacting the bearer token server and the registry, 2019-08-01) which has been released in containers/image v3.0.0. skopeo 1.13.3 vendors containers/image v5.26.2, so the CVE does not apply.

So, not sure what the best way of action would be...

Regards,
Yann E. MORIN.

Signature · 23 lines
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
| yann.morin (at) orange.com           |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
author
#2 lore raw

Christian, All,

On 2024-07-29 13:44 +0200, MORIN Yann INNOV/IT-S spake thusly:

Quoted 11 lines

On 2024-07-29 04:55 -0000, Thomas Petazzoni spake thusly:

Quoted 2 lines
   mips64    |       host-skopeo-1.13.3       | http://autobuild.buildroot.net/results/9dacb15da7dcf4fb97cd2eaf17c5cb3c88290390
  mips64el   |       host-skopeo-1.13.3       | http://autobuild.buildroot.net/results/e4dbb5c7eb1c952718c2efa9bcd2211681ac950a

The root cause for these build failures is that the gpgme wrapper in go needs CGO support, but the failing configurations both disable CGO, because the target architecture does not support CGO linking support.

We handle CGO in a slightly convoluted manner:

* if the go compiler supports the tqrget
- if there is no CGO linking, then we set HOST_GO_CGO_ENABLED=1

Of course, this is the other way around: if there is CGO linking, then we set HOST_GO_CGO_ENABLED=1.

Regards,
Yann E. MORIN.

Quoted 73 lines

- otherwise we set HOST_GO_CGO_ENABLED=0
* if the go compiler does not support the target, then we set HOST_GO_CGO_ENABLED=1

And then we build go packages, target or host variants alike, with:

    CGO_ENABLED=$(HOST_GO_CGO_ENABLED)

Furthermore, HOST_GO_CGO_ENABLED is also used when building go-src. The same go compiler is then used to build either target or host packages.

AFAICS, there is no way to tell the go compiler to build with CGO linking for the host but without for the target; its an all-or-nothing situation, and thus the limitation of the target do leak onto the host support.

There is a Kconfig knob that drives whether CGO is enabled, which is BR2_PACKAGE_HOST_GO_TARGET_CGO_LINKING_SUPPORTS. However, as its name suggests, it is for the target. And when go does not even support the target, that will not be enabled either.

So, what I see as a solution, is two-fold:

1. introduce BR2_PACKAGE_HOST_GO_HOST_CGO_LINKING_SUPPORTS, defined as follows:

config BR2_PACKAGE_HOST_GO_HOST_CGO_LINKING_SUPPORTS
bool
default y if BR2_PACKAGE_HOST_GO_TARGET_CGO_LINKING_SUPPORTS default y if !BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS

2. make skopeo depend on that new symbol

Thoughts?

Quoted 2 lines

-------------------------------+----------+----------------------------------------------+--------------+--------------
skopeo | DISTRO | https://release-monitoring.org/project/09216 | 1.13.3 | 1.15.2

I'll see at updating skopeo as time permits in the week...

Quoted 1 line

skopeo | CVE-2019-10214 | https://security-tracker.debian.org/tracker/CVE-2019-10214

That CVE applies to containers/image, and is matched for un-versioned skopeo (notice the dash '-' in the CPE ID):

    https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:skopeo_project:skopeo:-:*:*:*:*:*:*:*

and does not apply to any versioned skopeo (any and 1.13.3 for example; notice the star '*' or the version instead of the dash in the CPE ID):

    https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:skopeo_project:skopeo:*:*:*:*:*:*:*:*
    https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe:2.3:a:skopeo_project:skopeo:1.13.3:*:*:*:*:*:*:*

This was fixed in containers/image in upstream commit a3d69a4a (Use the same HTTP client for contacting the bearer token server and the registry, 2019-08-01) which has been released in containers/image v3.0.0. skopeo 1.13.3 vendors containers/image v5.26.2, so the CVE does not apply.

So, not sure what the best way of action would be...

Regards,
Yann E. MORIN.

Signature · 7 lines
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
| yann.morin (at) orange.com           |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'
Signature · 23 lines
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
| yann.morin (at) orange.com           |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot