Repository navigation
Enable trust pinning with docker content trust #84
Description
Activity
- changed the title
[-]Trust pinning cannot be enabled by docker content trust [/-][+]Enable trust pinning with docker content trust [/+]on May 15, 2017 ping @riyazdf @endophage PTAL
It's in our TODO list for the next round of
docker trustadditions. Early thoughts on the CLI syntax can be found in the "Configuring Trust in Docker" section of this doc: https://docs.google.com/document/d/1JOBAlCDuf5JnpVLW54voGuAdsnMmSR2LIbs8fjBDSaM/I talked to @cyc115 about contributing this a while ago. Are you planning to take this on or is this issue a feature request? If you're planning to implement it, let's bikeshed in this issue a little on the syntax, because I've been thinking maybe it could be shortened from
docker trust config pin ...in that doc, to justdocker trust pin ...Also, we should decide in
pinis the term we want to use. Security people will understand it, but if there's a more intuitive term we can use we're not married topin. Remember that one of the goals of thedocker trustcommand is to be more intuitive than notary and to hide the TUF concepts behind something much more friendly to the typical user.This feature is super important...Any updates on progress? Is there a potential for a workaround? That is, if I have a notary client and configure notary trust pinning commands while the notary trust_dir is set to ~/.docker/trust, will docker's imbedded notary component pick it up and honor the config?
See also this issue, which would require explicit user approval before TOFU
- closing because we removed
docker trustfrom the CLI; remove support for client-side docker content trust validation #6603
- closing because we removed
So, uhh, you guys just decided to give up on any chance of providing security in docker?
Description
The current version of notary currently support two types of trust pinnings: 1) certificate pinning that pins to a specific certificate and 2) CA pinning that uses a provided certificate of a trusted CA to validate the leaf certificate in the metadata.
Having the ability to pin to a trusted certificate/CA is extremely important as the current TUFUs model does not prevent MIMA for those who is pulling from the repository for the very first time.
At the moment, this feature seems to be disabled as an empty trust pin config is being passed into
client.NewNotaryRepository().