Skip to content
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

Key lifecycle #459

Closed
wants to merge 38 commits into from
Closed

Key lifecycle #459

wants to merge 38 commits into from

Conversation

Philip-NLnetLabs
Copy link
Member

Basic support for a collection of keys that sign a zone and key rolls.

@Philip-NLnetLabs Philip-NLnetLabs marked this pull request as draft November 28, 2024 15:03
@Philip-NLnetLabs Philip-NLnetLabs marked this pull request as ready for review December 2, 2024 14:19
@Philip-NLnetLabs Philip-NLnetLabs requested a review from a team December 2, 2024 14:20
Copy link
Contributor

@bal-e bal-e left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really neat! I can't verify all the logic of the key state transitions, but I've commented on the implementation code.

I'm concerned about how users are supposed to react if one of the key transition functions returns an error. I suppose this relates back to the TODO comment for aborting or canceling rollovers.

I think the single most important thing is to make KeyState.keys a hash map. This should greatly simplify a lot of the code accessing those keys, and it'll make the control flow and logic in the PR a lot easier. It should also noticeably reduce the size of the PR.

examples/lookup.rs Outdated Show resolved Hide resolved
src/sign/keyset.rs Outdated Show resolved Hide resolved
Comment on lines 846 to 851
#[derive(Clone, Debug, Deserialize, Serialize)]
/// A type that contains Unix time.
///
/// Unix time is the number of seconds since midnight January first
/// 1970 GMT.
pub struct UnixTime(Duration);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why std::time::SystemTime was not satisfactory? SystemTime::duration_since(UNIX_EPOCH) already provides a measure of Unix time, and users of this crate will expect standard time types instead of custom ones. I strongly recommend using SystemTime or adding a comment here explaining the need for UnixTime.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason is serde. I want to make sure that the time goes out as seconds since unix epoch. I don't think SystemTime guarantees that. After discussion with @partim we concluded that a type that is clearly defined as Unix time could be useful in more places.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's understandable. But I had a peek at serde: the impl Serialize for SystemTime shows that it serializes as seconds and nanoseconds since the Unix Epoch. I'm sure they can't change this now, for backward compatibility, so you can rely on it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can change that later if it makes sense. I don't like relying on undocumented features. It is also important that any time related type is easy to mock.

src/sign/keyset.rs Outdated Show resolved Hide resolved
src/sign/keyset.rs Outdated Show resolved Hide resolved
examples/keyset.rs Show resolved Hide resolved
src/sign/keyset.rs Outdated Show resolved Hide resolved
src/sign/keyset.rs Show resolved Hide resolved
src/sign/keyset.rs Show resolved Hide resolved
src/sign/keyset.rs Show resolved Hide resolved
Copy link
Contributor

@bal-e bal-e left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, @Philip-NLnetLabs. Nicely done!

Philip-NLnetLabs added a commit that referenced this pull request Dec 19, 2024
@Philip-NLnetLabs Philip-NLnetLabs deleted the key-lifecycle branch December 19, 2024 13:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants