-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add bootc build commit
#216
Comments
Can you sketch out where |
Yes as part of a |
@cgwalters any reason for this not to be a pass-thru to ostree-ext for now? |
One reason is we kind of just did a pivot around our handling of A tricky thing about making it a literal re-exec style passthrough is right now |
This issue also relates to #215 in that ultimately what we'd do here wouldn't involve ostree per se. But we'd need to then figure out something around the thorny issue of how we represent these xattrs (xref discussion in containers/storage#1608 ) |
Just a heads up that we are working this issue on our mobbing sessions. Specially based on this comment: I am not sure if this is intended to intersect with: #365 |
They're very different things, which argues for using different verbs. |
I'm a bit uncertain about doing this versus offering a container image that can work as part of a multi-stage build and do this stuff. That's inherently maximally flexible and avoids shipping potentially all sorts of tools in smaller images. i.e. we'd document:
Now don't get me wrong, it does seem quite convenient to ship basic scanning stuff as part of the image itself so you can just stick a If we take the "bootc does one thing and does it well" philosophy then this may end up being outside it, right? I could go either way... BTW one thing that we should have a basic lint checker for is having a single kernel (like rpm-ostree does). |
I can always be persuaded by the original Unix philosophy. I say we close this then. |
I keep going back and forth honestly 😄 One thing here is that while we have a stance that bootc is not a build system (you can use any container build system) there are in reality some rules it enforces specifically (such as the "one kernel" rule). Even if we had an external tool, it could call out to But we should probably think about what other things we need to lint for. There are potentially a lot...but I don't know how much is bootc specific in the end, versus "generic Linux" stuff. |
add simple lint to check that we only have one kernel in image. fixes: containers#216 Co-authored-by: Joseph Marrero <jmarrero@redhat.com> Co-authored-by: Huijing Hei <hhei@redhat.com>
add simple lint to check that we only have one kernel in image. fixes: containers#216 Co-authored-by: Joseph Marrero <jmarrero@redhat.com> Co-authored-by: Huijing Hei <hhei@redhat.com>
add simple lint to check that we only have one kernel in image. fixes: containers#216 Co-authored-by: Joseph Marrero <jmarrero@redhat.com> Co-authored-by: Huijing Hei <hhei@redhat.com>
add simple lint to check that we only have one kernel in image. fixes: containers#216 Co-authored-by: Joseph Marrero <jmarrero@redhat.com> Co-authored-by: Huijing Hei <hhei@redhat.com>
add simple lint to check that we only have one kernel in image. fixes: containers#216 Co-authored-by: Joseph Marrero <jmarrero@redhat.com> Co-authored-by: Huijing Hei <hhei@redhat.com> Co-authored-by: Yasmin de Souza <ydesouza@redhat.com>
add simple lint to check that we only have one kernel in image. fixes: containers#216 Co-authored-by: Joseph Marrero <jmarrero@redhat.com> Co-authored-by: Huijing Hei <hhei@redhat.com> Co-authored-by: Yasmin de Souza <ydesouza@redhat.com>
Add initial lint functionality, the first lint checks if there are multiple kernels in the image. fixes: containers#216 Co-authored-by: Joseph Marrero <jmarrero@redhat.com> Co-authored-by: Huijing Hei <hhei@redhat.com> Co-authored-by: Yasmin de Souza <ydesouza@redhat.com> Co-authored-by: Renata Ravanelli <rravanel@redhat.com> Co-authored-by: Adam Piasecki <c4rt0gr4ph3r@gmail.com>
OK another one we hit recently is where a user has a restrictive umask 077, and is doing a container build from a git clone that has a Dockerfile that is doing
Since the copy will preserve permissions (without I think we should probably lint against this by default. There's not a really good use case for having As for a larger fix for this case...well, it's probably not going to be viable in reality to force everyone doing git clones to reset the umask to 022. A
Where There is also https://docs.docker.com/reference/dockerfile/#copy---link - but we still need to canonicalize the permissions in that case. Hmm...
This would give us sane umask-independent semantics that hit the 95% case. There are of course use cases for things like setuid binaries being only executable by a specific user/group, but if you're doing that type of stuff you really should be explicitly setting the mode at install time for that specific binary. |
add simple lint to check that we only have one kernel in image. fixes: containers#216 Co-authored-by: Joseph Marrero <jmarrero@redhat.com> Co-authored-by: Huijing Hei <hhei@redhat.com> Co-authored-by: Yasmin de Souza <ydesouza@redhat.com>
add simple lint to check that we only have one kernel in image. fixes: containers#216 Co-authored-by: Joseph Marrero <jmarrero@redhat.com> Co-authored-by: Huijing Hei <hhei@redhat.com> Co-authored-by: Yasmin de Souza <ydesouza@redhat.com> Signed-off-by: Steven Presti <spresti@redhat.com>
Add an entrypoint that basically everyone can start adding to their builds which performs some basic static analysis for known problems. Closes : containers#216 Co-authored-by: Joseph Marrero <jmarrero@redhat.com> Co-authored-by: Huijing Hei <hhei@redhat.com> Co-authored-by: Yasmin de Souza <ydesouza@redhat.com> Signed-off-by: Steven Presti <spresti@redhat.com> Signed-off-by: Colin Walters <walters@verbum.org>
Add an entrypoint that basically everyone can start adding to their builds which performs some basic static analysis for known problems. Closes : containers#216 Co-authored-by: Joseph Marrero <jmarrero@redhat.com> Co-authored-by: Huijing Hei <hhei@redhat.com> Co-authored-by: Yasmin de Souza <ydesouza@redhat.com> Signed-off-by: Steven Presti <spresti@redhat.com> Signed-off-by: Colin Walters <walters@verbum.org>
@cgwalters, I feel this issue isn't actionable yet. Shall we groom it or is it a WIP? |
Looks like #381 helps but does not fully fixes this. |
This should take over the role of
ostree container commit
, however following up on ostreedev/ostree-rs-ext#569 we can change our thoughts on/var
.The text was updated successfully, but these errors were encountered: