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: protoc diagnostic parsing can throw inside the MSBuild task instead of reporting a normal compiler error — CONFIRMED
Affected code:
Verification:
Confirmed. The parser assumes that any stderr line with ≥ 3 colons is a file:line:column: message diagnostic. On Windows, a typical absolute path already has one colon (C:\…), so a perfectly normal C:\work\greeter.proto:9:1: syntax error line has 4 colons. Split([':'], 4) then produces:
parts[0] = "C"
parts[1] = "\\work\\greeter.proto"
parts[2] = "9"
parts[3] = "1: syntax error"
int.Parse(parts[1], CultureInfo.InvariantCulture) at line 156 throws FormatException, which the ToolTask surface then rethrows — the schema error becomes a task crash, losing the original diagnostic text.
Even on Unix, any message that happens to contain a colon in its body can mislead the column parse (e.g. an error mentioning "expected ;: got }"). Less common but equally brittle.
Impact:
- Ordinary schema errors surface as task crashes on Windows instead of readable MSBuild diagnostics.
- Build failures become harder to diagnose and can bypass normal error reporting pipelines (IDE squiggles, etc.).
Recommendation:
- Use a regex anchored on
<source>:<line>:<column>: where <line> and <column> are \d+, and fall back to the literal-log path on no match.
- Even in the structured branch, wrap the
int.Parse calls in TryParse and fall back to Log.LogError(singleLine) on failure.
- Add regression tests with Windows drive-letter paths and messages whose body contains a colon.
Status: Valid, Medium severity.
Source report: src-IceRpc.Protobuf.Tools-audit-2026-04-14.md (finding ``protoc diagnostic parsing can throw inside the MSBuild task instead of reporting a normal compiler error — **CONFIRMED**)
Severity (auditor-assigned): Medium
Medium:
protocdiagnostic parsing can throw inside the MSBuild task instead of reporting a normal compiler error — CONFIRMEDAffected code:
LogEventsFromTextOutputint colonCount = singleLine.Count(c => c == ':');Split([':'], 4)+int.Parse(parts[1])+int.Parse(parts[2])Verification:
Confirmed. The parser assumes that any stderr line with ≥ 3 colons is a
file:line:column: messagediagnostic. On Windows, a typical absolute path already has one colon (C:\…), so a perfectly normalC:\work\greeter.proto:9:1: syntax errorline has 4 colons.Split([':'], 4)then produces:parts[0] = "C"parts[1] = "\\work\\greeter.proto"parts[2] = "9"parts[3] = "1: syntax error"int.Parse(parts[1], CultureInfo.InvariantCulture)at line 156 throwsFormatException, which theToolTasksurface then rethrows — the schema error becomes a task crash, losing the original diagnostic text.Even on Unix, any message that happens to contain a colon in its body can mislead the column parse (e.g. an error mentioning "expected
;: got}"). Less common but equally brittle.Impact:
Recommendation:
<source>:<line>:<column>:where<line>and<column>are\d+, and fall back to the literal-log path on no match.int.Parsecalls inTryParseand fall back toLog.LogError(singleLine)on failure.Status: Valid, Medium severity.
Source report: src-IceRpc.Protobuf.Tools-audit-2026-04-14.md (finding ``protoc
diagnostic parsing can throw inside the MSBuild task instead of reporting a normal compiler error — **CONFIRMED**)Severity (auditor-assigned): Medium