feat!: enable cross-contract auth

[chadoh]

Fixes: #1030

Soroban allows contract authors to call require_auth() not only on a
G-address (for users), but also on a C-address (for contracts). This
will result in a cross-contract call to the __check_auth function in
the signing contract. This enables all sorts of powerful and novel
use-cases. See https://developers.stellar.org/docs/build/guides/conventions/check-auth-tutorials#customaccountinterface-implementation

Just as if one account submits a transaction (meaning that account signs
the transaction envelope) but the contract calls require_auth on a
different one, the app author will need to use
needsNonInvokerSigningBy and signAuthEntries, so app authors benefit
from these functions when require_auth is called on a contract.

This fixes various assumptions that these functions made to also work
with this sort of cross-contract auth.

• needsNonInvokerSigningBy now returns contract addresses
• sign ignores contracts in the needsNonInvokerSigningBy list, since
  the actual authorization will happen via cross-contract call
• signAuthEntry now takes an address instead of a publicKey, since
  this address may be a user's public key (a G-address) or a contract
  address. Furthermore, it allows setting a custom authorizeEntry, so
  that app and library authors implementing custom cross-contract auth
  can more easily assemble complex transactions.

Additional changes:

• switch to new test cases from AhaLabs/soroban-test-contracts
• switch to stellar instead of soroban
• use latest cli version (this version fixes a problem that some of the
  tests were working around, so they were removed)
• add (untested) workaround for Odd differences between signed and unsigned auth credentials #1070

[Shaptic]

Small comment to simplify the code, then can merge!

[Ifropc]

@chadoh would you mind taking a look at George's comments? I believe we are super close to merging this one.

[chadoh]

Updated with new test cases from https://github.com/AhaLabs/soroban-test-examples, "cloning" it with https://github.com/Rich-Harris/degit. This allows us to have actual contracts that exercise the sign-via-cross-contract-call, which makes it easy/possible to test sign in addition to needsNonInvokerSigningBy, and makes it a real end-to-end test.

[chadoh]

Marked as draft again. Working with @kalepail today to figure out how to make signAuthEntries work for cross-contract auth, too. Tests & code incoming.

[chadoh]

Ok, ready for review! This now introduces a breaking change. I've updated the description with lots of info.

[Ifropc]

LGTM.
Adding a authorizeEntry customization looks a bit premature to me, but I'm by no mean a js sdk exert

[chadoh]

Adding a authorizeEntry customization looks a bit premature to me, but I'm by no mean a js sdk exert

This allows @kalepail to write some really slick code

[Ifropc]

Is it to custom-sign the contract authes?
I feel like we def need to document that...

[Shaptic]

A few minor comments/questions, but otherwise this LGTM and can basically be merged once those are resolved

[Shaptic]

I'll be OOO next week and I don't want to block the merge, so I'll ✔️ but please make sure to consider the submodule approach as well as ensuring this is clearly denoted in the changelog!

[kalepail]

Would love to see this finished, merged and a new release cut this week if possible. Lots of my work is riding on this getting merged.

[socket-security]

New and removed dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
npm/typescript@4.8.4	None	0	68.8 MB	typescript-bot
npm/typescript@4.9.5	None	0	66.8 MB	typescript-bot
npm/typescript@5.0.4	None	0	39.2 MB	typescript-bot
npm/typescript@5.1.6	None	0	40.1 MB	typescript-bot
npm/typescript@5.2.2	None	0	40.6 MB	typescript-bot
npm/typescript@5.3.3	None	0	32 MB	typescript-bot
npm/typescript@5.4.5	None	0	32.4 MB	typescript-bot
npm/typescript@5.5.4	None	0	21.9 MB	typescript-bot
npm/typescript@5.7.0-dev.20240924	None	0	22.5 MB	typescript-bot

🚮 Removed packages: npm/typescript-4.8@4.8.4, npm/typescript-4.9@4.9.5, npm/typescript-5.0@5.0.4, npm/typescript-5.1@5.1.6, npm/typescript-5.2@5.2.2, npm/typescript-5.3@5.3.3, npm/typescript-5.4@5.4.5, npm/typescript-5.5@5.5.4, npm/typescript-5.6@5.6.2, npm/typescript-5.7@5.7.0-dev.20240924

