George Lestaris

Happy to close this. I kept it open until the PR gets accepted, but it does not matter that much :)

...and I just realised I can't close it since I don't own the issue anymore :) @philips feel free to close this

Is this related to https://github.com/opencontainers/image-tools/issues/14? Should we first introduce a logging framework and then add logs for the above cases?

I am very up for sharing a single unpacking implementation! I am not sure if this implementation should live outside of an `opencontainers` repository though. I would hope to see...

@vbatts let me try to become more specific. Once this PR is accepted we will be using `github.com/containers/storage` (or a subset of that) to make a changeset (layer). This will...

I agree that we can avoid something like `--fallback-user`. However, I think having `oci-unpack` dealing with translation is important. Imagine the following workflow: ``` bash oci-download --ref 3.2.5 oci://registry.opencontainers.org/redis ./redis-image...

I agree with @wking in that since it's not part of the spec it shouldn't live here. @runcom that would be an interesting mix. Since `containers/image` supports multiple sources and...

I think libraries with fairly stable APIs would be great! Unpacking can be error-prone, signature validation (once it becomes part of the spec) is not code you want to write...

Sorry for spamming but +1. We use rebase quite often and it's always a pain having to fix the authors of each commit.

@jszwedko The problem we are seeing is that we lose information about the commiter in all the rebased commits. Just to give an example: I made a repo with `master`...