T08 · Insecure Dependencies
- Location
SKILL.md:8- Finding
Unpinned Third-Party Packages Are Installed and Entrusted with Sensitive Credentials
- Content
View full analysis
=0.1.1" ], ``` ### Technical Analysis The project directs the environment to install `nostrcalendar` from an external package registry without an exact version, package hash, or lockfile. Although the project metadata identifies itself as version `0.2.3`, the installation command does not enforce `nostrcalendar==0.2.3`. Consequently, installation may resolve to a different future release. The `nostrkey` dependency uses the open-ended constraint `>=0.1.1`, allowing any subsequent version satisfying that range. The implementation of either dependency is absent from the audited artifact, so its behavior cannot be verified from the supplied source. These packages operate in a sensitive context: the documentation instructs users to provide `NOSTR_NSEC`, a private signing key, and the installed libraries communicate with external Nostr relays. A malicious or compromised permitted release could execute code with the Python process's privileges, read environment variables, forge signed events, and transmit information over the network. This is a supply-chain weakness rather than evidence that the currently published packages are malicious. ### Attack Path 1. An attacker compromises a dependency publisher account, build pipeline, package registry entry, or a future package release permitted by the version constraints. 2. The operator follows the documented setup or the ...[truncated 1405 chars]- Remediation
View remediation
