[ixuz]

What and why

The Markdown parser takes time quadratic in two more constructs that the cost guard did not count. The first is an opener that never closes: a backtick run, <!, <? or a link title. The parser reads such an opener to the end of its paragraph, so a paragraph with many of them is slow to read. The second is a text that opens many separate lists. A text within MAX_CHARS could hold enough of either to hold up the main thread each time it was first read: on a card, on a course page or question, and in the Studio's release check. A release can hold many such texts.

The guard in packages/markdown/src/parse.ts now counts both:

• New limit, MAX_LOOKAHEAD (500,000 characters). It caps how far the parser may read ahead for the end of a span or title, added up over the text. Each opener counts only to its closer: a backtick run to the next run of its length, <!-- to -->, <? to ?>, a link's title to its closing quote or paren, or to the next blank line when none comes. Closed spans, as in a long list or table of commands, therefore count about once, and only openers that never close add up to the cap. The count itself takes time linear in the text and stops once past the cap.
• New limit, MAX_LISTS (200). It caps the lists a text opens. A list's next items, and the lines its items hold, open none. An item that starts empty ends at a blank line right after it, because an item can start with at most one blank line. A marker that cannot interrupt a paragraph (an empty item, or an ordered item that does not start at 1) opens no list while a paragraph is open.
• The list count errs high, on purpose. A marker counts wherever it is, in fenced code or an HTML block too, and a lazy line leaves the list. Following micromark's block rules exactly to skip code blocks turned out to be easy to get wrong, so the guard does not try. The cost: a card whose fenced code holds more than about 200 list-like lines (a long diff), or more than 200 list items whose lines wrap without indentation, shows as plain text. No text in the library comes near either.
• Past either limit. A text past either limit is shown as plain text, the same as past the guard's other limits. The pathological tests pin each shape at the cap and past it, and other tests check that a tight list, a table and a long paragraph full of closed code spans still read as Markdown.
• Repository pages. parseDocument lifts MAX_LOOKAHEAD together with MAX_CHARS, because the count grows with a page's length. It refuses a page past MAX_LISTS.

One existing test changed: "a\n- b\n".repeat(MAX_UNDERLINES + 1) now goes past MAX_LISTS first, so the MAX_UNDERLINES test uses "a\n- b\n- c\n" instead.

docs/markdown.md lists both limits and says how they are counted.

Refs: GHSA-25hm-hjrf-w8fh

Checklist

• One issue. This pull request addresses one issue, linked above. (the advisory referenced above)
• One step. This pull request does not finish its issue, so it says Refs:, not Closes:. Leave this unchecked otherwise.
• Done, as AGENTS.md defines it: npm run check passes (lint, Markdown and spelling included), npm run lint:reuse too if a file was added, and npm run crosscheck too if ns/ or decks/ changed. (lint:reuse and crosscheck n/a: no file was added, and ns/ and decks/ are unchanged)
• Tests. New and changed code has its tests, and every package stays at 100% coverage (docs/testing.md).
• Docs. The docs say what changed, and a new page in docs/ is listed in docs/docs.ttl. (no new page)
• Languages. A new or changed message is in every locale: en, sv, ko, de, es and fr (packages/ui/src/i18n/). (n/a: no message added or changed)
• Vocabulary and shapes. Any change to ns/ was agreed in an issue first; no published ns/shapes/*/vN.ttl or decks/*/vN.ttl was edited; generated files were regenerated, not edited. (n/a: ns/, decks/ and generated files are unchanged)
• Breaking? Nothing in the public API breaks, or a commit says so (! and a BREAKING CHANGE: footer). npm run check:breaking sees a line of api/ that goes, but not a feature removed, nor a reader that reads less than before. (check:breaking passes, and every deck in the library still passes library:check)
• Pod data. Any change to what the app writes to a pod comes with its migration (docs/migrations.md). (n/a: nothing written to a pod changes)
• Policy. Any change to an external rule the code follows (SM-2, the plural rules, a specification) is cited. (no external rule changes; the counts follow how CommonMark 0.31.2 closes spans and starts lists)
• Licenses. New content is MIT, or a deck states its own license; a new file has its SPDX header (npm run lint:reuse), or a new deck its line in REUSE.toml; third-party content is credited. (n/a: no file, deck or third-party content added)
• Architecture. Imports follow docs/boundaries.md and the layers of docs/architecture.md.
• Run. I ran the app (npm run dev) and tried the change, and considered the user journeys.
• Authorship. I read and understand every line of this pull request, and answer for it, whatever tools helped write it (CONTRIBUTING.md).
• Commits. Each commit is one logical change, in Conventional Commits form (type(scope): subject, ! and a BREAKING CHANGE: footer if it breaks something), with an imperative subject and a body that explains why (CONTRIBUTING.md).