Valentin Rothberg

> @vrothberg do you think we'd want something similar to [containers/podman#7215](https://github.com/containers/podman/pull/7215) here? Yes, 7215 could be quite useful. I think you can fairly easily adopt the `layersTree` implementation in CRI-O....

@rhatdan, @marcov and I coordinated. The API in psgo should be stable enough now and the latest changes are merged. @marcov, in case you want to add bash-completion, feel free...

> Also wondering how `oom_score_adj` should be mapped if it's per-process instead of cgroup; if a container has multiple processes, _some_ of those could get OOM-killed, instead of the container...

Thanks, @filbranden, for the great summary!

> Should an implementation pull a manifest, and skip (ignore) layers with unknown compression, or should it produce an error? I had similar issues interpreting "ignore". The `containers/image` library errored...

Thanks, @thaJeztah! I also felt some relief :smile: @tych0, could you elaborate a bit on your use case? I don't want to break you a second time :angel:

Could it be generalized further to also limit the size of manifests and configs (i.e., blobs of unknown sizes)? We've seen situations/attacks where a registry would continue streaming a manifest/config...

> So, what do we think are reasonable limits for, to limit DOS attacks, or just runaway code? The containers/image library is mostly using a [limits of 4 MB](https://github.com/containers/image/blob/master/internal/iolimits/iolimits.go) some...

I don't understand the proposal and problem statement. Can you elaborate? Is it to rewrite oci-seccomp-bpf-hook in C with libbpf?

Can you outline the exact benefits of using libbpf? Porting/rewriting is costly and I want to make sure there are sufficient technical benefits. Heads up: I am generally opposed to...