So UpdateDelegation, DeleteDelegation, AddTargets, RemoveTargets now
all check for the role existence, not metadata existence. And they
also check the role's signing keys - there's no point in adding if
we can't sign.
Signed-off-by: Ying Li <ying.li@docker.com>
Previously we were always signing it, but we can't do that anymore
because then delegated users won't be able to publish ever (they
probably don't have the target key).
Some other related changes: when role keys are rotated, that role
needs to be marked as dirty now in order to be re-signed and
published.
Signed-off-by: Ying Li <ying.li@docker.com>
This is in addition to the canonical targets role, which always gets
re-signed and publish (we may want to revisit this later).
This makes some tests pass - still need to do fallback of roles
and publishing a created delegation role without necessarily
having the signing key for that role.
Signed-off-by: Ying Li <ying.li@docker.com>
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>
Ying Li
Diogo Mónica
David Lawrence
Riyaz Faizullabhoy
David Lawrence
Miloslav Trmač
Diogo Monica
Jessica Frazelle