This is an odd one that shouldn't be an issue for "normal" use cases, but would be nice to have fail more gracefully in exceptional ones. Basically, I'm using pullImageFromManifest (contributed in https://github.com/nlewo/nix2container/pull/77) to pull what is supposed to be an Ubuntu underlay image and then layer some Nix stuff on top of it. Unfortunately due to a misunderstanding, some Nix stuff also ended up in the underlay, including the exact curl store path that was doing the image pulling. On Hydra, we had an incomplete error message and just got error: unexpected end-of-file, but a local reproduction showed the assertion failure:
But once I unpacked that layer archive and had a look, it was clear that both it and the build trying to produce it were using the same /nix/store/m072pj8xfk9hvv9zj6z982xqa6rgybw3-curl-8.1.1 path.
To be clear, this is almost certainly not desirable— pullImage and pullImageFromManifest should be used to pull foreign blobs into the container, not stuff containing more Nix. However, if there's a mechanism that would enable marking off those tools used (skopeo, curl, jq, etc) as not being eligible to be references, that would be great; alternatively if we don't like that, we could also inspect the layer tarballs themselves and reject them outright if a /nix/store directory is present.
This is an odd one that shouldn't be an issue for "normal" use cases, but would be nice to have fail more gracefully in exceptional ones. Basically, I'm using
pullImageFromManifest
(contributed in https://github.com/nlewo/nix2container/pull/77) to pull what is supposed to be an Ubuntu underlay image and then layer some Nix stuff on top of it. Unfortunately due to a misunderstanding, some Nix stuff also ended up in the underlay, including the exactcurl
store path that was doing the image pulling. On Hydra, we had an incomplete error message and just goterror: unexpected end-of-file
, but a local reproduction showed the assertion failure:Pulling the tarball and inserting it into the store was no problem:
But once I unpacked that layer archive and had a look, it was clear that both it and the build trying to produce it were using the same
/nix/store/m072pj8xfk9hvv9zj6z982xqa6rgybw3-curl-8.1.1
path.To be clear, this is almost certainly not desirable—
pullImage
andpullImageFromManifest
should be used to pull foreign blobs into the container, not stuff containing more Nix. However, if there's a mechanism that would enable marking off those tools used (skopeo, curl, jq, etc) as not being eligible to be references, that would be great; alternatively if we don't like that, we could also inspect the layer tarballs themselves and reject them outright if a/nix/store
directory is present.