fix(link): validate pkg_config names before invoking pkg-config#5073
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis pull request adds input validation for pkg-config package names sourced from user configuration before passing them to the pkg-config command. A new validator function rejects empty strings, leading-dash prefixes, and characters outside a conservative allowlist, and validation is integrated at two points in the linking flow. Changespkg-config package name validation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
What
Adds
crates/perry/src/commands/compile/link/pkg_config.rswith a conservative allowlist validator, and calls it before bothpkg-configinvocation sites inlink/mod.rs.Why
pkg_configentries from the user'spackage.json(perry.nativeLibrary…) were passed straight toCommand::new("pkg-config").args(["--libs", pkg])with no validation. No shell is spawned, so this is argument-confusion (e.g. a leading-parsed as apkg-configflag) rather than shell injection, and the input is the user's own config — so severity is low. Validating against^[A-Za-z0-9._/@+-]+$(rejecting empty / leading-) removes the argument-injection surface and turns a confusing link failure into an actionable error naming the offending entry. All legitimate package names that work today keep working.Test
4 new unit tests (accepts real names like
openssl/gtk+-3.0; rejects empty, leading-dash flags, whitespace/metacharacters).cargo test -p perry pkg_config→ 4 passed.Closes #5068
Summary by CodeRabbit