[Bug] make sast has been red on main since disk_traces.dart landed #521

New issue

Closed

opened 2026-07-22 10:12:21 +00:00 by brenno · 0 comments

brenno commented

2026-07-22 10:12:21 +00:00

Owner

Describe the bug

make sast fails on main, and has done since lib/services/disk_traces.dart
landed. The rule semgrep.ocideck-subproces-buiten-de-gitlaag is Blocking and
fires on:

lib/services/disk_traces.dart:257
final result = await Process.run('chmod', ['700', dir.path]);

Verified against origin/main, not just a feature branch: the line is present
there, and a branch touching three unrelated files reproduces the failure.

Why it went unnoticed

sast is deliberately not wired into make check (it needs an external
binary), and there is no CI runner on this Forgejo instance. So nothing runs it
except a human following CONTRIBUTING/the landing routine — which means a
Blocking rule can sit red indefinitely while every day-to-day gate is green.

What to weigh, rather than just silence

The rule exists because a subprocess talks to the network outside NetGuard.
chmod 700 on a directory the app just created is not that: it starts no
network-capable process and takes no user input in its arguments. Two honest
options, and the choice matters more than the fix:

The rule's subject is really network-capable subprocesses, and chmod
with constant arguments is outside it. Then the rule is too broad and should
narrow — but narrowing a security rule by example is how deny-lists rot.
The rule means what it says — any new subprocess outside lib/services/git/
is a gap — and disk_traces.dart should not shell out at all. Directory
permissions can be set without a subprocess on the platforms we ship.

Option 2 is the safer shape. Either way, an inline suppression with a reason is
better than loosening the pattern, and no suppression at all is better than
both if the call can simply go away.

Regression guard

Whatever the outcome, the fix needs to hold in two directions: make sast
clean on the repo, and still firing on a planted subprocess outside the git
layer. A rule that silently stops matching is worse than no rule.

**Describe the bug** `make sast` fails on `main`, and has done since `lib/services/disk_traces.dart` landed. The rule `semgrep.ocideck-subproces-buiten-de-gitlaag` is Blocking and fires on: ``` lib/services/disk_traces.dart:257 final result = await Process.run('chmod', ['700', dir.path]); ``` Verified against `origin/main`, not just a feature branch: the line is present there, and a branch touching three unrelated files reproduces the failure. **Why it went unnoticed** `sast` is deliberately not wired into `make check` (it needs an external binary), and there is no CI runner on this Forgejo instance. So nothing runs it except a human following `CONTRIBUTING`/the landing routine — which means a Blocking rule can sit red indefinitely while every day-to-day gate is green. **What to weigh, rather than just silence** The rule exists because a subprocess talks to the network outside NetGuard. `chmod 700` on a directory the app just created is not that: it starts no network-capable process and takes no user input in its arguments. Two honest options, and the choice matters more than the fix: 1. The rule's subject is really *network-capable* subprocesses, and `chmod` with constant arguments is outside it. Then the rule is too broad and should narrow — but narrowing a security rule by example is how deny-lists rot. 2. The rule means what it says — any new subprocess outside `lib/services/git/` is a gap — and `disk_traces.dart` should not shell out at all. `Directory` permissions can be set without a subprocess on the platforms we ship. Option 2 is the safer shape. Either way, an inline suppression with a reason is better than loosening the pattern, and no suppression at all is better than both if the call can simply go away. **Regression guard** Whatever the outcome, the fix needs to hold in two directions: `make sast` clean on the repo, and still firing on a planted subprocess outside the git layer. A rule that silently stops matching is worse than no rule.

brenno added the

bug

triage

labels

2026-07-22 10:12:21 +00:00

brenno referenced this issue

2026-07-22 10:12:46 +00:00

fix: stuur kwetsbaarheidsmeldingen naar het adres dat we zelf documenteren #523

brenno referenced this issue

2026-07-22 10:17:17 +00:00

docs: PR-sjabloon wijst naar de bron van waarheid en vraagt naar de afweging #524

brenno referenced this issue