[Audit-Medium] CodeBlock.Indent corrupts embedded newlines inside str…

[pepone]

AI-generated audit finding — this issue was opened from an automated security/correctness audit. It has not been triaged by a human yet; verify the reasoning, reproducibility, and severity before acting on it.

Medium: CodeBlock.Indent corrupts embedded newlines inside string literals and across Windows line endings

Affected code:

• src/ZeroC.CodeBuilder/CodeBlock.cs:55-61 — _content.ToString().Replace("\n", "\n ")

Description:

Indent treats every \n byte in the content buffer as a logical newline boundary and injects four spaces after it. Two problems fall out of this:

1. Raw \n inside a verbatim C# string literal is corrupted. If the content buffer contains @"line1 (raw newline) line2", Indent produces @"line1 (raw newline + 4 spaces) line2". The final source still parses as C#, but the literal's value now includes four extra space characters at the start of line2. For a generator that emits a hand-crafted SQL query or regex inside a verbatim literal, this is a silent correctness bug in the generated code.

   Interpolated strings ($"…") and non-verbatim strings ("line1\nline2") are unaffected because they encode the newline as the two-character escape \n, not a raw byte — but a generator building verbatim literals to avoid double-escaping is the common case.

2. Windows line endings become \r\n . Replace("\n", "\n ") leaves the preceding \r intact, producing \r\n . That renders correctly in most contexts but is inconsistent with the library's own ToString which splits on \n only and discards trailing \r via TrimEnd. A generator whose input comes from string.Join(Environment.NewLine, …) will see its content re-processed differently by Indent and ToString.

Impact:

• Silent corruption of generated code that uses verbatim string literals with embedded newlines.
• Platform-dependent behavior under mixed line endings.

Recommendation:

• Process the content line-by-line (Split('\n') → prepend " " → rejoin) rather than using Replace. That makes line boundaries explicit and the raw-newline-in-literal case becomes at least visible.
• Or document clearly that Indent() must not be called on content containing raw newlines inside string literals; require generators to emit interpolated/escape-form literals in that case.
• Normalize line endings to \n at the entry point (the implicit FromString operator) for consistency.

Severity: Medium.

---

Source report: src-ZeroC.CodeBuilder-audit-2026-04-14.md (finding ``CodeBlock.Indent corrupts embedded newlines inside string literals and across Windows line endings)

Severity (auditor-assigned): Medium

[externl]

Unless I'm missing something I believe the intention is that we only generate \n up until we go to write the file, Then we replace \n by \r\n on Windows.