17:02:14 #startmeeting 2018-12-18 distribution spec walkthrough 17:02:14 Meeting started Tue Dec 18 17:02:14 2018 UTC. The chair is vbatts|work. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:14 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:02:14 The meeting name has been set to '2018_12_18_distribution_spec_walkthrough' 17:02:43 #topic intro and intention 17:02:55 #link https://github.com/opencontainers/distribution-spec/issues/24 17:03:25 #link https://github.com/kinvolk/ocicert/ 17:09:22 * vbatts|work should've thought about screen sharing ... 17:13:27 https://github.com/docker/distribution/tree/master/registry/handlers 17:13:30 https://github.com/docker/distribution/blob/master/registry/handlers/api_test.go 17:14:56 * sangy sighs, probably his mic doesn't work 17:15:26 https://github.com/docker/distribution/blob/master/registry/api/v2/descriptors.go 17:15:57 wanted to ask (I'm new around here) would something similar to DCT be backported into the distribution spec? (full disclosure, I'm part of the TUF team) 17:20:42 sangy: link to DCT, please? 17:20:57 https://docs.docker.com/engine/security/trust/content_trust/ 17:21:28 Docker Content Trust (CNCF Notary/Trust); but since Notary works to sign any content blob, what would be the "backport" into the spec? 17:21:49 meant: "(CNCF Notary/TUF)" 17:23:10 estesp: I may be missing information, but pretty much tying up the concept of a tag to a namespace/id that can be secured with Notary/TUF 17:25:53 dongsu: did you try screen share again? 17:27:55 vbatts|work: yes, but it didn't work 17:28:11 dongsu: ok. did you see my screen? 17:28:23 vbatts|work: yes I could see your screen 17:28:32 dongsu: ok 17:28:45 dongsu: how do i authenticate to do the push test? 17:29:14 vbatts|work: I haven't managed to do it 17:29:20 ah 17:29:22 :-) 17:30:10 DCT doesn't need to be included in the distribution spec 17:30:14 it's overlaid on top of it 17:31:24 fair enough, thanks for clearing it up :) 17:31:27 that was my perspective/understanding; notary has it's own server and validates a specific hash has a certain signature 17:32:15 beyond that, I'm not sure what integration would even make sense as notary is currently unlinked to anything specific to containers at all (since you can use TUF/Notary to sign any kind of blob) 17:32:51 make ro-test 17:32:55 make rw-test 17:33:16 I'd have to read more on the distribution spec exactly because of that. I don't know if it covers a GUN-identifier sort of specification, from which we can anchor namespaces into Notary/TUF 17:33:25 estesp: ^ 17:35:10 credential-helpers for testing with 17:35:35 repasted: https://github.com/docker/docker-credential-helpers 17:35:40 #link https://github.com/docker/docker-credential-helpers 17:35:46 sangy: ty :-) 17:35:52 Calavera (from Netlify) has a nice blog post on using them 17:36:15 vbatts|work: np! :) 17:36:27 https://medium.com/@calavera/stop-saving-credential-tokens-in-text-files-65e840a237bb 17:36:39 #link https://github.com/calavera/docker-credential-helpers 17:36:45 #link https://medium.com/@calavera/stop-saving-credential-tokens-in-text-files-65e840a237bb 17:42:05 #action look to cargo-cult from a basis of github.com/docker/distribution/blob/master/registry/api/v2/descriptors.go github.com/docker/distribution/blob/master/registry/handlers/api_test.go 17:43:13 #action basic helper to use an opaque blob for authentication token to test 'rw-test' with 17:44:58 #action merge the ocicert repo into the distribution-spec/ repo 17:57:53 cloud-native.slack.com 17:58:04 open-containers channel created 18:02:43 #endmeeting