T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:81
- Finding
- Nostr Private Key Exposed Through Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:81-92`, `SKILL.md:102-110`, `SKILL.md:116-122`, and `SKILL.md:128-139` **Vulnerability Type**: Private-key exposure through process arguments and command history **Risk Level**: Medium ### Vulnerable Code ```bash # Build and publish task proposal nak event -k 33401 \ --tag d="<unique-slug>" \ --tag p="<your-pubkey>" \ --tag amount="<bounty-in-sats>" \ --tag t="<category>" \ --tag status="proposed" \ --tag funding_type="patron" \ -c '{"title":"Task Title","description":"Detailed description...","requirements":"What must be delivered"}' \ --sec "<nsec>" \ wss://relay.damus.io wss://nos.lol wss://relay.primal.net ``` ```bash # Update to funded (add zap receipt reference) nak event -k 33401 \ --tag d="<same-d-tag>" \ --tag status="funded" \ --tag e="<zap-receipt-event-id>" \ # ... all other original tags ... --sec "<nsec>" \ wss://relay.damus.io ``` ```bash nak event -k 951 \ --tag e="<task-event-id>" \ --tag p="<patron-pubkey>" \ -c '{"delivery":"Description of completed work","evidence":"Link or proof"}' \ --sec "<nsec>" \ wss://relay.damus.io ``` ```bash nak event -k 3402 \ --tag e="<payout-zap-receipt-id>" \ --tag e="<task-event-id>" \ --tag p="<patron-pubkey>" \ --tag p="<arbiter-pubkey>" \ --tag p="<worker-pubkey>" \ --tag resolution="successful" \ --tag a="33401:<patron-pubkey>:<task-d-tag>" \ -c '{"resolution_details":"Work met all requirements"}' \ --sec "<nsec>" \ wss://relay.damus.io ``` ### Technical Analysis Every documented event-publishing workflow directs the user or agent to supply a Nostr secret key through the `--sec` command-line option. After replacing the placeholder with a real `nsec`, the secret becomes part of the process argument vector. Depending on the operating-system configuration and execution environment, command-line arguments can be exposed through: - Process inspection utilities and process metadata. ...[truncated 2177 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. **Remove literal private-key arguments from all examples.** Do not instruct users to place an `nsec` directly in the command line. 2. **Use an external signer where supported.** Prefer a hardware signer, encrypted keystore, NIP-46 remote signer, or another signing mechanism in which the publishing process never receives the raw private key. 3. **Use protected secret input where external signing is unavailable.** If the selected tool supports reading the secret from standard input, a restricted file descriptor, or an interactive no-echo prompt, use that mechanism instead of a command-line option. 4. **Avoid persistent plaintext storage.** Do not place the key in scripts, shell profiles, project files, or unencrypted configuration files. Any required key file should be encrypted at rest and protected with restrictive filesystem permissions. 5. **Prevent accidental logging.** Ensure shell tracing is disabled, sensitive commands are excluded from shell history, and agent, CI, audit, and observability systems redact signing credentials. Environment variables should not be presented as a fully secure alternative because they can also leak through process or diagnostic interfaces. 6. **Require confirmation for consequential signatures.** Display the event kind, relay destinations, content, and tags to the user before signing task-status or conclusion events. 7. **Document incident response.** Advise users who have already executed these examples with a real key to inspect relevant shell history and execution logs. If exposure is suspected, they should stop using the compromised identity and migrate to a newly generated key where operationally possible. ]]>