fix: escape control characters in IfcfgUtil.ValueEscape - #894
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthrough
ChangesValue escaping
Mergeability Score: ⚪ Minimal · up to This change correctly escapes control characters in generated ifcfg values and adds focused coverage. No actionable merge-blocking risk remains beyond normal checks and review. 🚥 Pre-merge checks | ✅ 5 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #894 +/- ##
==========================================
+ Coverage 43.11% 46.01% +2.89%
==========================================
Files 12 13 +1
Lines 3124 3277 +153
==========================================
+ Hits 1347 1508 +161
+ Misses 1777 1769 -8 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
@suraj-cmd where is the documentation for escaping - which characters must be escaped, and how to escape them? |
The ANSI-C quoting branch tested `ord(c) < ord(c)`, which is always
False, so the escaping path was dead and control characters were
written raw into the $'...' string. ifcfg_to_content() emits one
KEY=VALUE per line, so a value containing a newline broke that
structure in the generated file.
The escape also emitted a decimal code point, but ANSI-C quoting
reads \nnn as octal, so the sequence would have decoded to the wrong
character once the branch became reachable. Both are corrected by
comparing against ord(" ") and emitting %03o.
Adds unit tests covering the ANSI-C path, the double-quoting path and
the unquoted path. The two control-character tests fail without the
fix.
Documents the escaping rules in the ValueEscape docstring, citing
Bash Reference Manual 3.1.2.3 and 3.1.2.4.
Signed-off-by: Suraj Patil <surajpatil522@gmail.com>
dce6742 to
8417a35
Compare
|
The rules come from shell quoting, since ifcfg files are shell syntax. I've ANSI-C quoting, $'...' — Bash Reference Manual 3.1.2.4 Double quoting, "..." — Bash Reference Manual 3.1.2.3 Both branches in the existing code already match those sets, so "which On octal vs decimal: So the old str(ord(c)) would have written \10 for a newline and the shell would One thing I'd like your view on: NetworkManager's ifcfg-rh reader (shvar.c) is |
|
@bengal can you answer this question? ^^^
|
Problem
IfcfgUtil.ValueEscape()inlibrary/network_connections.pyguards itsANSI-C quoting branch with
ord(c) < ord(c), which is always False. Theescaping path is therefore unreachable and control characters are copied
verbatim into the
$'...'string.ValueEscape()is called fromifcfg_to_content(), which writes oneKEY=VALUEper line. A value containing a newline breaks that structurein the generated ifcfg file.
There is a second defect behind the first: the escape emits
"\\" + str(ord(c)), a decimal code point, but ANSI-C quoting reads\nnnas octal. Fixing only the comparison would make the branchreachable and produce the wrong character — newline (10) would emit
\10, which bash decodes as octal 10 = backspace.Fix
Compare against
ord(" ")and emit%03o. Uses%formatting to stayPython 2.6-compatible per the constraint on
library/code.Tests
Four unit tests added covering the ANSI-C path, the double-quoting path
and the unquoted path.
Without the fix:
With the fix:
Full suite on macOS:
153 passed, 3 skipped, 1 failed. The singlefailure is
TestSysUtils::test_link_read_permaddress, which needs aLinux
SIOCETHTOOLioctl and fails identically on an unpatchedcheckout — it appears in the "without the fix" run above for that
reason.
black --checkandflake8are clean on both changed files.Verified the octal form round-trips:
printf '%s' $'line1\012line2'produces a real newline.
Signed-off-by: Suraj Patil surajpatil522@gmail.com
Summary by CodeRabbit
Bug Fixes
Tests