be05a603be
Fixes the audit findings: HIGH-1 (NWC/WebLN auto-pay of unverified invoices): add assertInvoiceAmount and call it before every programmatic payment in useZaps, useCrewZap, and SpamFeePayment. A malicious LNURL/Lightning-address server can no longer return an inflated invoice and drain the wallet — amount is decoded from bolt11 and must match the intended sats (±1 sat), amountless invoices are rejected. HIGH-2 (forgeable trust signals): - useSasquatchPro: Pro is granted ONLY by a zap receipt AUTHORED by the platform's Lightning provider, embedding a user-signed zap request that tags the platform, with a real paid amount >= smallest tier. The self-signed kind:32671 receipt is now advisory only and never grants access (closed the "self-grant permanent Pro" hole). - useFeaturedVerification: a listing is 'verified' only when the matching 9735 is authored by the provider pubkey (not any self-published receipt). - useCrewGoal: tally only invoice-backed (bolt11) zaps; the forgeable amount tag is no longer summed, so goal progress can't be inflated with fake receipts. Bump to 1.2.14. Co-authored-by: shakespeare.diy <assistant@shakespeare.diy>
52 lines
2.1 KiB
Text
52 lines
2.1 KiB
Text
v1.2.14
|
|
|
|
🔒 Security hardening (payments & trust signals)
|
|
- Auto-pay now verifies every Lightning invoice's amount before paying (zaps,
|
|
crew zaps, listing fee). A server can no longer return an inflated invoice to
|
|
overcharge your wallet.
|
|
- Pro access is granted only by a verifiable, provider-issued zap receipt (plus
|
|
platform owners). Self-signed receipts no longer grant Pro.
|
|
- "Verified payment" badges on featured listings now require a provider-issued
|
|
zap receipt — self-published receipts can't fake verification.
|
|
- Crew funding goals tally only real invoice-backed zaps, so totals can't be
|
|
inflated with fake zap receipts.
|
|
|
|
Plus the delete diagnostics from 1.2.13 to pinpoint the signing/publish step.
|
|
|
|
---
|
|
|
|
v1.2.10
|
|
|
|
🛠️ Fixes a startup crash (black screen) introduced in the previous build and
|
|
keeps the Amber signing fix: signing now opens Amber the same reliable way
|
|
login does, so delete / accept invite / zap complete instead of hanging.
|
|
|
|
After updating, log OUT and log back IN once.
|
|
|
|
---
|
|
|
|
v1.2.8
|
|
|
|
🛠️ Amber finally pops up — signing works (the real fix)
|
|
The big one. On some Android setups (notably GrapheneOS), tapping delete,
|
|
accepting a crew invite, sending a zap, or editing your profile would spin
|
|
forever and Amber never appeared.
|
|
|
|
Root cause: the app's browser layer was silently dropping the request that
|
|
opens Amber, so the approval screen never launched. We added a native hand-off
|
|
so signing requests now open Amber directly — exactly like login already does.
|
|
|
|
Now every signing/encryption action launches Amber, you approve, and the
|
|
action completes. If Amber genuinely doesn't respond you get a clear message
|
|
in seconds instead of an endless spinner.
|
|
|
|
IMPORTANT: after updating, log OUT and log back IN once. Then delete, accept
|
|
invite, zap, and profile edits will just work.
|
|
|
|
🔔 Notification bell "Mark read" actually clears the badge
|
|
Marking notifications read now clears the count for crew items too, while
|
|
your pending invites and requests stay visible in the Crews tab until you
|
|
act on them.
|
|
|
|
🧹 Housekeeping
|
|
Behind-the-scenes reliability fixes across the signing and notification flows.
|