You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,6 +3,12 @@ Release History
3
3
4
4
### Pending
5
5
6
+
#### Fixes
7
+
-`auth.authorize_entry` no longer re-stamps an authorization entry's expiration ledger out from under a signature the entry already carries. A CAP-71-01 (`SOROBAN_CREDENTIALS_ADDRESS_WITH_DELEGATES`) entry has one `signature_expiration_ledger`, shared by the top-level address and every (nested) delegate, and each of their signatures commits to it — so signing one node with a `valid_until_ledger_sequence` different from the one already stored left the earlier signatures in place but no longer verifiable, and nothing was raised until the host rejected the entry. ([#1215](https://github.com/StellarCN/py-stellar-base/issues/1215))
8
+
-`authorize_entry` now resolves the target node(s) before touching the entry and raises `ValueError`, naming the stored expiration ledger, when the requested one would invalidate a signature on any node outside them. Signature values are opaque to the SDK, so every value other than `scvVoid` counts, `scvVoid` being the marker for a node still awaiting one — the convention `build_with_delegates_entry` and `needs_non_invoker_signing_by` already follow. An account contract that accepts `scvVoid` itself as a valid signature is therefore not covered. Re-signing the targeted node(s) with a new expiration is still allowed, and `ADDRESS` / `ADDRESS_V2` entries — which carry a single node — are unaffected.
9
+
-`AssembledTransaction[Async].authorize` / `sign_auth_entries` reach the same guard. They can only sign a delegates entry's top-level node, but the expiration they stamp (`latest_ledger + 100` by default) is the shared one, so signing the top level of an entry whose delegates have already signed now raises instead of invalidating them; pass those delegates' `valid_until_ledger_sequence` explicitly.
10
+
-`build_with_delegates_entry` documents that a signature already present on the wrapped entry is not carried over, which was true but undocumented.
0 commit comments