Timestamp

• Outcome: Pass
• Latest audit: Sep 10, 2026 · 7:29 PM UTC
• Version: 1.0.0

Overview

This skill is a coherent OpenTimestamps helper that submits file hashes, creates local proof files, and verifies them, with no evidence of hidden execution or persistence.

Install the OpenTimestamps client in an isolated, preferably pinned environment. Before using auto-memory mode, review the target file list, including `USER.md`. Do not timestamp highly sensitive or easily guessable files unless you accept that their hashes and timing metadata may be sent to third-party timestamp infrastructure.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:104
• Finding: Unpinned Third-Party Dependency Installation## Vulnerability Details **File Location**: `SKILL.md`, line 104 **Vulnerability Type**: Unpinned package installation from a third-party package repository **Risk Level**: Medium ### Vulnerable Code ```bash pip3 install opentimestamps-client ``` ### Technical Analysis The documented installation command retrieves and installs whichever version of `opentimestamps-client` the package index currently resolves as the latest release. It does not specify a reviewed version, validate an artifact hash, enforce a lock file, or explicitly identify a trusted package index. Python packages can execute code during installation and subsequently when their commands or modules are invoked. Consequently, the effective code installed by this instruction can change after the Skill has been reviewed. Exploitation would require compromise of the legitimate package, its publisher account, the configured package repository, or the dependency-resolution path. The audit found no evidence that the package currently contains malicious code; the confirmed weakness is the absence of dependency pinning and integrity verification. ### Attack Path 1. An attacker compromises the package publisher, package repository, or another relevant dependency-distribution component. 2. The attacker publishes a malicious release that resolves under the unversioned package name. 3. A user follows the setup documentation and runs `pip3 install opentimestamps-client`. 4. `pip` downloads and installs the attacker-controlled release without checking a project-supplied expected version or hash. 5. Malicious code executes during installation or when the installed `ots` command is subsequently used. ### Impact Assessment Malicious package code could execute with the privileges of the user running `pip3`. Depending on those privileges and the local Python installation configuration, this could permit access to user-readable files, modification of user-owned data, theft o ...[truncated 396 chars]
• Remediation: ## Remediation Suggestions - Pin `opentimestamps-client` to a specifically reviewed version. - Distribute a dependency lock file containing cryptographic hashes and install with `pip --require-hashes`. - Explicitly specify the approved package index and prevent fallback to untrusted indexes. - Review and pin transitive dependencies as well as the direct dependency. - Prefer an isolated virtual environment rather than installation into a shared or privileged Python environment. - Document a controlled upgrade process that reviews new versions before updating the pin. Example hardened installation pattern: ```bash python3 -m venv .venv .venv/bin/python -m pip install --require-hashes -r requirements.lock ``` The lock file should contain an exact version and approved hashes for every resolved package.

T09 · Insecure Skill Coding Practices

Note

• Location: scripts/ots-stamp.sh:34
• Finding: Timestamp Archive Name Collision Can Overwrite Existing Proofs## Vulnerability Details **File Location**: `scripts/ots-stamp.sh`, lines 34-40 **Vulnerability Type**: Unsafe archive collision handling **Risk Level**: Low ### Vulnerable Code ```bash if [ -f "$ots_file" ]; then archive_dir="$(dirname "$file")/.ots-archive/$(basename "$file")" mkdir -p "$archive_dir" timestamp=$(date -r "$ots_file" +%Y-%m-%d-%H%M%S 2>/dev/null || date +%Y-%m-%d-%H%M%S) mv "$ots_file" "$archive_dir/$timestamp.ots" echo " (archived old proof: $archive_dir/$timestamp.ots)" fi ``` ### Technical Analysis Archived proof names are derived only from the existing proof file's modification time with one-second resolution. The script does not test whether the destination already exists before invoking `mv`. Standard `mv` behavior permits an existing destination file to be replaced. Therefore, two proofs with the same derived timestamp can map to the same archive path, causing a previously archived proof to be silently overwritten. A collision can occur through repeated processing with matching timestamps, copied files that preserve modification times, restoration from backups, or deliberate modification of the proof file's timestamp by an actor who can write within the workspace. This defect undermines the stated objective of maintaining a complete verifiable history. It does not forge a valid OpenTimestamps proof, but it can remove an older proof from the local archive. ### Attack Path 1. A proof already exists at `.ots-archive/<filename>/YYYY-MM-DD-HHMMSS.ots`. 2. Another current `.ots` proof is assigned or retains a modification time that resolves to the same second. 3. The protected source file changes and `ots-stamp.sh` runs again. 4. The script derives the already-used archive destination name. 5. `mv` replaces the existing archived proof without explicit collision detection. 6. The previously stored historical proof is lost unless another backup or version-control c ...[truncated 692 chars]
• Remediation: ## Remediation Suggestions - Refuse to overwrite an existing archive by using `mv -n` and checking its result, or perform an explicit destination-existence check. - Generate collision-resistant archive names using nanosecond precision where supported and append a cryptographic digest or unique counter. - Create the destination atomically to avoid time-of-check/time-of-use races. - Treat archive collisions as errors and retain the current proof until a unique destination is secured. - Keep archived proofs in version control or an independently backed-up, append-only location. Example collision-resistant approach: ```bash proof_hash="$(sha256sum "$ots_file" | awk '{print $1}')" timestamp="$(date -r "$ots_file" +%Y-%m-%d-%H%M%S 2>/dev/null || date +%Y-%m-%d-%H%M%S)" destination="$archive_dir/${timestamp}-${proof_hash}.ots" if [ -e "$destination" ]; then echo "FAIL: archive destination already exists: $destination" >&2 exit 1 fi mv -n -- "$ots_file" "$destination" ``` The implementation should also verify that the move succeeded before reporting that the proof was archived.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (1)

Missing User Warnings

Low

• Confidence: 93% confidence
• Finding: The skill encourages users to submit file-derived SHA-256 hashes to external OpenTimestamps calendar servers and later depend on external network/blockchain verification, but it does not clearly warn about that outbound data flow at the point of use. Even though hashes are less sensitive than raw files, they can still disclose existence, enable correlation/linkability, and create privacy surprises for users who assume the workflow is fully local.

Static analysis

No suspicious patterns detected.