[WIP] Save source URLs in the created OCI containers

[eriknordmark]

Many of the Dockerfiles use curl, wget, docker ADD, and git commands to download software on the fly.
PR #2861 will turn all of those into docker ADD.
But it might still be useful to save what was in those commands in the image itself.

This rough and only partially working fix does that in a file called /source-info with the intent that a script can pull them out of the lkt cache (currently used for testing) or the docker OCI images which make up EVE-OS.

Note that currently we only see a subset of the containers (which is probably because I don't understand the WORKDIR etc commands in the docker files). FWIW we see
lfedge/eve-kernel:89cc42dbec95d32555f529f94209ab995b8f0b95-amd64
lfedge/eve-debug:1ff8d86b2bdf297c6e92a48cd328148f40a2cc5f-amd64
lfedge/eve-wwan:59d70945ed45fdffe7dd3c9036863ee08d7c8a1f-amd64
lfedge/eve-guacd:524bb18891fa4abeb1747ec0ce33547a1e107672-amd64
lfedge/eve-pillar:8478b60f30d411cb917ce0a86f24b57bda867374-amd64
lfedge/eve-vtpm:18482d1dcb43720c97772305b598c3300a4c192e-amd64
lfedge/eve-xen-tools:661deb835e2877de6ba8438a2d9a1d47bc5f6aa6-amd64

but not others like lfedge/eve-xen, uefi, u-boot, etc
I don't know if this can be related to the above is the kernel plus the service containers.

[deitch]

Is there a need for it? If, for argument's sake, we get all of the ADD working, then a good scanner should be able to read all of the ADD commands by scanning the Dockerfile itself.

I am somewhat concerned that we will forget to add things here and there.

FYI, Docker is working on a scanner for Dockerfiles, I will start looking at it.

[eriknordmark]

Is there a need for it? If, for argument's sake, we get all of the ADD working, then a good scanner should be able to read all of the ADD commands by scanning the Dockerfile itself.

I am somewhat concerned that we will forget to add things here and there.

FYI, Docker is working on a scanner for Dockerfiles, I will start looking at it.

@deitch My question is whether folks want to be able to start with the binary image and whether having such annotations inside the image/containers makes this easier.
The ADDs make it easy once I have found the source commit for the github.com/lf-edge/eve but maybe that will always be easy? If so we do not need this.

It would provide some benefits until we have the ADD support for git commits, but if that is on its way, then no need to add this complexity now.

[deitch]

My question is whether folks want to be able to start with the binary image and whether having such annotations inside the image/containers makes this easier

To be honest, I agree with you. If you look, for example, at some work I did on kernel distribution (I am not all that good at kernel design), I included information about sources in OCI image labels, in configs, and in the filesystem itself. So I am all for having it in multiple places.

My primary concern is the human burden. if we have this source_info file (which I am in favour of), then it needs to be accurate. And if it is dependent on people remembering to add information to it in a Dockerfile, then I am concerned it will fall out of sync, someone will depend on it, and it will be wrong.

So if there is a way we can automate that process, then by all means, and let's include it in labels as well as config and on the filesystem and anywhere else we can think of.

[eriknordmark]

Given #2861 this is no longer needed.