Add providers for signing config and legacy helper#967
Conversation
ad36d5b to
18b3a47
Compare
sigstore-java/src/main/java/dev/sigstore/SigningConfigProvider.java
Outdated
Show resolved
Hide resolved
18b3a47 to
b1cce2f
Compare
| return () -> { | ||
| try { | ||
| SigstoreTufClient tufClient = tufClientBuilder.build(); | ||
| tufClient.update(); |
There was a problem hiding this comment.
Just wondering, does this always have to be called after building a tuf client? Could it be automatic based on if the timestamp is expired?
There was a problem hiding this comment.
I think its because your local cache can be erased in between runs, you can't guarantee that state. So you have to validate it.
|
|
||
| // Temporary while the tuf repos catches up, this will still fail if the remove TUF isn't | ||
| // available to check for signing config | ||
| static SigningConfigProvider fromOrDefault( |
There was a problem hiding this comment.
What's the advantage of this method over catching if from(tuf) fails and initializing a SigstoreSigningConfig?
There was a problem hiding this comment.
This more mirrors the final expected workflow, while still allowing us to be very explicit that this will be removed once the signing config is finalized.
| var fromTuf = tufClient.getSigstoreSigningConfig(); | ||
| return fromTuf == null ? defaultConfig : fromTuf; | ||
| } catch (IOException ex) { | ||
| throw new SigstoreConfigurationException( |
There was a problem hiding this comment.
You could return defaultConfig if not null on error?
There was a problem hiding this comment.
and error may happen for other reasons that are issues with the tuf client. I would still like to fail if the error is unrelated to singingConfig missing from the repo.
sigstore-java/src/main/java/dev/sigstore/trustroot/LegacySigningConfig.java
Outdated
Show resolved
Hide resolved
And some other minor associated changes Signed-off-by: Appu Goundan <appu@google.com>
b1cce2f to
d99d67b
Compare
And some other minor associated changes as part #954