Import YAML as Bounded Data with a Pinned Parser

Direct answer

YAML is a serialization language with scalars, sequences, mappings, tags, anchors, and aliases. A YAML document does not simply describe a tree of string keys and string values: tags affect type resolution, mapping keys can be arbitrary nodes, aliases can refer to previously anchored nodes, and the representation graph can contain shared or cyclic references. An application that expects a narrow configuration object must state which part of that language it accepts rather than relying on whichever defaults a parser happens to use. Choose and pin the exact Android parser artifact and version, then record its YAML specification support, schema, loader settings, and output model. A parser may expose a composed node graph, generic collections, or custom typed objects; those are different boundaries. YAML 1.2.2 defines language semantics but does not select the application schema or Java constructors. A configuration importer should ordinarily parse to data-only nodes or primitive collections, then validate an allowlisted application schema before creating domain objects. Custom tags deserve an explicit allowlist. A tag is metadata about node type and meaning; it is not permission for input to name an arbitrary Java class. Some YAML APIs offer constructors that instantiate tagged Java types, while safer APIs construct standard values or require explicit tag handlers. Never use a general object constructor on a user file without verifying its exact behavior and restrictions. If one custom tag is required, bind that specific tag to a narrow constructor that checks node kind and fields; reject unknown tags rather than loading a class by name. Duplicate keys are an interpretation hazard. YAML mappings require unique keys under the specification’s node equality rules, but deciding whether two differently written scalar keys are equal can depend on tag resolution and canonical form. A Java Map may also collapse keys after parsing even if the parser accepted or transformed them. Configure duplicate detection where possible and test the actual parser with repeated plain keys, quoted keys, aliases, and values that resolve to equal typed scalars. For a settings file, a simple string-key-only policy is often easier to validate than arbitrary YAML key nodes. Aliases are references in a graph, not textual macros. Counting aliases alone does not measure the full cost of composing or traversing a graph; repeated references can expand work in downstream code, while self-reference can create a cycle that ordinary recursive validation does not expect. Set parser alias and code-point limits if the selected engine exposes them, and independently bound bytes, nesting, node count, collection size, traversal visits, and elapsed work. Preserve graph identity during validation or reject cycles explicitly; do not expand aliases by repeated string substitution. YAML schema resolution affects everyday scalar values. The same plain spelling may become a string, Boolean, number, or null under a parser’s selected schema and version. YAML 1.1 and 1.2 behavior is not interchangeable, and a library’s default schema may not be the one a producer used. Record the resolved type with the source node, validate the expected scalar kind, and test values such as `on`, `yes`, `001`, `0x10`, `null`, and quoted forms. Do not normalize a scalar before the application knows whether the producer intended text or a typed value. Use a test matrix tied to the exact engine. Include ordinary nested data, unknown global and local tags, a tag that names a class, one allowed narrow custom tag if needed, duplicate keys with alternate spellings, non-string keys, shared aliases, many aliases, cyclic references, deeply nested collections, oversized scalars, multiple YAML documents, invalid UTF-8, and unsupported directives. Compare parser node events or graph metadata before and after construction; assert that rejected input creates no partially applied preference changes. Synthetic input should contain no real tokens, prompts, account identifiers, or private model paths. A safe import pipeline has distinct stages: bytes and encoding, YAML parse/composition, tag and graph policy, application schema validation, semantic checks, user review where consequential, then persistence. A syntactically valid YAML graph can still contain unknown settings, out-of-range values, or fields that must not change permissions or model sources. Validate into a temporary immutable object and apply it atomically only after all checks pass. Keep source bytes unchanged and report errors by document/node location without echoing private values into logs. Do not claim that SnakeYAML Engine is Android compatible merely because its documentation names the JVM or a Java version. Compile and run the exact dependency with the project’s Android toolchain, min/target API range, and package constraints before naming it as an implementation option. Likewise, parser-safe construction does not prove that a resulting configuration is safe to execute. This guide describes a method for YAML ingestion; it does not claim Cove accepts YAML or uses any particular parser.

A shared YAML preset contains an unexpected tag and alias graph

A user selects a YAML preset from a colleague. It includes nested anchors, a repeated mapping key written once as a plain scalar and once quoted, plus a custom tag that resembles a runtime class name. The receiving app only expects a small set of inference preferences.

Decision

Parse with a pinned data-only configuration, detect duplicate keys under the selected schema, reject unknown tags and cycles, then validate allowed string keys and value ranges before an atomic preference update.

Expected outcome

The import either applies a reviewed immutable settings object or reports a location-specific unsupported-input result without invoking arbitrary constructors or partially changing preferences.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Parser/version/schema and constructor behavior
• Duplicate-key, alias-cycle, and unknown-tag fixtures
• Bounded graph validation and atomic preference updates

A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.

Implementation workflow

1. Pin parser, YAML version, and schema. Record exact dependency coordinates, resolved version, YAML directive behavior, schema, encoding policy, and output representation. Confirm compatibility with the actual Android build and APIs rather than assuming a general JVM claim applies.
2. Select a data-only construction policy. Prefer parser nodes or primitive collections plus application-owned validation. Disable arbitrary class construction, allow only explicitly reviewed tag handlers, and reject unknown local/global tags and unsupported document directives.
3. Define key, duplicate, and scalar rules. Restrict application maps to expected string keys where feasible. Test duplicate keys after the chosen schema resolves tags and scalar canonical forms; distinguish quoted text from typed scalars and reject values whose runtime representation is ambiguous.
4. Bound and validate alias graphs. Set the parser alias/code-point limits exposed by the selected version, and add independent byte, node, depth, collection, traversal, and time bounds. Detect or reject cycles and shared references according to an explicit graph policy; do not recursively expand aliases without accounting for visits.
5. Apply only after complete validation. Build an immutable temporary settings object, validate allowed fields and semantic ranges, show consequential changes for user review, and commit atomically. Test malformed and hostile synthetic inputs, parser failures, cancellation, and zero partial preference mutation.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• The exact parser, version, YAML schema, encoding policy, Android compatibility evidence, and constructed representation are recorded.
• Unknown/custom tags cannot name arbitrary classes; any supported custom tag has a narrow node-kind and field validator.
• Duplicate keys and non-string keys have deterministic outcomes under the actual schema, including alternate scalar spellings and aliases.
• Alias count, graph visits, depth, bytes, node/collection sizes, and time are bounded through verified parser controls or application checks; cycles have an explicit outcome.
• The importer validates into temporary state and applies no partial preference changes when parse, schema, or semantic validation fails.

Decision table

Failure patterns to prevent

• Instantiating arbitrary classes from tags
• Assuming YAML mappings only have string keys
• Expanding aliases without graph and work limits

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Android privacy and security
• YAML Language Development Team — YAML 1.2.2 Specification
• SnakeYAML Engine — project README and supported construction model
• SnakeYAML Engine 2.10 — LoadSettingsBuilder API

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions