dockerfile: reject an empty COPY or ADD source

[SashaMIT]

Summary

An empty COPY or ADD source was passed through NormalizePath, which treats an empty path as the parent directory. For a context copy that parent is /, so the instruction copied the whole build context into the image.

The JSON form, a quoted empty shell word, and a source that expands to an empty string are rejected before that rewrite.

Fixes #7261

Test plan

• go test -count=1 -run TestCopyEmptySource ./frontend/dockerfile/dockerfile2llb/
• go test -count=1 ./frontend/dockerfile/dockerfile2llb/

Before the guard, all four cases returned no error. After the guard, they return COPY source can't be empty or ADD source can't be empty.

[jsternberg]

See docker/buildx#4139 (comment) for why I'm closing this.

[SashaMIT]

Hey, I'm a real person :D but understandably I'm using compute and my codered system to tackle and support open source projects, you can see my OSS contributions repo on where I've helped over the months, if this is helpful that's great, if it's not aligned with your principles I also understand too, I get quite a lot of spare compute at times which I just direct and use to support OSS with, thanks!

[jsternberg]

I think I'll leave this PR closed because, looking at the PR description and the conversation from the linked issue, this doesn't seem to be the correct way to do it anyway. If you want to use spare compute for the buildkit project it's fine, but please try to keep interactions with the repository itself with a human touch and don't just have the agent scour the issues and pick up stuff randomly. It makes it much harder for us to manage stuff. If you see an issue yourself and think "I have the compute and I have the time to verify the output after the agent is finished" and you see that an issue has already been created and a method has been decided on, then that's fine. We just don't really want to do the verification for this stuff ourselves because there are too many possible ways that this can be abused to sneak code maliciously into the project.

For ourselves, most maintainers of buildkit have access to whatever compute they want to use to solve things if we want to and we generally have access to the same models that everyone else has access to.

In particular, the valuable part is the "ensuring the issue is real, the approach is correct, and the output is something both simple, verifiable, and understandable by a human maintainer." There's not a lot of value for us in "point the AI at an existing issue and just create a pull request with the output" as that puts the burden of the hard stuff on us.

[SashaMIT]

Ok really helpful feedback, appreciate if many PRs like this you must see a bloat issue which can waste time too, so my apologies here, thankyou for sharing.

If anything i can help with let me know, I'll otherwise only point PRs to direct areas we are having directly with moby on our company side so grounded moving forward, moby project and docker are awesome, thankyou for your work.