Thanks for raising the issue and pointing to the CNCF licensing requirements.

+1 on changing the busybox images. Before going with the AWS library, do you know if there are other alternatives we could consider?

I'd wonder if this use is even affected by the allow list policy and whether there should be concerns over GPL affecting licensing of collector. I know of at least one other CNCF project (Prometheus - https://github.com/prometheus/busybox) using BusyBox image and haven't heard similar concerns.

Thanks for raising the issue and pointing to the CNCF licensing requirements.

+1 on changing the busybox images. Before going with the AWS library, do you know if there are other alternatives we could consider?

We had weighed the decision between a cp-utility tool written in Go or Rust. We came to the conclusion that rust would be a safer choice due to the amount of CVEs that each language has historically had. Recently we have also discovered ToyBox as an option but did not evaluate how it could be integrated into the auto-instrumentation images.

I'd wonder if this use is even affected by the allow list policy and whether there should be concerns over GPL affecting licensing of collector. I know of at least one other CNCF project (Prometheus - https://github.com/prometheus/busybox) using BusyBox image and haven't heard similar concerns.

I think it's a fair question but is not something we should gloss over. Prometheus library may also not be compliant. IANAL so I think if we want to consider this line of questioning an operator maintainer should bring this to the GC and/or the CNCF.

Also, the collector image is built from scratch and only uses alpine to generate certificates. I don't think this is the full picture though because dependent libraries may also contain different licensing requirements. There is an open issue in collector core regarding license distribution.

+1 for changing out the busy box image for auto-instrumentation, this has been an ongoing discussion with my team.

Last week I created a scratch based image that uses a go binary as a cp-utility. It is good to know about the rust option now as well.

I think we should have a sig meeting tomorrow right? I could bring this discussion there.

@jvoravong do you have a link of the work you did with the go cp-utility?

We haven't merged it into main, but here is the draft and dev image.
Draft PR: jvoravong/splunk-otel-java#2
Dev Image jvsplk/splunk-otel-java:v1.22.0

I say this not having dived into either PR yet and having missed the discussion today in the SIG, but my gut reaction is to favor a Go-based image instead of rust. It looks like both PRs add some code to manage and personally I'd rather keep the language dependency of the repository on Go as much as possible. If we introduce rust the Approvers and Maintainers now need to understand how to maintain rust code in what is primarily a Go repository.

@TylerHelmuth thank you for the response! That was actually discussed in the sig today. I will provide some notes later on the discussion that was had. What we did agree on for both proposals is to see if we could lift the build of a cp utility into a different repository. From that repository we could publish it as a base image and the operator repo can have a dependency on it.

I will also take on the action of explaining on why the ADOT team chose rust over go. This was also discussed in the SIG meeting but it would be good to provide it in writing here.

In a meeting today, came across a binary that might use the new base image so it can be added into a k8s pod via init container. Potentially, the JMX Metric Gatherer could usa a proposed base image (with cp capabilities) to insert the JMX Metric Gatherer binary into a pod. I'm not an expert in the JMX Metric Gatherer, just leaving notes.

Was able to publish CVE reports for the golang proposal as part of this comment.

Summary: Using a scratch base image with go code gets the CVE count low.

Let me know if I should use another method for scanning for CVEs.

@bryan-aguilar @jvoravong are you still working on this?

What is the status of this development?

@atoulme I think the work has stalled, though this is something that we still desire. We have a similar request/need from this issue If you have time to work on this, the help would be appreciated! If not, I can see if anyone else has the cycles.