This should make it possible to delegate snapshot key management
to the server for existing repos, or switching back to user managing
snapshot keys.
Signed-off-by: Ying Li <ying.li@docker.com>
or unreadable.
This also modifies tuf/store/filestore to return ErrMetaNotFound if the
metadata file does not exist.
Signed-off-by: Ying Li <ying.li@docker.com>
- add a specific error type when the server is requested to manage
an unsupported key type
- variable name change
Signed-off-by: Ying Li <ying.li@docker.com>
This supports the case of a user intializing a repo so that the server
signs the snapshot, and then changing their minds and rotating the keys
so that they now sign the snapshot, but all before publishing a single
thing.
Signed-off-by: Ying Li <ying.li@docker.com>
The errors returned by the server aren't great right now, so it's hard
to try to be clever in synthesizing a signed.ErrNoKeys{}.
Signed-off-by: Ying Li <ying.li@docker.com>
When publishing, do not sign and send the snapshot metadata if the
client does not have the snapshot key. If the server sends back
an error, then it also does not have a snapshot key and the
client should propogate the no signing key error.
Signed-off-by: Ying Li <ying.li@docker.com>
If configured to have the server manage the snapshot key, the snapshot
key is not generated and there will be no snapshot metadata.
Signed-off-by: Ying Li <ying.li@docker.com>
Add explicit startTime and endTime parameters to
cryptoservice.GenerateCertificate and trustmanager.NewCertificate.
trustmanager.NewCertificate as a low-level data manipulation function
should not be hard-coding policy (10-year expiration); that policy
belongs to its callers, or one more level higher to callers of
cryptoservice.GenerateCertificate.
These places hard-coding policy now also have an explict comment to
that effect.
In addition to conceptual cleanliness, this will allow writing tests
of certificate expiry by generating appropriate expired or nearly-expired
certificates.
Tests which don't care about the policy much will continue to use the
just added cryptoservice.GenerateTestingCertificate.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
1. It is on a path where those errors can never happen
2. The specific error handling would silently ignore the error, which
can’t be right anyway.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Currently, when listing, publishing, or getting a particular target,
if the remote server errors, the client attempts to load it from a
local cache. However, if there is no local cache, it just returns
Metadata Not Found for listing and getting. Have it report the
remote the original remote error instead of Metadata Not Found
locally.
Signed-off-by: Ying Li <ying.li@docker.com>
over the root keys directory from non-root keys directory from keystoremanager
to keystore, since we're eliminating keystoremanager.
Maintain the two separate directories, though, because one can't tell whether
there is an old-style separate-directories structure, or if someone has a GUN
that starts with tuf_keys.
Signed-off-by: Ying Li <ying.li@docker.com>
Ying Li
David Lawrence
David Lawrence
Miloslav Trmač
Diogo Monica
Jessica Frazelle
Ryan Cox
Diogo Mónica