mock
v1.0.0Manage RPM package builds securely and reproducibly using Mock to create clean chroot environments with configurable presets and plugins.
⭐ 0· 90·0 current·0 all-time
bywei dong@weidongkl
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Benign
medium confidencePurpose & Capability
The name/description match the content: SKILL.md contains Mock installation steps, config locations, example presets, and commands for building, cleaning, and managing chroots. There are no unrelated binaries, environment variables, or credentials requested.
Instruction Scope
Instructions remain within the build domain (mock commands, config paths like /etc/mock, /var/lib/mock, ~/.config/mock.cfg). However, the docs recommend system changes with security impact — adding a user to the mock group, configuring sudoers with NOPASSWD for /usr/bin/mock, using systemd-run, and a sample repo config that sets gpgcheck=0. These are relevant to building but have clear security trade-offs that the skill does not fully warn about.
Install Mechanism
This is an instruction-only skill (no install spec). Nothing is downloaded or written by the skill bundle itself, which reduces supply-chain risk.
Credentials
The skill requests no environment variables or external credentials, which is appropriate. Operational steps do require elevated privileges (usermod, visudo edits, systemd-run), and the examples include signing plugins (which in practice require access to signing keys) and disabling gpg checks in repo config. Those privilege/secrets implications are relevant but not declared or explained in the skill.
Persistence & Privilege
The skill is not always-enabled and is user-invocable; it does not request permanent presence or claim to modify other skills or global agent settings. Autonomous model invocation is allowed (platform default) and not a separate concern here.
Assessment
This skill appears to be what it says: a guide for using Mock to build RPMs. Before following the instructions, consider: do not add NOPASSWD sudo entries unless you understand the risk—prefer adding the user to the mock group and using sudo with explicit, audited commands; avoid disabling GPG checks (gpgcheck=0) unless you control the repository and accept the risk; be careful with the 'sign' plugin because signing requires private keys—ensure keys remain on secure hardware or in a protected agent and are not exposed to build chroots; review any repository URLs and local paths you add; run mock actions in an isolated build host or VM to limit blast radius. If you need a higher-assurance review, provide the full (non-truncated) custom.cfg and any repository URLs or signing workflows the skill will use so those parts can be inspected in detail.Like a lobster shell, security has layers — review code before you run it.
buildvk972xqff44mkh7kn38h2996ghd83eqdkchrootvk972xqff44mkh7kn38h2996ghd83eqdkfedoravk972xqff44mkh7kn38h2996ghd83eqdklatestvk972xqff44mkh7kn38h2996ghd83eqdkmockvk972xqff44mkh7kn38h2996ghd83eqdkrpmvk972xqff44mkh7kn38h2996ghd83eqdk
License
MIT-0
Free to use, modify, and redistribute. No attribution required.