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>
Using the just added facility to generate a certificate as of a specific
time, tighten TestNewCertificate to use equality comparisons.
Signed-off-by: Miloslav Trmač <mitr@redhat.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>
Various tests have been calling trustmanager.NewCertificate and
open-coding most of cryptoservice.GenerateCertificate. So, add
cryptoservice.GenerateTestingCertificate. It differs only by using
crypto.Signer instead of data.PrivateKey because the tests
have a crypto.Signer more frequently available, and converting
from data.PrivateKey to crypto.Signer is easier than the other way.
This will make it easier to add policy parameters which the tests don't
care about to trustmanager.NewCertificate and
cryptoservice.GenerateCertificate in the future.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
The commented code is not converting DER to PEM, it is parsing DER into
an in-memory data structure, and is hopefully just as clear without a
comment.
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>
When the user insists on an invalid passphrase (or aborts the
operation), CryptoService.GetPrivateKey will try the correct root
location first, correctly failing, and then try to look for the root key
in the $gun subdirectory, and so will return the last error, a confusing
”open $path: no such file or directory”.
So, recognize the passphrase-related errors and fail with them directly.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
The gun field is not necessary yet, but will be useful in a future
commit. But including it immediately allows us to simplify by using
an ordinary method for cryptoServiceFactory instead of closures.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
None of these `filename`, `ext` or `configPath` should be in `main`,
they are all just for creating a instance of Viper and then nothing.
Do it in a separate function will make the function `main` more readable.
Signed-off-by: Hu Keping <hukeping@huawei.com>
Rather than create an SQL DB, then create a gorm BD using the SQL
DB. Also split the Create/Get test into two tests.
Signed-off-by: Ying Li <ying.li@docker.com>
Also, eliminate the timestamp JSON constant and just generate a new
one for the tests.
The client test now also uses KeyFileStore and certs.Manager to
verify the keys and certs on disk, rather than directly manipulating
the files themselves. This way, if the exact implementation of
KeyFileStore or certs.Manager changes, this test won't fail so long
as KeyFileStore and certs.Manager are self-consistent.
Signed-off-by: Ying Li <ying.li@docker.com>
Ying Li
David Lawrence
Miloslav Trmač
HuKeping
Diogo Mónica
Ying Li
David Lawrence
Jessica Frazelle