[ixuz]

What and why

The Turtle parser resolves each base declaration (@base, BASE) against the base before it. It resolves each relative IRI and each prefix declaration against the current base too, and it walks the whole base each time. Some bases, and many prefixes under one base, make the parse take time far beyond linear in the text, on the main thread. A declaration makes no triple, so none of the read limits counted it, and the parser read on to the end of the text even after a limit was passed. So a release small enough to pass every limit could still freeze the tab. This happened when the release was added from a link, on each later read of it or of its catalog for the deck list, and on a Studio import.

This pull request changes four things:

• The parse stops at the first limit. A Turtle text read under limits is now given to the parser in parts, as a JSON-LD text already is. The parser gets no more once the text is past its limits (writeTurtle in readLimits.ts).
• Base and prefix declarations are bounded. Before each part goes to the parser, the declarations that start in it are checked. The text is refused if it has more than 16 bases or more than 4,096 prefixes. It is also refused if a base has a ., .. or empty segment or an escape in its path, or if a base can grow past 512 characters. The refusal is the usual read-limit error: releaseTooLarge for a release, deckFileTooLarge for a deck file. No release the app writes has such a base, and a document needs only a few prefixes.
• The search reads the text as the parser does. It skips strings, IRIs and comments, so a comment cannot hide a declaration, and a declaration quoted in a card's text is not counted. It takes time linear in the text. Where it might read a directive differently from the parser, it refuses.
• Both Solid clients do this. It applies when a document is read, in getSolidDatasetLinear and in parseQuads. The clients' contract tests hold both clients to it, and growth tests check that the time to refuse a text grows linearly. A text read with no limits, from the user's own pod, is parsed as before.

docs/deck-library.md and docs/data-model.md give the new release and deck-file limits. docs/testing.md lists the new growth test.

Refs: GHSA-q3q9-h5mp-3956

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.
• 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 changed; the refusal uses the existing releaseTooLarge and deckFileTooLarge)
• 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 the 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.
• 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, and the user's own pod documents are read without limits as before)
• Policy. Any change to an external rule the code follows (SM-2, the plural rules, a specification) is cited. (n/a: no external rule changes; the search reads Turtle as the parser already does)
• 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).