docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

updating top level README

This commit is contained in:
David Lawrence 2015-06-19 13:32:29 -07:00
parent 03fcba1c98
commit 4cf631f670
1 changed files with 17 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
README.md
View File

@ -1,34 +1,25 @@
**N.B. The project is a work in progress and is not ready for production.**
# Notary # Notary
## Overview ## Overview
Notary Server manages trust metadata as a complementary service to the registry. The Notary project comprises server and client tools for running and interacting
It implements all endpoints under the `_trust` segment of the registry URLs. with trusted collections. Please see the READMEs for the individual tools for
Notary Server expects to manage TUF metadata and will do validation of one parent more information on their specifics.
level of content for any data uploaded to ensure repositories do not become
corrupted. This means either the keys in the root.json file will be used to
validate the uploaded role, or the keys in the immediate delegate parent will
be used.
Uploading a new root.json will be validated using the same token mechanism ## Goals
present in the registry. A user having write permissions on a repository
will be sufficient to permit the uploading of a new root.json.
## Timestamping Notary aims to make the internet more secure by making it easy for people to
publish and verify content. We often rely on TLS to secure our communications
with a web server which is inherently flawed, as any compromise of the server
enables malicious content to be substituted for the legitimate content.
TUF requires a timestamp file be regularly generated. To achieve any ease With Notary, publishers can sign their content offline using keys kept highly
of use, it is necessary that Notary Server is responsible for generating the secure. Once the publisher is ready to make the content available, they can
timestamp.json based on the snapshot.json created and uploaded by the push their signed trusted collection to a Notary Server.
repository owner.
It is bad policy to place any signing keys in frontline servers. While Consumers, having acquired the publisher's public key through a secure channel,
Notary Server is capable of supporting this behaviour we recommend using a can then communicate with any notary server or (insecure) mirror, relying
separate service and server with highly restricted permissions. Rufus only on the publisher's key to determine the validity and integrity of the
is provided as a reference implementation of a remote signer. An received content.
implementation that satisfies the gRPC interface defined in Rufus will
satisfy Notary Server's requirements.
# Running
`# docker-compose build`
`# docker-compose up`