Skip to content
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

Merged
merged 17 commits into from
Aug 1, 2023

Conversation

aristidesstaffieri
Copy link
Contributor

@aristidesstaffieri aristidesstaffieri commented Jul 25, 2023

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.

@aristidesstaffieri aristidesstaffieri added the wip not for merging yet label Jul 25, 2023
@aristidesstaffieri aristidesstaffieri self-assigned this Jul 25, 2023
@aristidesstaffieri aristidesstaffieri changed the title [WIP] API signTransaction accepts arbitrary blobs API signTransaction accepts arbitrary blobs Jul 26, 2023
@aristidesstaffieri aristidesstaffieri removed the wip not for merging yet label Jul 26, 2023
@aristidesstaffieri aristidesstaffieri marked this pull request as ready for review July 26, 2023 18:51
// 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(
Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added in f3865d3

Copy link

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

Copy link
Contributor Author

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?

Copy link

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"

Copy link
Contributor Author

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?
Screenshot 2023-07-31 at 2 40 58 PM

Screenshot 2023-07-31 at 2 41 10 PM

Copy link
Contributor Author

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

Copy link
Contributor

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) => {
Copy link
Contributor

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.)

Copy link
Contributor Author

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.

Copy link
Contributor Author

@aristidesstaffieri aristidesstaffieri Jul 28, 2023

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

@aristidesstaffieri
Copy link
Contributor Author

@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.

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) => {
Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor Author

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 👍

Copy link
Contributor Author

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

@aristidesstaffieri aristidesstaffieri changed the base branch from master to release/5.2.6 July 31, 2023 20:49
@piyalbasu piyalbasu merged commit 4f8e48f into release/5.2.6 Aug 1, 2023
1 check passed
@piyalbasu piyalbasu deleted the feature/sign-arbitrary-blobs branch August 1, 2023 22:05
piyalbasu added a commit that referenced this pull request Aug 3, 2023
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants