T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:108
- Finding
- Production Private Keys Are Directed into Plaintext Environment Files<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 108-111; related guidance at lines 456-461 and 482-484 **Vulnerability Type**: Plaintext storage of sensitive signing credentials **Risk Level**: Medium ### Vulnerable Snippet ```markdown 1. Run `chr keygen --key-id <dapp-name>` to generate a keypair (stored in `~/.chromia/`) 2. Provide the public key — readable via `cat ~/.chromia/<dapp-name>.pubkey` or from CLI output 3. Store the **private key** (`~/.chromia/<dapp-name>`) in `.env` as e.g. `ADMIN_PRIVKEY=<hex>` — it will be needed for signing admin transactions from the client 4. Add `.env` to `.gitignore` ``` Related policy: ```markdown ### Zero-Secret Policy - **NEVER** embed private keys, mnemonics, or secrets in Rell code or `chromia.yml` - Use `moduleArgs` with `"PLACEHOLDER_PUBKEY"` for admin keys in config - Store secrets in `.env` files; load via client-side tooling only - Add `.env` to `.gitignore` in every project ``` ### Technical Analysis The Skill explicitly instructs users to copy a production private key into a plaintext `.env` file within the project environment. Adding the file to `.gitignore` only reduces the likelihood of committing it to Git; it does not encrypt the key or protect it from: - Malicious or compromised dependencies running under the same user account. - Local processes with access to the project directory. - Backup, synchronization, indexing, or diagnostic tools. - Accidental inclusion in archives, build contexts, logs, or support bundles. - Frontend build systems that expose selected environment variables in generated assets. - Excessively permissive filesystem permissions. The key is described as an administrative signing credential. Its confidentiality therefore directly protects privileged blockchain operations. ### Attack Path 1. A developer follows the Skill and copies the production private key into `.env` as `ADMIN_PRIVKEY`. 2. A malicious package, compromised build tool, local process ...[truncated 1134 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Do not direct users to copy production private keys into project-local `.env` files. 2. Retain keys in the Chromia key store where supported and refer to them through `--key-id` rather than exporting raw key material. 3. For automated production signing, use a managed secret service, OS credential store, hardware-backed wallet, HSM, or KMS-backed signing service. 4. Separate administrative signing into a server-side process; never load administrative keys into browser or frontend application code. 5. Apply least privilege by using distinct keys for deployment, asset administration, and routine application operations. 6. If plaintext storage is temporarily unavoidable: - Store it outside the project directory. - Restrict permissions to the owning user. - Exclude it from backups, archives, container build contexts, and frontend bundling. - Add automated secret scanning to CI and pre-commit checks. - Rotate the key immediately after suspected exposure. 7. Update the Skill to explain that `.gitignore` is not a security boundary and does not protect secrets already committed or accessible to local processes. ]]>