View full report↗︎

[chadoh]

Is it to custom-sign the contract authes?
I feel like we def need to document that...

Good point, @Ifropc. Not sure I understand the actual use-case well enough to explain the possibilities, but I'll fill in what I can, and we can think about where to add more documentation.

signAuthEntries is used in multi-auth workflows to sign all auth entries belonging to a particular address. You need to pass in signAuthEntry, which is a standard part of wallet interfaces; see https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0043.md#wallet-interface-format. @kalepail convinced me that signAuthEntry is poorly named, since what it actually does is sign a preimage of an auth entry. Here's the relevant parts of the authorizeEntry implementation in stellar base:

export async function authorizeEntry(
  entry,
  signer,
  validUntilLedgerSeq,
  networkPassphrase = Networks.FUTURENET
) {
  const preimage = xdr.HashIdPreimage.envelopeTypeSorobanAuthorization(
    new xdr.HashIdPreimageSorobanAuthorization({
      networkId: hash(Buffer.from(networkPassphrase)),
      nonce: addrAuth.nonce(),
      invocation: clone.rootInvocation(),
      signatureExpirationLedger: addrAuth.signatureExpirationLedger()
    })
  );
  const payload = hash(preimage.toXDR());

  let signature;
  let publicKey;
  if (typeof signer === 'function') {
    signature = Buffer.from(await signer(preimage));
    publicKey = Address.fromScAddress(addrAuth.address()).toString();
  } else {
    signature = Buffer.from(signer.sign(payload));
    publicKey = signer.publicKey();
  }

Regardless of the future of SEP-43 and the possibility of renaming signAuthEntry to something like signAuthEntryPreimage, it will never be the right fit for cross-contract auth workflows. For assembling transactions that use cross-contract auth, you need to to completely customize authorizeEntry, rather than relying on the implementation from stellar-base shown above.

I'd love to understand exactly how you used this authorizeEntry override, @kalepail. I searched https://github.com/kalepail/passkey-kit to get a sense of it, but honestly it's so slick that it just sorta looks unimpressive.

Would you be able to fill in some details on how you accomplish your cross-contract auth workflow using this new assembleTransaction option? We could also wait for your Meridian talk in two weeks, if you're going to cover it then 😄

[kalepail]

Is it to custom-sign the contract authes? I feel like we def need to document that...

See this comment here: #1044 (comment)

It's a little bit of a tricky thing to document specifically as it's essentially allowing the developer to decide how they want to handle modifications to the auth entry. In the custom account model this is essential as __check_auth allows the ability to configure a developer defined signature type which will require the ability for the JS SDK to custom craft the signature for the auth entry. Hence the need to override what the current default does which is assume a G-address non-invoker signer.

[kalepail]

@chadoh

I'd love to understand exactly how you used this authorizeEntry override, @kalepail.

The latest and greatest are currently in the next branch.

https://github.com/kalepail/passkey-kit/blob/next/src/kit.ts#L183-L192

Then used here: https://github.com/kalepail/passkey-kit/blob/next/src/kit.ts#L387-L393

[Shaptic]

Just for the record, I wanted to mention something here:

@kalepail convinced me that signAuthEntry is poorly named, since what it actually does is sign a preimage of an auth entry.

Nobody knows what a preimage is (which is a stupid mathy gatekeeping term for "hash function input" or "thing that got hashed"), and they shouldn't need to. The signAuthEntry method gives you a signature to insert into the authorization entry which represents, or otherwise put it returns the correct signature for that auth entry, so it is the defacto way to... sign auth entries, lol.

To your point about building custom auth structures, that would have been slightly easier with the previous helper functions, but I totally agree that we could extend authorizeEntry with a buildAuthStructure parameter or what-have-you that returns the actual ScVal needed for signatureArgs. It's a good idea! But these helpers were never made with custom auth in mind.