-
Notifications
You must be signed in to change notification settings - Fork 25
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
API signTransaction accepts arbitrary blobs #912
Conversation
// try to build a tx xdr, if you cannot then assume the user wants to sign an arbitrary blob | ||
let encodedBlob = "" | ||
try { | ||
const transaction = SDK.TransactionBuilder.fromXDR( |
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.
Yeah, I like your idea of splitting this up into a new API method called signBlob
. I think signing a blob is a different enough, and perhaps more of a super-user feature, that we can just have its own dedicated method for it rather than splitting it here on the try/catch
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.
Added in f3865d3
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.
100% agreed: signing arbitrary data is very dangerous
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.
@Shaptic can you expand your thoughts on this? I'm trying to think through ways to make this safer. I think we can safely decode the b64 blob and display it in the signing window/make the window clearly show that this is not XDR, but can you think of anything else we can do to make this safer for end users?
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 think a warning around "Do not sign random blobs unless you know what you're signing/doing, trust their source, etc." would be really helpful! As in "we have no idea what this blob represents so be aware of that"
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.
@piyalbasu I added these kind of off the cuff, any thoughts or additions for this warning?
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.
It also shows the blob you are signing underneath
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.
Nice - I think this is a great start. We can run this by Bruno to see if he wants to adjust this copy at all
blob: BlobToSign | ||
} | ||
|
||
const SignBlobBody = ({ blob }: SignBlobBodyProps) => { |
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.
what are the differences between this and SignTxBody? It seems like there's some repeated logic here. Is it possible to either combine these into one function or split out the reusable stuff? (for ex: selecting the correct account, checking password, showing warning messages, etc.)
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.
yeah I think so, looking at it more I think we can probably define something like isBlob
because the main difference is you don't show some elements for blobs and change some copy slightly.
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 refactored this in 440302a to move common state/dom up to the parent, there is still some repetition in the markup but it seemed better to me to have this bit of repetition for now vs trying to make one common render with more complicated logic to switch between blob or tx mode, I suspect that the render will only get more complicated as we expand on how we display common blobs. What do you think of this approach? @piyalbasu
e6ae94f
to
cddc615
Compare
@piyalbasu one detail here is that blob must be b64 encoded right now, I can't think of any problems about this right away but wanted to bring it up. |
f3865d3
to
f037bdc
Compare
handleApprove: (signAndClose: () => Promise<void>) => () => Promise<void> | ||
} | ||
|
||
const SignBlobBody = ({ publicKey, allAccounts, isDropdownOpen, handleApprove, isConfirming, accountNotFound, rejectAndClose, currentAccount, setIsDropdownOpen, setIsPasswordRequired, isPasswordRequired, blob, isExperimentalModeEnabled, t, dispatch, hwStatus, isHardwareWallet, setStartedHwSign }: SignBlobBodyProps) => { |
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.
what do you think about moving SignBlobBody and SignTxBody to their own components
files? Might make this file a little easier to digest
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.
Also, if you move these to their own files - you won't need to pass t
and dispatch
, you can just re-instantiate them with useTranslation
and useDispatch
respectively
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.
yup, can do on both 👍
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 split out the body components in their own files, moved t and dispatch into the body components and formatted the files manually, all in 5f96ea1
69a41d3
to
5f96ea1
Compare
5f96ea1
to
440302a
Compare
* API signTransaction accepts arbitrary blobs (#912) * adds signBlob workflows and allows for signTransaction to take a b64 blob * cleans up SignTransaction and splits blob and tx signing review * cleans up SignTransaction and splits blob and tx signing review * Added translations * add domain to blob signing, split blob and tx signing body components * Added translations * refactors SignTransaction to abstract common state to parent * adds new api, signBlob * splits out sign blob and sign tx bodies * restore var name in signTransaction * adds blob warning and blob preview to sign blob flow * Added translations * fixes data blob styling and placement * Added translations * manually format changes * fixes grammar in signing warning * Added translations * Feature/wal 509 remove domain connection (#911) * update slack notify as old version was erroring * add UI to remove connected domains * Added translations * add a separate service for saveAllowList and add an empty state * clean up allowList value that UI receives * fixes bad references to request/response keys in the listener layer * renames args, drops unused args, and splits Request interfaces for tx and blobs * renames forgotten reference in response handler * makes options optional for signBlob * bump freighter-api version for next release (#925) * set current account after accountMap has been generated (#927) * set current account after accountMap has been generated * de-dupe accountsMap logic --------- Co-authored-by: aristides <aristides.staffieri@stellar.org>
This extends signTransaction to be able to do sign arbitrary blobs encoded as b64.
It splits our singing workflows into either tx or blob and splits the review screen as well.
Adds new
signBlob
which is an equivalent to signTransaction, which signs arbitrary base64 data blobs.