Validate auth entries before signing

[mootz12]

What

The CLI currently relies on the RPC to check that no non-root auths are included in simulation results. This PR adds an explicit, per-entry validation step inside sign_soroban_authorizations that classifies every Address-credential auth entry against the transaction's host function before signing. Entries that don't match the host function exactly require approval. This approval can be bypassed with a --force flag.

Example output:

$ stellar contract invoke --source alice --id CA3WF5KPVE2TXQQSOEQPVD3J6GIZ7G74UA2H7BNQMHBQPOON6XV4PHT4 -- diff_auth_sub_auth --addr bob --val "Test" --subcall CAXDPLG2XWFA3LI3SUDG7AIQ7MF7ZJMFBEQYRGTZIGLT7OLZ243IU3FE
ℹ️  Simulating transaction…
⚠️  Authorization entry does not match the current contract call, and needs approval:
  Auth Entry:
    Signer: GCFEAQ5A5BOO4NYTCDN63TF2UX2DS3T3KLNZDHPDPC3IVGCPR37RSRCC
    Invocation:
      Contract: CA3WF5KPVE2TXQQSOEQPVD3J6GIZ7G74UA2H7BNQMHBQPOON6XV4PHT4
      Fn: diff_auth_sub_auth
      Args:
        "1"
        "2"
      Sub-invocation #0:
        Contract: CAXDPLG2XWFA3LI3SUDG7AIQ7MF7ZJMFBEQYRGTZIGLT7OLZ243IU3FE
        Fn: do_auth
        Args:
          "GCFEAQ5A5BOO4NYTCDN63TF2UX2DS3T3KLNZDHPDPC3IVGCPR37RSRCC"
          Test

⚠️  Sign this authorization entry? (y/N)
y
ℹ️  Signing transaction: ebf3db4651a6cd77ed8a9f2782938eaedd1603e4942a9ceab99b467dd8c04f40
🌎 Sending transaction…
✅ Transaction submitted successfully!
"Test"

If the CLI is invoked in a non-interactive location and the force flag is not preset, it will fail:

$ echo | stellar contract invoke --source alice --id CA3WF5KPVE2TXQQSOEQPVD3J6GIZ7G74UA2H7BNQMHBQPOON6XV4PHT4 -- diff_auth_sub_auth --addr bob --val "Test" --subcall CAXDPLG2XWFA3LI3SUDG7AIQ7MF7ZJMFBEQYRGTZIGLT7OLZ243IU3FE 
ℹ️  Simulating transaction…
⚠️  Authorization entry does not match the current contract call, and needs approval:
  Auth Entry:
    Signer: GCFEAQ5A5BOO4NYTCDN63TF2UX2DS3T3KLNZDHPDPC3IVGCPR37RSRCC
    Invocation:
      Contract: CA3WF5KPVE2TXQQSOEQPVD3J6GIZ7G74UA2H7BNQMHBQPOON6XV4PHT4
      Fn: diff_auth_sub_auth
      Args:
        "1"
        "2"
      Sub-invocation #0:
        Contract: CAXDPLG2XWFA3LI3SUDG7AIQ7MF7ZJMFBEQYRGTZIGLT7OLZ243IU3FE
        Fn: do_auth
        Args:
          "GCFEAQ5A5BOO4NYTCDN63TF2UX2DS3T3KLNZDHPDPC3IVGCPR37RSRCC"
          Test

❌ error: An authorization entry requires confirmation, but stdin is not interactive. Rerun with --force to sign anyway.

Why

The CLI eagerly signs authorization entries returned from the user-specified RPC. If an unsafe auth entry is included, the user might unexpectedly sign for something they did not intend. This check ensures everything the CLI signs automatically is bound to the exact host function invocation in the transaction.

Close https://github.com/stellar/stellar-cli-internal/issues/50

Known limitations

require_auth_for_args for non-source accounts

