-
Notifications
You must be signed in to change notification settings - Fork 44
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
docs: Document safe use of Twox64Concat #601
base: develop
Are you sure you want to change the base?
Changes from 10 commits
d138faf
2cf3adf
dcfc942
5158f25
e15e9c5
16edb75
0cd7ad3
add4848
616f857
ef7c7f4
7e4ffcc
6463c51
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -143,10 +143,19 @@ pub mod pallet { | |
/// Storage of all deposits. Its first key is a namespace, and the second | ||
/// one the deposit key. Its value includes the details associated to a | ||
/// deposit instance. | ||
// SAFETY of Twox64Concat: | ||
// The Namespace is not chosen by the user but by the pallet and therefore | ||
// doesn't allow for arbitrary data. | ||
#[pallet::storage] | ||
#[pallet::getter(fn deposits)] | ||
pub(crate) type Deposits<T> = | ||
StorageDoubleMap<_, Twox64Concat, <T as Config>::Namespace, Twox64Concat, DepositKeyOf<T>, DepositEntryOf<T>>; | ||
pub(crate) type Deposits<T> = StorageDoubleMap< | ||
_, | ||
Twox64Concat, | ||
<T as Config>::Namespace, | ||
Blake2_128Concat, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. note this change. I think the DepositKey might be chosable by the user There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This follows the same reasoning as my other comments (not sure if above or below). The concrete type of a deposit key is defined by the runtime, but it could take user-specified values, so I am all in favor for this change. |
||
DepositKeyOf<T>, | ||
DepositEntryOf<T>, | ||
>; | ||
|
||
#[pallet::pallet] | ||
#[pallet::storage_version(STORAGE_VERSION)] | ||
|
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.
How does this play out with cross-chain origins? I know probably migration would be hard here, but it might still be worth it.
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 DID that creates the endpoint still needs to be a valid accountId. If you would be able to choose an arbitrary accountId you could impersonate other accounts. So I don't think that this will ever be possible.
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.
No, but the resulting account ID is given by our location converter. There might be a way for a chain to craft origins which are then converted into something else on our chain. That would be the same as crafting origins on our chain.
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.
Creating specific AccountIds on our chain should never be possible? Even if the origin is coming from another chain.
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 saying that. But to have an account on our chain you must have a valid private key to generate the signature. On a different chain, "trying" with different accounts might be cheaper, e.g., if, by absurd, you simply create a chain to spam all possible account IDs. This is probably very theoretical, but still possible. All those origins would be converted into some sort of account ID on our chain, but we don't really know what's the "proof of ownership" for that account ID on the source chain. Maybe this is somehow prevented by having XCM fees in place, which is also a mitigation in our case.