-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Support PermissionDelegation Amendment XLS-74d XLS-75d #5354
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
base: develop
Are you sure you want to change the base?
Conversation
70a6362
to
5b262d1
Compare
c8bc5f6
to
e8e74f1
Compare
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.
Preliminary partial review. I know you're still working on this, but a few things jumped out at me, and I wanted to bring them to your attention before you go down a problematic path.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #5354 +/- ##
=========================================
+ Coverage 78.1% 78.2% +0.1%
=========================================
Files 795 800 +5
Lines 68598 68969 +371
Branches 8278 8280 +2
=========================================
+ Hits 53593 53961 +368
- Misses 15005 15008 +3
🚀 New features to boost your workflow:
|
e8e74f1
to
b1f0387
Compare
b1f0387
to
4495956
Compare
4495956
to
49ca2b8
Compare
Also, I propose that we shouldn't need to squash commits. Commits makes it easier for the reviewers to keep track of the changes, and they will all be squashed in the end anyways. Also, the audit relies on a particular commit hash, so it's best to keep the commit history as authentic as possible. |
src/libxrpl/protocol/Permissions.cpp
Outdated
if (value == ttSIGNER_LIST_SET || value == ttREGULAR_KEY_SET || | ||
value == ttACCOUNT_SET || value == ttDELEGATE_SET || | ||
value == ttACCOUNT_DELETE) | ||
return true; |
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.
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.
Agreed (though difficult to make it happen without waiting for one of the two PRs to merge first)
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.
I do agree that it should be prohibited but we should wait till batch is merged. Also if ed's comment was implemented it would need to be added in the transactor instead. I like that approach tbh.
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.
@dangell7 ed agrees not to force overridding the checkPermission
function. Since it's checked on the DelegateSet
level and all transactions need to be authorized by the delegating account through DelegateSet transaction before a delegated account can send delegating transactions
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.
I got some suggestion from the security audit that I should use whitelist for the supported transactions, which is safer. I added enum delegatable {enabled, disabled}
and put it in the transactions.macro
. These safety sensitive transactions are delegatable::disabled
. And the system-generated transaction types are disabled as well. For newly added transactions in the future, developers can choose to disable delegation through transactions.macro
I got compile error when building with unity on. Non unity build compiles fine. Could you also please fix a couple of unused variable warning as well? One is in protocol/Permissions.cpp:76. Just add /Users/user/Work/Projects/rippled-acct-prms/src/test/app/SetRegularKey_test.cpp:64:27: error: reference to 'disabled' is ambiguous |
updated |
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.
👍 LGTM
I have a few minor comments for your consideration,
There's a change in the spec, so please refer the new spec:
The PR for spec change: XRPLF/XRPL-Standards#257
Original spec:
XRPLF/XRPL-Standards#217
XRPLF/XRPL-Standards#218
This amendment is called
PermissionDelegation
DelegateSet
transaction is added so that a delegating account can give permission to delegated account to send transaction on his behalf.Ledger object
Delegate
is created, its keylet is hashed from delegating and delegated account.optional common field
Delegate
is added, to indicate that a transaction is a delegating transaction.The following transaction is a delegating transaction,
Delegate
account is the sender of the transaction and will sign this transaction,Account
is the delegating account,Added a
checkPermission
function to check if the delegated account is authorized to send the transaction. And it can be extended in each sub-transactor to check the granular permissions.the delegated account pays the fee
can query
account_objects
of the delegating account to see the permissions he owns.A delegate transaction can be multi-signed by the delegated account's signer list
High Level Overview of Change
Context of Change
Type of Change
.gitignore
, formatting, dropping support for older tooling)API Impact
libxrpl
change (any change that may affectlibxrpl
or dependents oflibxrpl
)