Add accessors to trustroot #432
Conversation
| assertIsPresent( | ||
| trustRoot.getTlog(key, ZonedDateTime.parse("2021-01-12T11:53:27.000Z").toInstant())); |
There was a problem hiding this comment.
Have you considered factoring out assertGetTLogExists / assertGetTLogMissing so the assertion failures could include input data rather than "expected true got false"?
There was a problem hiding this comment.
I think the failure is pretty obvious from the data/test-line-number? In particular, someone would need to inspect the full trust root json and then decide why the test is failing.
It seems to me that changes would make the tests a bit more complicated that it needs to be? But maybe I'm not seeing this the same way you are?
There was a problem hiding this comment.
okay, I think coming back to this, I see what you're saying, lemme try it out
sigstore-java/src/main/java/dev/sigstore/trustroot/SigstoreTrustedRoot.java
Outdated
Show resolved
Hide resolved
| List<CertificateAuthority> certificateAuthorities) { | ||
| var current = | ||
| certificateAuthorities.stream() | ||
| .filter(ca -> ca.getValidFor().getEnd().isEmpty()) |
There was a problem hiding this comment.
could a currentCA not have a getEnd value that's in the future?
There was a problem hiding this comment.
@znewman01 @kommendorkapten could it?
There was a problem hiding this comment.
Technically they could, but the intention is to have the current with an unspecified end. I think this is a good callout, I'll create a PR to clarify this: sigstore/protobuf-specs#80.
If the current has a known end, and due to operational constraints there may be an overlap of the validity time for a CA, so if we need to understand what CA is the current we would need to guess based on the time range which can be error-prone.
loosebazooka
force-pushed
the
plumb-tuf-client-part1
branch
from
6bb9a4d
to
4f55b3f
Compare
Specificially for CertificateAuthorities and TransparencyLogs We need to be able to query the trustroot for CAs and logs to initialize our signers and based on the material we are signing. This will eventually allow us to init a client directly from a trustroot Signed-off-by: Appu Goundan <[email protected]>
loosebazooka
force-pushed
the
plumb-tuf-client-part1
branch
from
4f55b3f
to
9b9fb4c
Compare
|
reworked this a bit to put the logic in |
We need to be able to query the trustroot for CAs and logs to initialize our signers and based on the material we are signing.
This will eventually allow us to init a client directly from a trustroot