-
Notifications
You must be signed in to change notification settings - Fork 1
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
Security Shield builder API updates #343
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #343 +/- ##
==========================================
+ Coverage 92.81% 92.84% +0.02%
==========================================
Files 1154 1160 +6
Lines 25738 25797 +59
Branches 85 85
==========================================
+ Hits 23890 23952 +62
+ Misses 1837 1834 -3
Partials 11 11
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
crates/core/utils/src/constants.rs
Outdated
pub const DAYS_PER_WEEK: u16 = 7; | ||
|
||
/// Number of days per year. | ||
pub const DAYS_PER_YEAR: u16 = DAYS_PER_WEEK * WEEKS_PER_YEAR; |
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.
Do we want to skip 1 day? Since this is 364.
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.
Right, I'm not sure. Maybe it's best to make it 365 with the downside of being unable to express a year in a fixed number of weeks, but I guess it's fine since we don't need that now anyway.
@@ -23,6 +23,13 @@ impl Threshold { | |||
Threshold::Specific(value) => *value, | |||
} | |||
} | |||
|
|||
/// Returns the selectable values for a threshold. | |||
pub fn values(max_threshold: u8) -> Vec<Threshold> { |
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.
we can do this, but should we? This genarates 9999
elements and then is UniFFI exported. probably not a huge cost but still, it is 10k elements which are uniffi converted, when you could use 2 elements instead by use of a range:
#[derive(uniffi::Record)]
pub struct Range16 {
pub lower: u16,
pub upper: u16
}
And then in Swift Sargon or Kotlin Sargon map the range to Vec<u16>
. And we know we always include Threshold::All
(prepend with).
Futhermore, current impl allows for 10000 elements of Threshold::All
which is weird...
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.
Are you confusing this with the values for the emergency fallback where we have the upper bound of 9999? For the threshold, the array length would be the number of primary threshold factors the user has chosen. Also, we could use IndexSet
instead of Vec
to ensure the values are unique, but we'll still have to convert to Vec when exporting it through uniffi, so I'm not sure if it's worth making this change since we've covered this with a unit test.
crates/core/utils/src/constants.rs
Outdated
pub const DAYS_PER_YEAR: u16 = 365; | ||
|
||
/// Maximum number of units (days, weeks, years) for the security structure recovery confirmation fallback period. | ||
pub const MAX_RECOVERY_CONFIRMATION_FALLBACK_PERIOD_UNITS: u16 = 9999; |
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.
hmm this seems too specific to be on core
crate, ought to into profile-security-structures
crate ?
} | ||
|
||
impl TimePeriodUnit { | ||
pub fn values(&self) -> Vec<u16> { |
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.
@CyonAlexRDX Here we have an array with 9999 u16
elements which crosses the uniffi boundary, do you think the performance cost of this is too high compared to the benefit of having this logic in a single place?
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.
Is it useful though? the main thing you want to expose is actually the upper bound, there is no reason for this to not be contiguous, so rather maybe this should be a range instead of the actual enumerated values.
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.
right, so here I would use a Range instead.
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.
Right, currently it brings value only in terms of display readiness (there's nothing else to do in UI, just render the values) and in terms of the lower and upper bounds, and if we ever were to display non-consecutive values. But it's ok to have this defined in hosts as it's very UI specific.
let primary_override_factors = | ||
self.primary_role.get_override_factors().clone(); | ||
|
||
primary_override_factors.iter().try_for_each(|fsid| { | ||
self.remove_factor_from_primary(fsid, FactorListKind::Override) | ||
}) |
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.
Could you instead expose a function on primaryRole to clear all factors in override? similar to primaryRole.reset() function?
} | ||
|
||
impl TimePeriodUnit { | ||
pub fn values(&self) -> Vec<u16> { |
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.
Is it useful though? the main thing you want to expose is actually the upper bound, there is no reason for this to not be contiguous, so rather maybe this should be a range instead of the actual enumerated values.
Updated the API of
SecurityShieldBuilder
as follows:TimePeriod
andTimePeriodUnit
to represent in the UI the time until recovery auto-confirmationvalidate
function to better accommodate the UI requirements. For example, in the first step in the UI, after selecting enough factor sources to build a good shield and auto-assign them to recovery and confirmation roles, and removing all but one primary threshold factor sources and the authentication signing factor, the UI needs to reflect that an authentication signing factor source has to be added before continuing to the recovery / confirmation step.