Merged
Conversation
This was referenced Aug 31, 2016
| for _, c := range []struct { | ||
| ctx *types.SystemContext | ||
| expected string | ||
| }{ |
Member
There was a problem hiding this comment.
can we test this out with $HOME?
Collaborator
Author
There was a problem hiding this comment.
Test what? defaultPolicyPath does not use the home directory. (re: the other conversation about environment variables, that happens for ATOMIC_CONF in docker/lookaside.go:atomicConfPath, but not in this PR).
Do you mean testing that an explicit SignaturePolicyPath is not expanded if it contains $HOME?
Member
There was a problem hiding this comment.
Do you mean testing that an explicit SignaturePolicyPath is not expanded if it contains $HOME?
yes this
Member
|
lgtm just a (silly) question (feel free to skip) |
| }, | ||
| // No environment expansion happens in the overridden paths | ||
| // Path overridden | ||
| {&types.SystemContext{SignaturePolicyPath: variableReference}, variableReference}, |
As we add more config files, having a single knob to override them all may simplify usage. Note that this is not a chroot; it will override e.g. hard-coded /etc, but $HOME is unaffected. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... instead of Docker-specific certPath and tlsVerify. Also invert the sense of tlsVerify to make the default secure. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
…ation This allows the selection to be consistent across GetManifest and GetSignatures (which will be needed by Docker lookaside). The API change causes lots of churn, but ultimately it just moves the real origin of the value from image.FromSource() to transport.NewImageSource(), both of which are static for the life of the ImageSource. Does not change behavior. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
For lookaside signature store, and separating the read and write URLs, we need to set up read-only and read-write states differently; having read-write “delete” in dockerImageSource is incovenient. In tue future, ImageSource.Delete will be a really poor fit for docker-daemon:, where initializing the ImageSource causes the tarball to be copied from the daemon. We could instead implement the docker-daemon source so that it only copies the tarball on demand, but not sharing the object is much simpler. This leaves the Docker implementation in docker_image_src.go to make reviewing easier. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Collaborator
Author
|
👍 |
mtrmac
added a commit
to containers/skopeo
that referenced
this pull request
Aug 31, 2016
Vendor in API changes from containers/image#64
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
… immediately needed for #52 , but also #56 was done expecting these API changes to occur.
Primarily extends usage of
types.SystemContextto creation of transport objects. See individual commits for detailed comments. Should not change behavior.