-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature flag for requiring global HPKE keys #3268
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The approach SGTM. 👍🏻
/// Experimental. Always advertise global HPKE keys instead of per-task HPKE keys. This will | ||
/// become on by default in a future version of Janus. | ||
#[serde(default)] | ||
pub require_global_hpke_keys: Option<bool>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: is None
the same as Some(false)
? if so, for simplicity I think this should just be a bool
which defaults to false
, so that we only interpret a missing value once.
3503372
to
aeaba92
Compare
aeaba92
to
1543ca7
Compare
Eh, pulling this back to draft, I think some work on integration/interop tests is justified here. |
I've made integration and inteorp tests use the flag. I'll make unit tests use it in the next PR, to keep this PR relatively small. |
Supports #2147.
Introduces a feature flag
require_global_hpke_keys
. When this is enabled:GlobalHpkeKeypairCache
blocks and retries fetching keys until it gets a list containing at least one active key. This is a bootstrapping case--it allows for the key rotator to do initialization, whether it's running in-process or separately./hpke_configs
endpoint unconditionally returns global keys, regardless of the?task_id
parameter.Draft, as it needs refactoring and more testing. Looking for feedback on whether the overall approach is sane.