Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Error-tolerant parse: recovered commands for unparseable input (deny-only use)

Offen
#190 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
csharp
Bereich
cli

Rechercherichtung

Start by locating ParsedCommand and the existing exact parser projections for Commands, Clauses, IsUnparseable, and Syntax. Review how the parser handles unbalanced quotes, separators, assignments, and wrapper children before designing the recovered projection. Done means adding a clearly non-authoritative RecoveredCommands API that over-reports safely, preserves exact projections, and documents deny-only use.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

enhancement

Problem

When ParsedCommand.IsUnparseable is true, Commands and Clauses are empty. A consumer then has no command words to check. Syntax can contain partial diagnostic evidence, but it has no stable projection that a consumer can use.

A security consumer must still find dangerous commands in input that the parser rejects. For example, a deny list must find rm -rf / in rm -rf / ; echo "unbalanced. Today each consumer must write its own raw-text splitter. Netclaw has one (LegacyShellTextScan, about 300 lines). It splits on whitespace outside quotes, guesses at list separators and wrapper children, and guesses a path style. That code is a second, weaker shell reader, and it drifts from the parser.

Proposal: error-tolerant parse with a separate recovered projection

Add a recovery result for unparseable input, similar to Roslyn error recovery. The parser returns what it could read, marked clearly as not authoritative.

Schematic API (names are open):

public sealed record ParsedCommand
{
    // Unchanged: exact, fail-closed projections. Empty when IsUnparseable.
    public IReadOnlyList<CommandOccurrence> Commands { get; }
    public bool IsUnparseable { get; }

    // New: populated only when IsUnparseable is true.
    public IReadOnlyList<RecoveredCommand> RecoveredCommands { get; }
}

public sealed record RecoveredCommand(
    IReadOnlyList<string> Words,     // quote-removed words, best effort
    SourceRange Range,               // where in Source
    RecoveryReason Reason);          // unbalanced quote, unknown construct, ...

Contract

  • Commands and Clauses keep their current meaning. Recovery never adds to them.
  • RecoveredCommands is for deny-only use: deny lists, protected-path checks, and audit. The XML docs must say that a consumer must not allow, approve, or grant anything from a recovered command.
  • Recovery must over-report, not under-report. If the parser cannot decide whether text is one command or two, it returns both readings.
  • Recovery includes wrapper children when the wrapper text is readable (bash -c "...", sh -c '...', pwsh -Command ...).
  • Recovery uses the same grammar code as the exact parser where it can. A second tokenizer is not the goal.

Examples

Positive (recovered words exist):

  • rm -rf / ; echo "unbalanced recovers rm -rf / and echo unbalanced.
  • X=1 Y=2 netclaw daemon stop (until #189 lands) recovers netclaw daemon stop with the assignments skipped.
  • bash -c "shutdown now; echo 'x recovers shutdown now from the wrapper child.

Negative:

  • Input that parses exactly has an empty RecoveredCommands. The exact projection is the only source of truth.
  • A recovered command never appears in Commands, so ls ; echo "x stays unparseable and does not become an approved ls.

Consumer plan

Netclaw will check recovered commands against its hard-deny list and protected-path hints, and then delete LegacyShellTextScan. Netclaw keeps its policy data (deny lists, path hints). Only the grammar work moves here.

Vorherrschende Sprache
C#
Sterne
15
Forks
0
Ø Merge
9 Std. 54 Min.
Gemergte PRs (30 T.)
40

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus Aaronontheweb/ShellSyntaxTree

Alle Issues in Aaronontheweb/ShellSyntaxTree

Ähnliche Issues

Weitere Issues zu C#

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.