The only thing depending on signed.Sign keeping old signatures was two
tests; all real users were modifying the signed data without clearing
the old signatures, and therefore implicitly relying on signing with
the keys which were used for the old signatures as well.
This broke signing an updated root with a new certificate when the old
certificate was no longer available.
It could have been fixed by keeping signed.Sign as is and adding the
clearing to all users, but noting actually needs the appending
semantics, the appending semantics is surprising, and switching to
replacing signatures is less code.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Ordinarily we don't want to continue operating on signed data if the
role's threshold of signatures cannot be me and the signature is unsuable.
OTOH we want to keep signing root.json with all older keys if they are
available (to allow migration), but in that case a missing key is not a
fatal error.
So, split the keys passed to signed.Sign into primary and optional,
treating all current uses as primary and enforcing the role's threshold
only on primary keys. Also update the single existing test which uses
a missing/unusable key to use the optionalKeys parameter.
Note that only the _presence_ of optionalKeys is optional; if an
optional key exists but signing using it fails, the function will fail.
This temporarily breaks the second ErrInsufficientSignatures check
(optional keys count against the role threshold), but that will be fixed
soon.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Tell signed.Sign how many signatures are necessary to sign a role, and
have it fail if it cannot create that many.
For most uses this does not make much of a difference because the
threshold tends to be 1 and signed.Sign was already failing if no key
could be found or if no signature could be created; only >1-threshold
roles now (correctly) fail in additional situations. But the knowledge
of a role’s threshold will be useful in a future commit.
Always use ErrInsufficientSignatures for this failure, whether this is
when loading the keys or actually using them (also fixing
ErrInsufficentSignature documentation to refer to signing and not
verification). ErrNoKeys is no longer returned by signed.Sign.
So, adjust the “snapshot key is not available” logic in
NotaryRepository.Publish accordingly, which also makes it more precise
(actually triggering only when no snapshot key is available).
Now that role's threshold is enforced when signing, update
TestValidateRootInvalidTimestampThreshold to create the second key
necessary to correctly sign the timestamp role.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This is a refactoring with no behavior change, but it will allow adding
more parameters to the function in the future.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Actually there are two way to implement this.
One is check the present hash algorithm first and then only update
what we have.
The other is update/add both sha256 and sha512 no matter whether we
have the hash of sha512 or not.
Personally I prefer the latter, for it brings much less change of the
code and will also not affect the validate of the old clients.
Signed-off-by: Hu Keping <hukeping@huawei.com>
Updated the testutils/repo.go utility to be able to produce a repository with delegations
and to export metadata from said repo instead.
Signed-off-by: Ying Li <ying.li@docker.com>
Riyaz Faizullabhoy
Ying Li
Miloslav Trmač
David Lawrence
HuKeping
Jessica Frazelle