The check flags contracts that use require_auth_for_args(custom_args) at the root for non-source accounts. The auth tree's root carries custom_args, not the host function's args, so the strict-match check fails even though the auth is genuinely rooted at the operation. A tampered auth entry with the same custom args at root could otherwise be signed and replayed. Source-account auth via SorobanCredentials::SourceAccount is unaffected.

[Copilot]

Pull request overview

This PR hardens soroban-cli transaction signing by explicitly validating each Address-credential Soroban auth entry against the transaction’s host function before signing, rejecting entries that are unsafe to replay or malformed, and improving the error output by rendering the offending auth entry inline.

Changes:

• Added a host-function vs auth-root-invocation classifier and enforced “strict” auth validation in sign_soroban_authorizations.
• Introduced pretty-print formatting for auth entries to improve CLI error messages.
• Added coverage via a new auth fixture contract + integration tests, and added missing RPC network-passphrase verification in extend/restore commands.

Reviewed changes

Copilot reviewed 11 out of 12 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
cmd/soroban-cli/src/tx.rs	Updates comment to reflect new validation behavior prior to signing.
cmd/soroban-cli/src/signer/validation.rs	Adds auth root-invocation classification logic + unit tests.
cmd/soroban-cli/src/signer/mod.rs	Enforces strict validation before signing; adds new errors and source-account credential guard; adds unit tests.
cmd/soroban-cli/src/log/auth.rs	Replaces prior debug helper with structured formatting for auth entries.
cmd/soroban-cli/src/commands/contract/restore.rs	Adds verify_network_passphrase call on RPC client.
cmd/soroban-cli/src/commands/contract/extend.rs	Adds verify_network_passphrase call on RPC client.
cmd/crates/soroban-test/tests/it/integration/util.rs	Adds AUTH fixture constant.
cmd/crates/soroban-test/tests/it/integration/auth.rs	Adds integration coverage for strict vs non-strict/non-root auth scenarios.
cmd/crates/soroban-test/tests/it/integration.rs	Wires in the new auth integration test module.
cmd/crates/soroban-test/tests/fixtures/test-wasms/auth/src/lib.rs	Adds a Soroban test contract to generate various auth-tree shapes.
cmd/crates/soroban-test/tests/fixtures/test-wasms/auth/Cargo.toml	Adds the new test fixture crate manifest.
Cargo.lock	Records the new test_auth fixture crate dependency.

[leighmcculloch]

.

[leighmcculloch]

.

[leighmcculloch]

.

[leighmcculloch]

.

[leighmcculloch]

.

[leighmcculloch]

I haven't finished reviewing this, but it's not obvious to me that this is the appropriate action, it's rather restrictive, especially in the context of the known limitations in the pr description.

I think given the stellar-cli is a developer tool it would be more appropriate to do the following instead of rejecting outright:

• validate the safe case and auto sign in that case (most commands other than invoke should have relatively predictable auth entries required)

• identify the unsafe cases and display those to the user to confirm if they wish to continue

And for a tool that has narrower use, such as a wallet cli rather than a developer focused cli, to provide narrower restrictions like this to protect its use case.

[mootz12]

I think given the stellar-cli is a developer tool it would be more appropriate to do the following instead of rejecting outright:

• validate the safe case and auto sign in that case (most commands other than invoke should have relatively predictable auth entries required)
• identify the unsafe cases and display those to the user to confirm if they wish to continue

Thanks for the feedback @leighmcculloch !

This PR is basically step 1, identify "safe" auth. In my mind, I defined this as any auth entry that is tied to the root invocation exactly. Since the idea of this is not to limit user actions, we can assume the user input the contract invocation as intended. Thus, even if the auth could be detached, the only way its valid is if the exact contract invocation the user intended was the root invocation.

To add, I'd be shocked if this was actually restrictive. The only use case it blocks is non-source accounts signing require_auth_for_args, when the only way to provide additional signers is via arguments as it stands.

---

Note - updated to add a bypass flag and approval mechanism.

Created a follow up issue to support non-root auth: #2574