-
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
Apply Shield Wallet Interaction Part 1 #345
Apply Shield Wallet Interaction Part 1 #345
Conversation
crates/system/os/factors/src/apply_security_shield/wallet_interaction_apply_security_shield.rs
Outdated
Show resolved
Hide resolved
crates/system/os/factors/src/apply_security_shield/wallet_interaction_apply_security_shield.rs
Outdated
Show resolved
Hide resolved
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #345 +/- ##
==========================================
- Coverage 92.85% 92.68% -0.17%
==========================================
Files 1161 1166 +5
Lines 25867 26078 +211
Branches 81 81
==========================================
+ Hits 24019 24171 +152
- Misses 1837 1896 +59
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. |
@@ -176,6 +179,7 @@ impl TransactionManifestModifying for TransactionManifest { | |||
|
|||
pub enum InstructionPosition { | |||
First, | |||
Last, |
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.
Not used actually, so we might remove it
/// We allow to pass amount so that we can top of with more or less based on | ||
/// token balance of `payer` and current balance of the access controller (when | ||
/// we use this method for securified entities.) | ||
fn modify_manifest_add_withdraw_of_xrd_for_access_controller_xrd_vault_top_up_payed_by_account( |
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.
@0xOmarA @GhenadieVP N.B. It is my intention we call this both with manifest which Securified an unsecurified entity and for manifests updating factors for already Securified entity.
/// we use this method for securified entities.) | ||
fn modify_manifest_add_withdraw_of_xrd_for_access_controller_xrd_vault_top_up_payed_by_account( | ||
payer: Account, | ||
// TODO: remove `entity_applying_shield`, this should be read out from the manifest in a throwing function, `manifest.get_address_of_entity_applying_shield()` or similar which Omar need to provide us with, oh well we need the account here, so elsewhere, in SargonOS where we have access to Profile we would call `manifest.get_address_of_entity_applying_shield` and then lookup the entity. |
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.
May be possible based on manifest static analysis, but it should be completely acceptable to receive account as input, after all modify should happen on Wallet action which has the context of the account.
use crate::prelude::*; | ||
|
||
#[derive(Clone, Debug, PartialEq, Eq)] | ||
pub enum TransactionManifestApplySecurityShieldKindSelector { |
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.
not used by this PR, but will be used in the follow up PR
let apply_shield_manifest_kind = self | ||
.apply_shield_manifest_kind | ||
.clone() | ||
.ok_or(CommonError::Unknown)?; // TODO: replace with proper error |
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.
TODO replace in next PR
9f79f13
to
be35bc4
Compare
Jira ABW-4056
Note
Part 1 of N
The first of two (or more) PRs for producing manifests which updates the security config of entities - i.e. applying a security shield (factor instances) to an entity.
This PR specifically only adds support for securifying an unsecurified account.
Other Changes
UnsecurifiedPersona
&&UnsecurifiedAccount
typesRefactored
UnsecurifiedEntity
to be generic over entity =>AbstractUnsecurifiedEntity
with type aliasesAnyUnsecurifiedEntity
,UnsecurifiedAccount
andUnsecurifiedPersona
-- acting just like their "securified cousins" (AbstractSecurifiedEntity
,AnySecurifiedEntity
,SecurifiedAccount
andSecurifiedPersona
)EntitiesOnNetwork
Refactor the five fields of
NextDerivationEntityIndexProfileAnalyzingAssigner
into the typeEntitiesOnNetwork
and letNextDerivationEntityIndexProfileAnalyzingAssigner
imlDefef<Target = EntitiesOnNetwork>
. TheEntitiesOnNetwork
is now also returned fromapply_security_shield_with_id_to_entities
which we make use of when we call that function from the new API:make_interaction_for_applying_security_shield
and immediately get a structured object of which entites are securified and which are not (all having a provisional config).IndexSet
->IdentifiedVecOf
I've changed to use
IdentifiedVecOf<Sec/Unse Entity>
instead ofIndexSet
which is an important change preventing bugs. Why? BecauseIndexSet
would allow for two copies of the same account if one single deeply nested value has changed, e.g. ahidden
flag being present vs non-present - sinceIndexSet
is Hash-based. So the sameAccountAddress
would be present twice. This should never be allowed to happen. And could potentially lead to dangerous bugs. And we automatically protect against this by usingIdentifiedVecOf
!Future Work
Future PR will add the more complex situation where we must produce 6 different kinds of manifest based on: