txnbuild: ignore txhash (preauth) and xhash signers in sep-10 #2215
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
### What Ignore txhash (T...) signers, used for preauth transactions, and xhash (X...) signers during SEP-10 verification. ### Why Developers will likely pass through to the verification functions the signers on accounts as provided by Horizon. Accounts can have other non-ed25519 signers and they're likely going to be passed through verbatim. The verification logic's goal is to confirm the transaction has been signed by the signers and so ignoring unsupported types like txhash and xhash seems like a safe thing to do given that the verification function will also ignore ed25519 signers that don't match a signature. Without this in a typical SEP-10 implementation any account with a txhash or xhash signer will likely fail SEP-10 verification. Issues that might be caused by this new behavior is if a user passes in an account seed (S...) or some other string they won't see an error unless it just happens to start with G and does not parse as an address. I think that's unlikely and hopefully a smaller impact than is worth making this solution more complex.
leighmcculloch
requested review from
howardtw
and removed request for
ire-and-curses
ire-and-curses
approved these changes
Feb 3, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Checklist
PR Structure
otherwise).
services/friendbot, orallordocif the changes are broad or impact manypackages.
Thoroughness
I've updated any docs (developer docs,.mdfiles, etc... affected by this change). Take a look in the
docsfolder for a given service,like this one.
Release planning
I've updated the relevant CHANGELOG (here for Horizon) ifneeded with deprecations, added features, breaking changes, and DB schema changes.
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.
What
Ignore txhash (T...) signers, used for preauth transactions, xhash (X...)
signers, and other future types of signers the server might not know
about, during SEP-10 verification.
Why
Developers will likely pass through to the verification functions the
signers on accounts as provided by Horizon. Accounts can have other
non-ed25519 signers and they're likely going to be passed through
verbatim. The verification logic's goal is to confirm the transaction
has been signed by the signers and so ignoring unsupported types like
txhash and xhash seems like a safe thing to do given that the
verification function will also ignore ed25519 signers that don't match
a signature.
Without this in a typical SEP-10 implementation any account with a
txhash or xhash signer will likely fail SEP-10 verification.
Issues that might be caused by this new behavior is if a user passes in
an account seed (S...) or some other string they won't see an error.
I think that's unlikely and hopefully a smaller impact than is worth
making this solution more complex.
This issue was first identified by @overcat in lightsail-network/java-stellar-sdk#264,
but solved in a way that depends on data from Horizon. This solution
does not depend on data from Horizon and should be portable to all our
SDKs. This was previously discussed at:
lightsail-network/java-stellar-sdk#264 (comment).
Known limitations
N/A
CC
@overcat @tamirms @ire-and-curses