{"action":"created","issue":{"url":"https://api.github.com/repos/docker/docker/issues/16654","labels_url":"https://api.github.com/repos/docker/docker/issues/16654/labels{/name}","comments_url":"https://api.github.com/repos/docker/docker/issues/16654/comments","events_url":"https://api.github.com/repos/docker/docker/issues/16654/events","html_url":"https://github.com/docker/docker/issues/16654","id":108905583,"number":16654,"title":"Notary signature verification ineffective for Remote API users","user":{"login":"mtrmac","id":7052838,"avatar_url":"https://avatars.githubusercontent.com/u/7052838?v=3","gravatar_id":"","url":"https://api.github.com/users/mtrmac","html_url":"https://github.com/mtrmac","followers_url":"https://api.github.com/users/mtrmac/followers","following_url":"https://api.github.com/users/mtrmac/following{/other_user}","gists_url":"https://api.github.com/users/mtrmac/gists{/gist_id}","starred_url":"https://api.github.com/users/mtrmac/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mtrmac/subscriptions","organizations_url":"https://api.github.com/users/mtrmac/orgs","repos_url":"https://api.github.com/users/mtrmac/repos","events_url":"https://api.github.com/users/mtrmac/events{/privacy}","received_events_url":"https://api.github.com/users/mtrmac/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/docker/docker/labels/group/trust","name":"group/trust","color":"F6FBFF"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2015-09-29T16:21:21Z","updated_at":"2015-11-11T14:05:12Z","closed_at":null,"body":"The current use of notary integrated in the docker(1) CLI (as of 1.8.2) is ineffective in automated setups where Docker is driven using the Remote API without going through the CLI.\r\n\r\nCurrently, automated uses would have to either switch to using the CLI and screenscraping, or to integrate each client with the notary, and embed detailed information about the way Docker uses the notary into each client. It seems far preferable to allow the daemon perform signature verification, regardless of which client is used."},"comment":{"url":"https://api.github.com/repos/docker/docker/issues/comments/155792119","html_url":"https://github.com/docker/docker/issues/16654#issuecomment-155792119","issue_url":"https://api.github.com/repos/docker/docker/issues/16654","id":155792119,"user":{"login":"mtrmac","id":7052838,"avatar_url":"https://avatars.githubusercontent.com/u/7052838?v=3","gravatar_id":"","url":"https://api.github.com/users/mtrmac","html_url":"https://github.com/mtrmac","followers_url":"https://api.github.com/users/mtrmac/followers","following_url":"https://api.github.com/users/mtrmac/following{/other_user}","gists_url":"https://api.github.com/users/mtrmac/gists{/gist_id}","starred_url":"https://api.github.com/users/mtrmac/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mtrmac/subscriptions","organizations_url":"https://api.github.com/users/mtrmac/orgs","repos_url":"https://api.github.com/users/mtrmac/repos","events_url":"https://api.github.com/users/mtrmac/events{/privacy}","received_events_url":"https://api.github.com/users/mtrmac/received_events","type":"User","site_admin":false},"created_at":"2015-11-11T14:05:12Z","updated_at":"2015-11-11T14:05:12Z","body":"@stevvooe \r\n>  Pushing this into the daemon could make trust just as ineffective, as trust configured by one user is not firewalled from the other.\r\n\r\nVerifying trust in the daemon does not make the multi-user scenario any more difficult: each user can continue to rely on their client doing signature verification (e.g. using the code which exists right now), both verification requirements will apply at the same time. (Or the administrator could switch off the daemon-side verification and give the users complete freedom.)\r\n\r\nVerifying trust in the daemon (or perhaps in a different but equally mandatory choke point, runc?), OTOH:\r\n* Allows the system owner/administrator to define mandatory policy, where the users can’t opt out (as @endophage says, for QA signoff; or to prevent running a random possibly backdoored image just because a newbie found it referenced in some blog post; or to enforce that anything running in production has been built on the approved build system and has sources managed in the corporate SCM).\r\n* Defines the daemon’s trust mechanism and trust configuration system as *the* Docker trust mechanism and *the* Docker trust configuration syntax. If we ask every automated client to do their own trust checking, each will have integrate it with their configuration somehow, likely enough using a different format, different option names and probably subtly different semantics; a few will not be able to integrate with the Go notary client and will have to reimplement it (almost certainly diverging); and a small subset may decide they know better and implement something completely different, perhaps GPG signatures. I think such fragmentation would be unfortunate."}}