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

docker trust: view, revoke, sign subcommands (experimental) #472

Merged
merged 20 commits into from Sep 26, 2017

Conversation

@riyazdf

riyazdf commented Aug 24, 2017

This PR introduces the docker trust subcommand. The command has been fleshed out in detail in this design document. docker trust provides a direct notary signing experience beyond what is provided with the DOCKER_CONTENT_TRUST environment variable.

In this PR, we introduce three subcommands:

  • docker trust view: displays signatures on image tags, and who signed them
  • docker trust revoke: revokes signatures from signed image tag(s)
  • docker trust sign: adds a signature to an image tag, pushing the image if it doesn't already exist

cc @ashfall and @eiais who helped implement this feature

@mistyhacks

Several copyedit-style comments. In addition, scrub all occurrences of "like so", "please", and future-facing prose like "will sign" or "will create". In docs, we live in the eternal present and we don't say "please". :) Likewise, the phrase "note that".

Show outdated Hide outdated docs/reference/commandline/trust_inspect.md Outdated
Show outdated Hide outdated docs/reference/commandline/trust_inspect.md Outdated
Show outdated Hide outdated docs/reference/commandline/trust_inspect.md Outdated
Show outdated Hide outdated docs/reference/commandline/trust_inspect.md Outdated
Show outdated Hide outdated docs/reference/commandline/trust_inspect.md Outdated
Show outdated Hide outdated docs/reference/commandline/trust_sign.md Outdated
Show outdated Hide outdated docs/reference/commandline/trust_sign.md Outdated
@@ -78,18 +78,21 @@ to use `notary` with Docker images.
## Building Notary
Prerequisites:
Note that our [latest stable release](https://github.com/docker/notary/releases) is at the head of the

This comment has been minimized.

@mistyhacks

mistyhacks Aug 25, 2017

Contributor

s/Note that our/Notary's

@mistyhacks

mistyhacks Aug 25, 2017

Contributor

s/Note that our/Notary's

This comment has been minimized.

@riyazdf

riyazdf Aug 25, 2017

vendored code - we can address this in docker/notary

@riyazdf

riyazdf Aug 25, 2017

vendored code - we can address this in docker/notary

Run `make binaries`, which creates the Notary Client CLI binary at `bin/notary`.
Note that `make binaries` assumes a standard Go directory structure, in which
Run `make client`, which creates the Notary Client CLI binary at `bin/notary`.
Note that `make client` assumes a standard Go directory structure, in which
Notary is checked out to the `src` directory in your `GOPATH`. For example:
```

This comment has been minimized.

@mistyhacks

mistyhacks Aug 25, 2017

Contributor

Newlines

@mistyhacks

mistyhacks Aug 25, 2017

Contributor

Newlines

This comment has been minimized.

@riyazdf

riyazdf Aug 25, 2017

vendored code - we can address this in docker/notary

@riyazdf

riyazdf Aug 25, 2017

vendored code - we can address this in docker/notary

@@ -98,3 +101,5 @@ $GOPATH/
docker/
notary/
```
To build the server and signer, please run `docker-compose build`.

This comment has been minimized.

@mistyhacks

mistyhacks Aug 25, 2017

Contributor

s/please//

@mistyhacks

mistyhacks Aug 25, 2017

Contributor

s/please//

This comment has been minimized.

@riyazdf

riyazdf Aug 25, 2017

vendored code - we can address this in docker/notary

@riyazdf

riyazdf Aug 25, 2017

vendored code - we can address this in docker/notary

@riyazdf

This comment has been minimized.

Show comment
Hide comment
@riyazdf

riyazdf Aug 25, 2017

thank you @mstanleyjones for the review! Just updated with the fixes, and left a comment about one potential command output change.

riyazdf commented Aug 25, 2017

thank you @mstanleyjones for the review! Just updated with the fixes, and left a comment about one potential command output change.

@dnephin

Cool!

This is a big change so I looked over the first two commands for now.

Re: testing, I think the tests you have look great, but we need to fake the notary client so we're not actually making HTTP requests in unit tests.

An end-to-end test for each of the commands (inspect, revoke, sign) would be great as well. We'll want to add a notary service to compose-env.yaml so we're testing against an isolated service. I think that can be done in a separate follow up PR.

We just merged https://github.com/docker/cli/blob/master/TESTING.md which has a bit more information as well

// trustedPush handles content trust pushing of an image
func trustedPush(ctx context.Context, cli command.Cli, repoInfo *registry.RepositoryInfo, ref reference.Named, authConfig types.AuthConfig, requestPrivilege types.RequestPrivilegeFunc) error {
// TrustedPush handles content trust pushing of an image
func TrustedPush(ctx context.Context, cli command.Cli, repoInfo *registry.RepositoryInfo, ref reference.Named, authConfig types.AuthConfig, requestPrivilege types.RequestPrivilegeFunc) error {

This comment has been minimized.

@dnephin

dnephin Aug 25, 2017

Collaborator

We have a package at cli/trust. Do you think it would make sense to move these functions (this one and the few below that are either already exported, or were changed to exported) into the cli/trust package, now that they are being shared between multiple commands?

@dnephin

dnephin Aug 25, 2017

Collaborator

We have a package at cli/trust. Do you think it would make sense to move these functions (this one and the few below that are either already exported, or were changed to exported) into the cli/trust package, now that they are being shared between multiple commands?

This comment has been minimized.

@riyazdf

riyazdf Aug 25, 2017

I think we certainly can for the GetSignableRoles function and so I've moved over.

This one is a little more tricky because it calls imagePushPrivileged - can we export that function?

@riyazdf

riyazdf Aug 25, 2017

I think we certainly can for the GetSignableRoles function and so I've moved over.

This one is a little more tricky because it calls imagePushPrivileged - can we export that function?

This comment has been minimized.

@dnephin

dnephin Aug 26, 2017

Collaborator

Ya, I think it makes sense to export it. There's nothing in there that's really specific to the command routing. The only change I would make is to accept a client.ImageAPIClient instead of the full command.Cli

@dnephin

dnephin Aug 26, 2017

Collaborator

Ya, I think it makes sense to export it. There's nothing in there that's really specific to the command routing. The only change I would make is to accept a client.ImageAPIClient instead of the full command.Cli

Show outdated Hide outdated cli/command/trust/cmd.go Outdated
Show outdated Hide outdated cli/command/trust/helpers.go Outdated
Show outdated Hide outdated cli/command/trust/helpers.go Outdated
Show outdated Hide outdated cli/command/trust/helpers.go Outdated
Show outdated Hide outdated cli/command/trust/inspect_test.go Outdated
Show outdated Hide outdated cli/command/trust/revoke.go Outdated
Show outdated Hide outdated cli/command/trust/revoke.go Outdated
Show outdated Hide outdated cli/command/trust/revoke.go Outdated
Show outdated Hide outdated cli/command/trust/inspect_test.go Outdated
@dnephin

This comment has been minimized.

Show comment
Hide comment
@dnephin

dnephin Aug 25, 2017

Collaborator

I think the design looks good. It sounds like you've already done a lot of work on the design before opening this PR so I mostly focused on the code.

Collaborator

dnephin commented Aug 25, 2017

I think the design looks good. It sounds like you've already done a lot of work on the design before opening this PR so I mostly focused on the code.

@riyazdf

This comment has been minimized.

Show comment
Hide comment
@riyazdf

riyazdf Aug 26, 2017

@dnephin: thank you for the review! I've addressed all comments except for the following:

  • for the notary tag you suggest: there isn't a "canonical" notary server or a way to currently pre-configure one per-image (you could in theory contact a different one for different images) - so I'm inclined to add this later if you think that makes sense
  • I've flattened the map for the admin keys. Haven't done so for signers and the signatures because I want to make sure I don't mess up the table printing 😅
  • totally agree for mocking out the notary client behind the CLI so we can mock it. Will get to this.

riyazdf commented Aug 26, 2017

@dnephin: thank you for the review! I've addressed all comments except for the following:

  • for the notary tag you suggest: there isn't a "canonical" notary server or a way to currently pre-configure one per-image (you could in theory contact a different one for different images) - so I'm inclined to add this later if you think that makes sense
  • I've flattened the map for the admin keys. Haven't done so for signers and the signatures because I want to make sure I don't mess up the table printing 😅
  • totally agree for mocking out the notary client behind the CLI so we can mock it. Will get to this.
@dnephin

This comment has been minimized.

Show comment
Hide comment
@dnephin

dnephin Aug 26, 2017

Collaborator

so I'm inclined to add [the notary tag] later if you think that makes sense

Sounds good. I think we can forget about the tag, I can't think of a good reason to hide the commands.

Collaborator

dnephin commented Aug 26, 2017

so I'm inclined to add [the notary tag] later if you think that makes sense

Sounds good. I think we can forget about the tag, I can't think of a good reason to hide the commands.

@riyazdf

This comment has been minimized.

Show comment
Hide comment
@riyazdf

riyazdf Sep 1, 2017

Some small updates: I've made a couple of tweaks to address small discrepancies in CLI output and we also have an interface for a trust repository incoming from Notary theupdateframework/notary#1220 that will help provide testable mocks for this PR. I'll update here once that is merged and vendored.

riyazdf commented Sep 1, 2017

Some small updates: I've made a couple of tweaks to address small discrepancies in CLI output and we also have an interface for a trust repository incoming from Notary theupdateframework/notary#1220 that will help provide testable mocks for this PR. I'll update here once that is merged and vendored.

@riyazdf

This comment has been minimized.

Show comment
Hide comment
@riyazdf

riyazdf Sep 12, 2017

@dnephin: I've rebased and vendored in the notary client interface and exposed it as cli.NotaryClient. I'm rewriting the tests now to use mocks of that, but figured I'd push the update so you can see how the cli changes look

riyazdf commented Sep 12, 2017

@dnephin: I've rebased and vendored in the notary client interface and exposed it as cli.NotaryClient. I'm rewriting the tests now to use mocks of that, but figured I'd push the update so you can see how the cli changes look

@dnephin

Thanks, looks good

Show outdated Hide outdated cli/command/cli.go Outdated
Show outdated Hide outdated cli/command/cli.go Outdated
@dnephin

Tests are looking good, just a few comments.

Show outdated Hide outdated cli/command/cli.go Outdated
Show outdated Hide outdated cli/command/trust/cli_test.go Outdated
Show outdated Hide outdated cli/command/trust/inspect_test.go Outdated
Show outdated Hide outdated cli/command/trust/inspect_test.go Outdated
@dnephin

If you rebase you should pickup the fix for e2e. Once the build is green we'll get a coverage report, and then I'll think this looks to be ready for merge.

Show outdated Hide outdated cli/command/image/trust_test.go Outdated
@riyazdf

This comment has been minimized.

Show comment
Hide comment
@riyazdf

riyazdf Sep 15, 2017

thank you @dnephin for your continuous review! Just updated the tests and rebased.

riyazdf commented Sep 15, 2017

thank you @dnephin for your continuous review! Just updated the tests and rebased.

@dnephin

LGTM

@mistyhacks

LGTM, left a couple comments. I think maybe for the tests we should stick to the alice/bob/claire convention and not use real names. Also had a question about two of the tests that seem to be really testing for the same condition...

Show outdated Hide outdated cli/command/formatter/trust_test.go Outdated
Show outdated Hide outdated cli/command/trust/inspect_test.go Outdated
@vieux

This comment has been minimized.

Show comment
Hide comment
@vieux

vieux Sep 19, 2017

Contributor

@johnstep can you please take a look at this ? to make sure it works well on windows.

Contributor

vieux commented Sep 19, 2017

@johnstep can you please take a look at this ? to make sure it works well on windows.

@johnstep

This comment has been minimized.

Show comment
Hide comment
@johnstep

johnstep Sep 19, 2017

Contributor

Yes, will look today.

Contributor

johnstep commented Sep 19, 2017

Yes, will look today.

@thaJeztah

Sorry for being late in reviewing (catching up after my vacation). I gave this PR a spin, and wrote up more from a UX perspective after playing around with it 😊

Some inconsistencies from an UX perspective:

docker trust inspect doesn't default to :latest

Running docker trust inspect without specifying a :tag, lists all tags for the repository. This is inconsistent with other commands, which default to :latest if the tag is omitted. For comparisson, docker pull requires adding the -a / --all-tags flag to pull all tags from the repository;

docker pull --help

Usage:	docker pull [OPTIONS] NAME[:TAG|@DIGEST]

Pull an image or a repository from a registry

Options:
  -a, --all-tags                Download all tagged images in the repository
      --disable-content-trust   Skip image verification (default true)
      --help                    Print usage

Perhaps docker trust inspect should use the same approach: inspect :latest by default, and have an -a / --all-tags flag to fetch all tags.

sha256: prefix missing for digests

For example, docker image ls --digests includes the sha256: prefix in the DIGEST column. We should probably print it here as well (also in case other hashing is used in future?)

No REPOSITORY column in output of docker trust inspect

Also for consistency; perhaps we should have a REPOSITORY and TAG columns in the output; more consistent with docker images, and would allow accepting multiple repositories as argument in future (docker trust inspect <repo1> <repo2>)

Is there a way to show unsigned tags in a repository?

Thinking out loud here: as a user, I may be interested to check which tags in a repository are not yet signed (so that I can sign them). Once a --filter option is added, those could be omitted (or included if the default should be to only show signed tags).

$ docker trust inspect myname/myrepo
REPOSITORY      TAG            DIGEST                                                             SIGNERS
myname/myrepo   latest         99ccecf3da28a93c063d5dddcdf69aeed44826d0db219aabc3d5178d47649dfa   (Repo Admin)
myname/myrepo   v1.0.0         974c59c89665e01151571c6a50c0b7ef0bee941ef16d81ced1cf29073547ea8a   <none>
myname/myrepo   v1.0.1         7713b80b59cfc144ef87b3f272d156ce2dbf0f6b3ec4c1171c0c3d8b2ac229b7   <none>

Output format of docker trust inspect

This is a bit tricky: historically, all our inspect commands output as JSON by default, allowing to use a custom format (--format), and for some commands, having a --pretty option to print in a more human-readable format.

I realize that the JSON output is not very useful to quickly view information, so definitely see a need to have a default that's more readable. From a consistency perspective though, docker trust inspect should output JSON.

So what's the alternative?

I was thinking of that a while back; perhaps we should start thinking of a new set of subcommands for Docker objects that default to a human-readable format; something like docker <object> print, docker <object> view or docker <object> show. If we can come to an agreement on that, the docker trust subcommand could be the first type of "object" to use such a command (e.g., docker trust view <repo>[:tag]). We can keep a docker trust inspect subcommand for later addition if we want.

docker trust sign and pushing

Wondering if it's always desirable to push the image, or if there should be an option to either make pushing optional, or to disable pushing.

Update:

I just signed another image, and noticed it did a push before asking for my passphrase to sign the image. I did not expect that (in my mental model, signing and pushing are separate actions); I would've expected a confirmation to sign (and push) the image, especially since accidentally selecting the (wrong) image will overwrite existing images in the registry.

docker trust sign alternative keys?

Just wondering here: Is there a way to specify which key to sign an image with? Could I have multiple keys, and need to specify which key to use? If so; should there be a docker trust keys subcommand, showing all keys that I have present?

Unauthorized shows HTTP status code

Not sure we should print HTTP status codes here, feels like an implementation detail. If we do want more information, I'd be interested what server returned that error (also, is that configurable? where can I find it?).

$ docker trust sign foo:latest
you are not authorized to perform this operation: server returned 401.

Instructions could use some formatting

The instructions when signing could use a bit of reformattting; it's quite a wall of text.

$ docker trust sign thajeztah/testing:latest
You are about to create a new root signing key passphrase. This passphrase
will be used to protect the most sensitive key in your signing system. Please
choose a long, complex passphrase and be careful to keep the password and the
key file itself secure and backed up. It is highly recommended that you use a
password manager to generate the passphrase and keep it safe. There will be no
way to recover this key. You can find the key in your config directory.
Enter passphrase for new root key with ID 9636fc9:
Repeat passphrase for new root key with ID 9636fc9:
Enter passphrase for new repository key with ID 94fb4d2:
Repeat passphrase for new repository key with ID 94fb4d2:
you are not authorized to perform this operation: server returned 401.

Quotes between repo and tag

docker trust sign thajeztah/testing:latest
Enter passphrase for root key with ID 9636fc9:
Enter passphrase for new repository key with ID 19ba70d:
Repeat passphrase for new repository key with ID 19ba70d:
Enter passphrase for new thajeztah key with ID 9ae2e44:
Repeat passphrase for new thajeztah key with ID 9ae2e44:
Created signer: thajeztah
Finished initializing signed repository for thajeztah/testing:latest
The push refers to a repository [docker.io/thajeztah/testing]
2d37a63fe311: Pushed
db8bf4510ce1: Mounted from library/python
4af7c20a45bb: Mounted from library/python
07d54c9d22d6: Mounted from library/python
590266e37bf8: Mounted from library/python
ba2cc2690e31: Mounted from library/python
latest: digest: sha256:43a0097ba50ce3a0547316a1142d7cc46062d051155f760e28619e8d99cddc25 size: 1579
Signing and pushing trust metadata
Enter passphrase for thajeztah key with ID 9ae2e44:
Successfully signed "docker.io/thajeztah/testing":latest

In the last line, there's quotes around the repository, and the :latest tag is printed outside of the quotes:

Successfully signed "docker.io/thajeztah/testing":latest

Also wondering if it should print the digest that was signed as well.

Show outdated Hide outdated docs/reference/commandline/trust_sign.md Outdated
@riyazdf

This comment has been minimized.

Show comment
Hide comment
@riyazdf

riyazdf Sep 19, 2017

@thaJeztah: thank you for the very thorough review and thoughtful writeup! I've replied inline. Please let me know if our (cc @ashfall @eiais) reasoning doesn't make sense.

I think the most pressing issue that we should address in this PR is renaming docker trust inspect to docker trust view or similar. There are a few other issues you've raised that definitely deserve followup PRs and we can help with those.

docker trust inspect doesn't default to :latest

For Content Trust (and docker trust) most operations affect a full repository, as all signers and keys are assigned per-repo - so my gut is that we should have the default information display per-repo. It's also likely that repos may have signed tags, but not a signed latest tag, which would make docker trust inspect <repo> confusing if no signed tags showed up.

sha256: prefix missing for digests

We intentionally omitted this since it is repetitive information at present. I'd be inclined to add the prefix once we support multi-hashing - WDYT?

No REPOSITORY column in output of docker trust inspect

docker trust inspect operates over a single repository. Operating over multiple repositories would be very confusing because the keys and signers are per-repo. So for that reason I do not think we should have a REPOSITORY column.

Is there a way to show unsigned tags in a repository?

We intentionally omitted unsigned tags because they are unpullable with DOCKER_CONTENT_TRUST=1.

Output format of docker trust inspect

We've discussed this at length with @dnephin: IIRC we agreed to potentially add JSON output controlled by a flag in the future - though as you mention this isn't consistent with other inspect commands.

We had initially named this command docker trust info - if you prefer we revert to that name I wouldn't be opposed; I don't think JSON output would be very helpful for this information by default, I'd like it to be an optional --json or similar flag if we deem it desirable. docker trust view could work as well.

docker trust sign and pushing

If the image doesn't exist: docker trust sign will push and sign the image because a signature without associated image data is not of much use because you won't be able to pull down or run the image.

As for the ordering of push and signing: this mimics the behavior users are accustomed to from DOCKER_CONTENT_TRUST=1 docker push and so we decided to keep this consistent. Also, if there is a failure during the image push, we won't sign anything because there is no content to reference.

docker trust sign alternative keys?

We're actually just about to follow up with docker trust key-* commands! docker trust sign could also take on a --key flag in the future if we deem this useful.

Unauthorized shows HTTP status code

This is also an issue in DCT:

$ DOCKER_CONTENT_TRUST=1 docker pull foo:latest
you are not authorized to perform this operation: server returned 401.

I'm happy to update this but I'd prefer this to be a separate PR to update both errors for consistency.

Instructions could use some formatting

This is also from DCT and Notary, but I think this is necessary. It is a lot of text but it is interactive and for entering sensitive passphrases.

Quotes between repo and tag
...
In the last line, there's quotes around the repository, and the :latest tag is printed outside of the quotes:
Successfully signed "docker.io/thajeztah/testing":latest

This is an issue across both DCT and docker trust: I'd be more than happy to update both in a followup.

Also wondering if it should print the digest that was signed as well.

It's printed a couple of lines above.

cc @ruchitarr

riyazdf commented Sep 19, 2017

@thaJeztah: thank you for the very thorough review and thoughtful writeup! I've replied inline. Please let me know if our (cc @ashfall @eiais) reasoning doesn't make sense.

I think the most pressing issue that we should address in this PR is renaming docker trust inspect to docker trust view or similar. There are a few other issues you've raised that definitely deserve followup PRs and we can help with those.

docker trust inspect doesn't default to :latest

For Content Trust (and docker trust) most operations affect a full repository, as all signers and keys are assigned per-repo - so my gut is that we should have the default information display per-repo. It's also likely that repos may have signed tags, but not a signed latest tag, which would make docker trust inspect <repo> confusing if no signed tags showed up.

sha256: prefix missing for digests

We intentionally omitted this since it is repetitive information at present. I'd be inclined to add the prefix once we support multi-hashing - WDYT?

No REPOSITORY column in output of docker trust inspect

docker trust inspect operates over a single repository. Operating over multiple repositories would be very confusing because the keys and signers are per-repo. So for that reason I do not think we should have a REPOSITORY column.

Is there a way to show unsigned tags in a repository?

We intentionally omitted unsigned tags because they are unpullable with DOCKER_CONTENT_TRUST=1.

Output format of docker trust inspect

We've discussed this at length with @dnephin: IIRC we agreed to potentially add JSON output controlled by a flag in the future - though as you mention this isn't consistent with other inspect commands.

We had initially named this command docker trust info - if you prefer we revert to that name I wouldn't be opposed; I don't think JSON output would be very helpful for this information by default, I'd like it to be an optional --json or similar flag if we deem it desirable. docker trust view could work as well.

docker trust sign and pushing

If the image doesn't exist: docker trust sign will push and sign the image because a signature without associated image data is not of much use because you won't be able to pull down or run the image.

As for the ordering of push and signing: this mimics the behavior users are accustomed to from DOCKER_CONTENT_TRUST=1 docker push and so we decided to keep this consistent. Also, if there is a failure during the image push, we won't sign anything because there is no content to reference.

docker trust sign alternative keys?

We're actually just about to follow up with docker trust key-* commands! docker trust sign could also take on a --key flag in the future if we deem this useful.

Unauthorized shows HTTP status code

This is also an issue in DCT:

$ DOCKER_CONTENT_TRUST=1 docker pull foo:latest
you are not authorized to perform this operation: server returned 401.

I'm happy to update this but I'd prefer this to be a separate PR to update both errors for consistency.

Instructions could use some formatting

This is also from DCT and Notary, but I think this is necessary. It is a lot of text but it is interactive and for entering sensitive passphrases.

Quotes between repo and tag
...
In the last line, there's quotes around the repository, and the :latest tag is printed outside of the quotes:
Successfully signed "docker.io/thajeztah/testing":latest

This is an issue across both DCT and docker trust: I'd be more than happy to update both in a followup.

Also wondering if it should print the digest that was signed as well.

It's printed a couple of lines above.

cc @ruchitarr

riyazdf added some commits Aug 24, 2017

trust inspect: docs for docker trust inspect
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
trust sign: add docker trust sign command
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
trust sign: docs for docker trust sign
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
trust revoke: add docker trust revoke command
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
trust revoke: docs for docker trust revoke
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
docs: update docker trust docs with correct tense and formatting
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
trust: address review feedback, refactor to align with existing cli/c…
…ommand semantics

Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
trust: add Repository client interface
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
cli: introduce NotaryClient getter
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
trust: use mock CLI for testing offline
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
tests: address review feedback
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
trust: update reference type and use golden output
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
tests: move trust test to proper package
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
trust: update remove to error on empty references for consistency
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
tests: use alice/bob/claire conventional names for signers
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
trust: rename inspect to view, add repo name to signer table header
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
mark command as experimental in docs and cli
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
@thaJeztah

changes and putting it as "experimental" LGTM - we can address tweaking the commands/UX in follow ups

@johnstep

This comment has been minimized.

Show comment
Hide comment
@johnstep

johnstep Sep 26, 2017

Contributor

I verified that signing and viewing works from Windows.

Contributor

johnstep commented Sep 26, 2017

I verified that signing and viewing works from Windows.

@vieux

vieux approved these changes Sep 26, 2017

@vieux vieux merged commit af3cdcc into docker:master Sep 26, 2017

7 checks passed

ci/circleci: cross Your tests passed on CircleCI!
Details
ci/circleci: lint Your tests passed on CircleCI!
Details
ci/circleci: shellcheck Your tests passed on CircleCI!
Details
ci/circleci: test Your tests passed on CircleCI!
Details
ci/circleci: validate Your tests passed on CircleCI!
Details
continuous-integration/jenkins/pr-head This commit looks good
Details
dco-signed All commits are signed

@GordonTheTurtle GordonTheTurtle added this to the 17.10.0 milestone Sep 26, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment