From 5d71a968d653e72ceab8e053bd0a98ec50f60571 Mon Sep 17 00:00:00 2001 From: Claude Date: Tue, 13 Oct 2026 21:05:56 +0000 Subject: [PATCH 1/5] fix(k9,deed): route --- per the coordination grammar; align IANA drafts The K9 contract's dialect discriminator routed a first line of `---` to k9-coordination with or without the K9! magic. The coordination grammar (v1.1.1, ruling D318) requires the magic and has no `---` production, so every such file was routed to a grammar that could only reject it, and a plain YAML file with a .k9 suffix was waved through as "out of scope" instead of failing K9-E005. A `---` file is now routed only with the magic (to be rejected there) and is unclaimed without it. The validator matches, with self-test assertions for all four magic/no-magic cases. No committed .k9 / .k9.ncl file changes verdict. IANA drafts brought up to date with the specs they register: vnd.k9 (registration .txt and form-ready .adoc, Revision 3): - LF-only line endings; the old "MUST accept CR+LF" contradicted K9-E003 - the K9! line is envelope, not Nickel (envelope-strip rule) - `version` parameter names pedigree.schema_version - links moved from the retired k9-svc/ path to 1-formats/k9/, citing the normative K9-CONTRACT-SPEC - non-existent k9-scan/k9-sign replaced by k9-validate.sh - the .k9 extension and K9! magic shared with coordination.k9 recorded as an OPEN DECISION (subtype vs parameter) that blocks filing vnd.deed (Revision 2): - a leading BOM is INVALID, as the spec and ABNF say (the draft said parsers MUST accept it) - cites spec v0.2.2 / ABNF v1.1.0 at 1-formats/deed/ - restores the :media-type: attribute the draft cites to the current spec Also: SPEC.adoc warns that its freedesktop glob mislabels coordination.k9, and svc/k9/README.adoc drops the withdrawn vnd.k9+nickel and dead k9-svc/ links. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01GqfpQtLuMczxtgG1U9PkLW --- .machine_readable/svc/k9/README.adoc | 14 +-- .../application-vnd.deed-registration.txt | 40 +++++--- 1-formats/deed/spec/DEED-GRAMMAR-SPEC.adoc | 1 + 1-formats/k9/IANA-MEDIA-TYPE-APPLICATION.adoc | 91 ++++++++++++++----- 1-formats/k9/SPEC.adoc | 10 ++ .../iana/application-vnd.k9-registration.txt | 89 ++++++++++++++---- 1-formats/k9/spec/K9-CONTRACT-SPEC.adoc | 16 +++- 1-formats/k9/tools/k9-validate.sh | 37 +++++++- 8 files changed, 231 insertions(+), 67 deletions(-) diff --git a/.machine_readable/svc/k9/README.adoc b/.machine_readable/svc/k9/README.adoc index 923e1d57c..752037003 100644 --- a/.machine_readable/svc/k9/README.adoc +++ b/.machine_readable/svc/k9/README.adoc @@ -130,7 +130,7 @@ K9 contractiles integrate with other RSR standards: ⚠️ **Never run as root unless required** + ⚠️ **Sandbox external components** -**See:** https://github.com/hyperpolymath/standards/blob/main/k9-svc/docs/SECURITY-BEST-PRACTICES.adoc +**See:** https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/docs/SECURITY-BEST-PRACTICES.adoc == Template Files @@ -169,15 +169,15 @@ cargo install just # Clone K9-SVC (for must shim and tooling) git clone https://github.com/hyperpolymath/standards.git -# Note: K9-SVC is located in standards/k9-svc +# Note: K9-SVC is located in standards/1-formats/k9 ---- == Learn More -- **K9-SVC Specification:** https://github.com/hyperpolymath/standards/blob/main/k9-svc/SPEC.adoc -- **K9 User Guide:** https://github.com/hyperpolymath/standards/blob/main/k9-svc/GUIDE.adoc -- **Security Documentation:** https://github.com/hyperpolymath/standards/blob/main/k9-svc/docs/SECURITY-FAQ.adoc -- **IANA Media Type:** `application/vnd.k9+nickel` +- **K9-SVC Specification:** https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/SPEC.adoc +- **K9 User Guide:** https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/GUIDE.adoc +- **Security Documentation:** https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/docs/SECURITY-FAQ.adoc +- **IANA Media Type:** `application/vnd.k9` (application drafted, not yet filed; see https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/IANA-MEDIA-TYPE-APPLICATION.adoc) == Contributing @@ -189,4 +189,4 @@ When adding K9 contractiles to your repository: 4. Sign Hunt-level components before committing 5. Add K9 validation to CI/CD pipeline -**Questions?** Open an issue on https://github.com/hyperpolymath/standards/tree/main/k9-svc +**Questions?** Open an issue on https://github.com/hyperpolymath/standards/tree/main/1-formats/k9 diff --git a/1-formats/deed/docs/iana/application-vnd.deed-registration.txt b/1-formats/deed/docs/iana/application-vnd.deed-registration.txt index efa752981..71b0e59ba 100644 --- a/1-formats/deed/docs/iana/application-vnd.deed-registration.txt +++ b/1-formats/deed/docs/iana/application-vnd.deed-registration.txt @@ -12,7 +12,7 @@ registration uses "application/vnd.deed" as the base type, matching the `:media-type:` attribute declared normatively in DEED-GRAMMAR-SPEC.adoc and following the same reasoning already applied to application/vnd.k9. -Submission Date: NOT YET SUBMITTED (Revision 1, prepared 2026-09-14) +Submission Date: NOT YET SUBMITTED (Revision 2, prepared 2026-10-13) Submitted By: Jonathan D.A. Jewell --- @@ -93,8 +93,9 @@ Interoperability considerations: version. Character encoding is UTF-8 (RFC 3629). A leading Byte Order Mark - (U+FEFF) is permitted but not required; parsers MUST accept and - silently consume it. + (U+FEFF) is INVALID: the grammar begins with the SPDX header line + ";;", and parsers MUST reject a document that starts with a BOM + rather than silently consume it. Head-form dispatch is exact-stem-first. The literal "estate_chora.deed" also matches the general "_chora.deed" @@ -102,10 +103,10 @@ Interoperability considerations: estate-deed, never as repo-deed. Published specification: - Primary specification (v0.1.0, DRAFT): - https://github.com/hyperpolymath/standards/blob/main/deed/spec/DEED-GRAMMAR-SPEC.adoc + Primary specification (v0.2.2, DRAFT): + https://github.com/hyperpolymath/standards/blob/main/1-formats/deed/spec/DEED-GRAMMAR-SPEC.adoc - Formal grammar (ABNF): + Formal grammar (ABNF v1.1.0, normative for parsing): https://github.com/hyperpolymath/standards/blob/main/1-formats/deed/spec/abnf/deed.abnf Applications which use this media type: @@ -117,7 +118,7 @@ Applications which use this media type: with application/vnd.k9 (which enforces) Reference implementation: - https://github.com/hyperpolymath/standards/tree/main/deed + https://github.com/hyperpolymath/standards/tree/main/1-formats/deed Fragment identifier considerations: None defined at this revision. DEED documents are whole-document @@ -184,7 +185,8 @@ Author/Change controller: Provisional registration: Yes Registered provisionally to establish the subtype name while the - grammar specification is at v0.1.0 DRAFT. A full registration will + grammar specification is at v0.2.2 DRAFT (ABNF v1.1.0). A full + registration will be re-filed, superseding this one, once DEED-GRAMMAR-SPEC.adoc is marked Stable. The re-filing is expected to change only the specification reference and the Security considerations (see OPEN @@ -208,14 +210,14 @@ References: [2] RFC 3629 - UTF-8, a transformation format of ISO 10646 https://www.rfc-editor.org/rfc/rfc3629.html -[3] DEED Grammar Specification (v0.1.0, DRAFT) - https://github.com/hyperpolymath/standards/blob/main/deed/spec/DEED-GRAMMAR-SPEC.adoc +[3] DEED Grammar Specification (v0.2.2, DRAFT) + https://github.com/hyperpolymath/standards/blob/main/1-formats/deed/spec/DEED-GRAMMAR-SPEC.adoc -[4] DEED ABNF grammar +[4] DEED ABNF grammar (v1.1.0) https://github.com/hyperpolymath/standards/blob/main/1-formats/deed/spec/abnf/deed.abnf [5] application/vnd.k9 registration (companion enforcement format) - https://github.com/hyperpolymath/standards/blob/main/k9-svc/docs/iana/application-vnd.k9-registration.txt + https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/docs/iana/application-vnd.k9-registration.txt --- @@ -230,6 +232,17 @@ Change Log: rather than binary because DEED has no opaque payload construct. +2026-10-13: Revision 2 -- aligned with DEED-GRAMMAR-SPEC v0.2.2 and + deed.abnf v1.1.0. A leading BOM is now stated as INVALID + (Revision 1 said parsers MUST accept it, contradicting the + spec's lexical rule and the grammar). Specification and + reference-implementation links moved from the retired + deed/ path to 1-formats/deed/, and the vnd.k9 link from + k9-svc/ to 1-formats/k9/. The :media-type: attribute this + file cites had been dropped from the current spec and + survived only in the archived v0.1; it is restored there. + Override mechanism re-checked: still absent. + --- SETTLED BY OWNER RULING, 2026-09-14: @@ -272,7 +285,8 @@ OPEN BEFORE SUBMISSION (owner action, not blocking this file): named + justified + expiring + countable, loosening only) has been designed for this family but appears NOWHERE in DEED-GRAMMAR-SPEC.adoc at v0.1.0 — verified 2026-09-14, 0 - occurrences of "override" in the spec against 28 ABNF rules. It is + occurrences of "override" in the spec against 28 ABNF rules. + Re-verified 2026-10-13 at spec v0.2.2 / ABNF v1.1.0: still 0. It is therefore deliberately absent from the Security considerations above, which describe only what the registered grammar actually admits. If overrides land in the normative grammar, this diff --git a/1-formats/deed/spec/DEED-GRAMMAR-SPEC.adoc b/1-formats/deed/spec/DEED-GRAMMAR-SPEC.adoc index 47342c252..7f6c132c4 100644 --- a/1-formats/deed/spec/DEED-GRAMMAR-SPEC.adoc +++ b/1-formats/deed/spec/DEED-GRAMMAR-SPEC.adoc @@ -1,6 +1,7 @@ = DEED Grammar Specification :version: 0.2.2 :status: DRAFT +:media-type: application/vnd.deed :toc: :toclevels: 3 diff --git a/1-formats/k9/IANA-MEDIA-TYPE-APPLICATION.adoc b/1-formats/k9/IANA-MEDIA-TYPE-APPLICATION.adoc index 924cfd924..fa14ba9db 100644 --- a/1-formats/k9/IANA-MEDIA-TYPE-APPLICATION.adoc +++ b/1-formats/k9/IANA-MEDIA-TYPE-APPLICATION.adoc @@ -2,11 +2,22 @@ ____ Prepared for submission to IANA per RFC 6838 (Vendor Tree) Submission -URL: https://www.iana.org/form/media-types Revision 2 – 2026-04-03 +URL: https://www.iana.org/form/media-types Revision 3 – 2026-10-13 ____ ''''' +[IMPORTANT] +.Not filed: blocked on an open decision +==== +Do not submit this application yet. Its *File extension(s)* field claims +`.k9`, and a second format, the k9-coordination dialect +(`coordination.k9`), uses that extension and the `K9!` magic with a +different body language. Whether that dialect gets its own subtype or a +parameter of this one has not been ruled on. See +<>. +==== + === Important: Change from +nickel suffix Earlier drafts registered `+application/vnd.k9+nickel+`. The `++nickel+` @@ -61,21 +72,31 @@ component requests. Defaults to `+kennel+` if absent. This parameter is advisory; the authoritative security level is declared inside the component’s pedigree metadata. Processors MUST NOT grant privileges beyond the level declared in the pedigree. -* *version*: K9 specification version. Syntax: `+major.minor.patch+` -(e.g., `+1.0.0+`). If absent, processors SHOULD assume the latest -version they support. +* *version*: The `pedigree.schema_version` the component declares. Syntax: +`+major.minor.patch+` (e.g., `+1.0.0+`). Advisory, like `security-level`: +the value inside the pedigree is authoritative. This is *not* the version +of the contract a reader validates against; the specification keeps the +two numbers separate. If absent, processors SHOULD assume the latest +schema major they support. ==== Encoding Considerations *8bit* -K9 files are UTF-8 text using Nickel configuration language syntax. They -begin with the ASCII magic bytes `+K9!+` (0x4B 0x39 0x21) at byte offset -0. No binary payload blocks are defined in the K9 format itself, though -pedigree metadata may reference external binary artefacts by hash. +K9 files are UTF-8 text with no NUL octet. Line 1 is exactly the three +octets `+K9!+` (0x4B 0x39 0x21) followed by LF: no byte-order mark, no +trailing whitespace, no case variants. No binary payload blocks are +defined in the K9 format itself, though pedigree metadata may reference +external binary artefacts by hash. + +Line endings are LF (U+000A) only. A CR+LF file is non-conforming (rule +K9-E003): a CR in the magic line would make it four octets, and byte +sniffers would then disagree with validators. -Line endings are LF (U+000A) by convention; parsers MUST accept CR+LF -(U+000D U+000A) and normalise to LF internally. +After the magic line and an SPDX comment header, the body is a single +Nickel term. The magic line itself is *not* Nickel. A reader that +evaluates the body MUST first replace it with a Nickel comment, keeping +line numbers stable (the envelope-strip rule). ''''' @@ -190,16 +211,34 @@ The format is self-describing: conforming components include a pedigree metadata block declaring the component’s type ("`breed`"), version, security level, and target architectures. -The underlying syntax is Nickel (https://nickel-lang.org), a typed -configuration language. Standard Nickel tooling can parse K9 files, -though K9-aware processors provide additional security enforcement. +The body syntax is Nickel (https://nickel-lang.org), a typed +configuration language, which is normative by reference. K9 defines no +grammar of its own beyond the envelope. Standard Nickel tooling can parse +a K9 body only after the envelope-strip rule has removed the `+K9!+` line; +unstripped, `nickel typecheck` fails at line 1, column 3. + +[[open-decision]] +==== Open decision: coordination.k9 + +A second format, the k9-coordination dialect, also uses the `.k9` +extension and the `+K9!+` magic. Its body is a YAML-like language with its +own ABNF grammar, it never executes anything, and it is versioned +separately. Readers MUST classify a file by its first significant line +before validating it (K9 Component Contract Specification, K9-E005). +Whether that dialect is labelled with its own subtype or with a parameter +of this one has not been ruled on. Until it is, this application MUST NOT +be filed. ''''' === Published Specification -* *K9 SVC Specification (v1.0.0-alpha):* -https://github.com/hyperpolymath/standards/blob/main/k9-svc/SPEC.adoc +* *K9 Component Contract Specification v1.0.0 (normative):* +https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/spec/K9-CONTRACT-SPEC.adoc +* *Machine-readable contract:* +https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/spec/contract/k9_contract.ncl +* *K9 SVC Specification v1.0.0 (format overview, informative):* +https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/SPEC.adoc * *Nickel configuration language:* https://nickel-lang.org/ * *Just command runner:* https://just.systems/ @@ -209,7 +248,7 @@ https://github.com/hyperpolymath/standards/blob/main/k9-svc/SPEC.adoc K9 SVC files are used by: -* K9 component validators and deployers (`+k9-scan+`, `+k9-sign+`) +* The reference validator, `+k9-validate.sh+` (L0 envelope through L3) * CI/CD pipelines with self-validating configuration * Container orchestration systems (Podman-first) * Multi-architecture deployment tools @@ -218,7 +257,7 @@ K9 SVC files are used by: * The Contractile CLI system (must/trust/dust/intend/k9) Reference implementation: -https://github.com/hyperpolymath/standards/tree/main/k9-svc +https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/tools/k9-validate.sh ''''' @@ -259,8 +298,10 @@ signature verification and explicit user consent. |=== |Field |Value |*Deprecated alias names* |None -|*Magic number(s)* |`+K9!+` (0x4B 0x39 0x21) at byte offset 0 -|*File extension(s)* |`+.k9+`, `+.k9.ncl+` +|*Magic number(s)* |`+K9!+` (0x4B 0x39 0x21) at byte offset 0, followed by +LF. Shared with the k9-coordination dialect (see <>). +|*File extension(s)* |`+.k9.ncl+` (components); `+.k9+` (shared with the +k9-coordination dialect, see <>) |*Macintosh file type code(s)* |None |*Object Identifier(s) / OID(s)* |None |*Intended usage* |COMMON @@ -306,8 +347,10 @@ and freedesktop shared-mime-info rules. https://www.rfc-editor.org/rfc/rfc6838.html . RFC 8032 – Edwards-Curve Digital Signature Algorithm (EdDSA) https://www.rfc-editor.org/rfc/rfc8032.html -. K9 SVC Specification (v1.0.0-alpha) -https://github.com/hyperpolymath/standards/blob/main/k9-svc/SPEC.adoc +. K9 Component Contract Specification v1.0.0 +https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/spec/K9-CONTRACT-SPEC.adoc +. K9 SVC Specification v1.0.0 (overview) +https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/SPEC.adoc . Nickel Configuration Language https://nickel-lang.org/ . Just Command Runner https://just.systems/ @@ -320,6 +363,8 @@ https://github.com/hyperpolymath/standards/blob/main/k9-svc/SPEC.adoc * [x] Confirm no naming conflict with existing registrations * [x] Remove unregistered +nickel suffix (RFC 6838 Section 4.2.8) * [x] Unify file extensions under base type +* [x] Align with the K9 Component Contract Specification v1.0.0 (Revision 3) +* [ ] Settle the coordination.k9 open decision (subtype or parameter) * [ ] Submit via IANA web form at https://www.iana.org/form/media-types * [ ] Monitor IANA email for review feedback * [ ] Update specification with assigned media type upon approval @@ -341,5 +386,5 @@ independent media types - Community consensus on suffix semantics ''''' -_Prepared: 2026-01-30_ _Revised: 2026-04-03 (Revision 2)_ _Status: Draft -– ready for submission_ +_Prepared: 2026-01-30_ _Revised: 2026-10-13 (Revision 3)_ _Status: Draft +– blocked on the coordination.k9 open decision_ diff --git a/1-formats/k9/SPEC.adoc b/1-formats/k9/SPEC.adoc index 538a43652..319c034b5 100644 --- a/1-formats/k9/SPEC.adoc +++ b/1-formats/k9/SPEC.adoc @@ -486,6 +486,16 @@ conformance by link:tools/k9-validate.sh[`tools/k9-validate.sh`]. Location: `/usr/share/mime/packages/k9.xml` +[WARNING] +==== +The `*.k9` glob and the `K9!` magic also match `coordination.k9`, which is +a different format (the k9-coordination dialect, with a YAML-like body). This +entry therefore labels coordination files as Nickel components. How the +dialect should be labelled is an open decision that blocks the IANA filing. +See link:IANA-MEDIA-TYPE-APPLICATION.adoc#open-decision[the media type +application]. +==== + === macOS (UTI) [source,xml] diff --git a/1-formats/k9/docs/iana/application-vnd.k9-registration.txt b/1-formats/k9/docs/iana/application-vnd.k9-registration.txt index b9f88b488..16e44ae7b 100644 --- a/1-formats/k9/docs/iana/application-vnd.k9-registration.txt +++ b/1-formats/k9/docs/iana/application-vnd.k9-registration.txt @@ -10,8 +10,13 @@ structured syntax suffix is not registered with IANA. Per RFC 6838 Section 4.2.8, unregistered suffixes SHOULD NOT be used. This registration uses "application/vnd.k9" as the base type. -Submission Date: 2026-04-03 (Revision 2) -Submitted By: Jonathan D.A. Jewell +STATUS: NOT FILED. Do not submit this until the open decision below +(OPEN DECISION: coordination.k9) is settled, because the File +extension(s) field claims ".k9", which a second, differently-bodied +format also uses. + +Prepared: 2026-10-13 (Revision 3) +Prepared By: Jonathan D.A. Jewell --- @@ -32,15 +37,27 @@ Optional parameters: authoritative security level is declared in the pedigree metadata. version - K9 specification version. Syntax: major.minor.patch (e.g., "1.0.0"). + The pedigree.schema_version the component declares. Syntax: + major.minor.patch (e.g., "1.0.0"). Advisory, like security-level: + the value inside the pedigree is authoritative. This is NOT the + version of the contract a reader validates against; the + specification keeps those two numbers separate and forbids + inferring one from the other. Encoding considerations: 8bit - K9 files are UTF-8 text using Nickel configuration language syntax. - They begin with the ASCII magic bytes "K9!" (0x4B 0x39 0x21) at - byte offset 0. Line endings are LF by convention; parsers MUST - accept CR+LF and normalise to LF. + K9 files are UTF-8 text with no NUL octet. Line 1 is exactly the + three octets "K9!" (0x4B 0x39 0x21) followed by LF: no byte-order + mark, no trailing whitespace, no case variants. Line endings are LF + only; a CR+LF file is non-conforming (rule K9-E003), because a CR in + the magic line would make it four octets and byte-sniffers would + then disagree with validators. + + After the magic line and an SPDX comment header, the body is a + single Nickel term. The magic line itself is NOT Nickel: a reader + that evaluates the body MUST first replace it with a Nickel comment, + keeping line numbers stable (the "envelope-strip rule"). Security considerations: K9 implements a tiered Leash System with three security levels: @@ -65,7 +82,11 @@ Security considerations: deployment targets. Implementations SHOULD strip metadata before sharing across trust boundaries. - See K9 security documentation for complete details. + A signature block is a claim, not a verification: a reader MUST NOT + treat a component as verified because a signature is present. A + well-formed component is a well-formed REQUEST for privilege, not an + authorisation. See "Security considerations" in the K9 Component + Contract Specification for the complete list. Interoperability considerations: K9 targets multi-architecture permanence (Linux, Minix, macOS, @@ -78,17 +99,34 @@ Interoperability considerations: Just, and Ed25519 verification. The format is self-describing via pedigree metadata blocks. The - underlying syntax is Nickel (https://nickel-lang.org). + body syntax is Nickel (https://nickel-lang.org), which is normative + by reference; K9 defines no grammar of its own beyond the envelope. + + OPEN DECISION: coordination.k9. A second format, the k9-coordination + dialect, also uses the ".k9" extension and the "K9!" magic, but its + body is a YAML-like language with its own ABNF grammar, it never + executes anything, and it is versioned separately. Readers MUST + classify a file by its first significant line before validating it + (K9 Component Contract Specification, "K9-E005 - the discriminator"). + Whether that dialect is labelled with its own subtype or with a + parameter of this one has not been ruled on. Until it is, this + registration MUST NOT be filed. Published specification: - K9 SVC Specification (v1.0.0-alpha): - https://github.com/hyperpolymath/standards/blob/main/k9-svc/SPEC.adoc + K9 Component Contract Specification v1.0.0 (normative): + https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/spec/K9-CONTRACT-SPEC.adoc + + Machine-readable contract: + https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/spec/contract/k9_contract.ncl + + K9 SVC Specification v1.0.0 (format overview, informative): + https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/SPEC.adoc Nickel: https://nickel-lang.org/ Just: https://just.systems/ Applications which use this media type: - - K9 component validators and deployers (k9-scan, k9-sign) + - The reference validator, k9-validate.sh (L0 envelope through L3) - CI/CD pipelines with self-validating configuration - Container orchestration systems (Podman-first) - Multi-architecture deployment tools @@ -97,7 +135,7 @@ Applications which use this media type: - The Contractile CLI system (must/trust/dust/intend/k9) Reference implementation: - https://github.com/hyperpolymath/standards/tree/main/k9-svc + https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/tools/k9-validate.sh Fragment identifier considerations: Dot-separated paths into the component's data structure. @@ -118,8 +156,11 @@ Restrictions on usage: Additional information: Deprecated alias names for this type: None - Magic number(s): "K9!" (0x4B 0x39 0x21) at byte offset 0 - File extension(s): .k9, .k9.ncl + Magic number(s): "K9!" (0x4B 0x39 0x21) at byte offset 0, followed + by LF. Shared with the k9-coordination dialect; + see OPEN DECISION above. + File extension(s): .k9.ncl (components); .k9 (shared with the + k9-coordination dialect; see OPEN DECISION above) Macintosh file type code(s): None Object Identifier(s) or OID(s): None @@ -149,8 +190,11 @@ References: [2] RFC 8032 - Edwards-Curve Digital Signature Algorithm (EdDSA) https://www.rfc-editor.org/rfc/rfc8032.html -[3] K9 SVC Specification (v1.0.0-alpha) - https://github.com/hyperpolymath/standards/blob/main/k9-svc/SPEC.adoc +[3] K9 Component Contract Specification v1.0.0 + https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/spec/K9-CONTRACT-SPEC.adoc + +[3a] K9 SVC Specification v1.0.0 (overview) + https://github.com/hyperpolymath/standards/blob/main/1-formats/k9/SPEC.adoc [4] Nickel Configuration Language https://nickel-lang.org @@ -168,3 +212,14 @@ Change Log: +nickel suffix per RFC 6838 Section 4.2.8), added RFC 8032, corrected encoding to "8bit", added resource bounding, replay prevention, Podman-first, web form submission +2026-10-13: Revision 3 -- brought into line with the K9 Component + Contract Specification v1.0.0: LF-only line endings (the + old "MUST accept CR+LF" contradicted K9-E003); the magic + line is envelope, not Nickel; "version" names + pedigree.schema_version; published-specification and + reference-implementation links moved from the retired + k9-svc/ path to 1-formats/k9/; the non-existent k9-scan and + k9-sign tools replaced by k9-validate.sh. Recorded the + shared ".k9" extension and "K9!" magic with the + k9-coordination dialect as an OPEN DECISION that blocks + filing. diff --git a/1-formats/k9/spec/K9-CONTRACT-SPEC.adoc b/1-formats/k9/spec/K9-CONTRACT-SPEC.adoc index 6d1ac5637..fe9911e43 100644 --- a/1-formats/k9/spec/K9-CONTRACT-SPEC.adoc +++ b/1-formats/k9/spec/K9-CONTRACT-SPEC.adoc @@ -256,13 +256,25 @@ the envelope: [cols="1,2,2",options="header"] |=== |First significant line |With `K9!` magic |Without -|`---` |`k9-coordination` |`k9-coordination` |`{`, `[`, `(`, `let `, or a string literal |`k9-svc-component` |`k9-svc-library` |an `identifier =` binding |`k9-svc-component` |`k9-svc-library` |a bare `key:` line (no `=`) |`k9-coordination` |*unclaimed* +|`---` |`k9-coordination` (and rejected there) |*unclaimed* |anything else |*unclaimed* |*unclaimed* |=== +Only a file carrying the magic line is ever routed to `k9-coordination`, +because that dialect's grammar requires `K9!` and could never accept a file +without it. Routing such a file would report a plain YAML document that merely +carries a `.k9` suffix as "out of scope" instead of as the K9-E005 defect it is. + +`---` is *not* a coordination construct. It is routed only so that the +coordination grammar can reject it as a malformed coordination file, which is +a more useful report than *unclaimed*. Ruling D318 (coordination grammar +v1.1.1) keeps `---` invalid there. Earlier revisions of this table routed `---` +to `k9-coordination` with or without the magic line, which contradicted the +coordination grammar on both counts. + A Nickel file must ultimately be a *single* term, so a top-level binding sequence is a defect — but it is a Nickel defect, and belongs at L1/L2 rather than to a dialect mismatch. @@ -1125,7 +1137,7 @@ to infer a grammar from prose. * RFC 8017 / RFC 8032 — Ed25519 * link:../SPEC.adoc[K9 SVC Specification] * link:../IANA-MEDIA-TYPE-APPLICATION.adoc[`application/vnd.k9` media type] -* link:../../../2-protocols/k9-coordination/spec/abnf/coordination-k9-grammar_v1.1.abnf[K9 Coordination File Grammar v1.1.0] +* link:../../../2-protocols/k9-coordination/spec/abnf/coordination-k9-grammar_v1.1.abnf[K9 Coordination File Grammar v1.1.1] * standards#1058 (grammar artifacts), ruling D173; standards#837, #856, #752, #49, #64 [appendix] diff --git a/1-formats/k9/tools/k9-validate.sh b/1-formats/k9/tools/k9-validate.sh index c7380ea53..aca2d8f6a 100755 --- a/1-formats/k9/tools/k9-validate.sh +++ b/1-formats/k9/tools/k9-validate.sh @@ -290,10 +290,18 @@ check_l0() { fi # K9-E005 — the dialect discriminator (§4.3). After the magic line and the - # comment header, the first significant line decides the dialect. `---` is - # the coordination dialect's document marker; `{`, `[`, `(`, `let`, a string, - # or a top-level `ident =` binding is a Nickel term; a bare `key:` line with - # no `=` is YAML that belongs to no K9 dialect at all. + # comment header, the first significant line decides the dialect. `{`, `[`, + # `(`, `let`, a string, or a top-level `ident =` binding is a Nickel term. A + # bare `key:` line (no `=`) or a `---` marker is YAML: with the magic line it + # is routed to the coordination dialect, without it it claims nothing. + # + # `---` is NOT a coordination construct. Ruling D318 (coordination grammar + # v1.1.1) keeps it invalid, so a magic-bearing file that opens with one is + # routed to that grammar to be REJECTED there, as a malformed coordination + # file rather than an unclaimed one. Before this fix a `---` file with no + # magic was routed too, though the grammar requires `K9!` and so could never + # accept it: every plain YAML document carrying a `.k9` suffix was waved + # through as "out of scope" instead of failing K9-E005. if [ "$HAS_MAGIC" -eq 1 ]; then body_start="$(sed -n '2,$p' "$f" | grep -vE '^[[:space:]]*#' | grep -vE '^[[:space:]]*$' | head -n 1)" else @@ -301,7 +309,7 @@ check_l0() { fi if printf '%s' "$body_start" | grep -qE '^-{3}'; then - DIALECT="coordination" + if [ "$HAS_MAGIC" -eq 1 ]; then DIALECT="coordination"; else DIALECT="unclaimed"; fi elif printf '%s' "$body_start" | grep -qE '^(\{|\[|\(|let[[:space:]]|")'; then if [ "$HAS_MAGIC" -eq 1 ]; then DIALECT="component"; else DIALECT="library"; fi elif printf '%s' "$body_start" | grep -qE '^[A-Za-z_][A-Za-z0-9_."-]*[[:space:]]*='; then @@ -847,6 +855,25 @@ EOF echo -e "${YEL}SKIP${NC} attribution assertions: $impostor not present" fi + echo "== the dialect discriminator agrees with the coordination grammar (§4.3) ==" + # coordination-k9-grammar_v1.1.abnf requires `K9!` and has no `---` + # production (D318). So no file without the magic may be routed there, and + # one with it is routed only to be rejected by that grammar. + local disc + disc="$(mktemp --suffix=.k9)" + for case in "magic ---:coordination" "magic metadata::coordination" "plain ---:unclaimed" "plain metadata::unclaimed"; do + local shape="${case%:*}" want="${case##*:}" first + first="${shape#* }" + { + [ "${shape%% *}" = magic ] && printf 'K9!\n' + printf '# SPDX-License-Identifier: MPL-2.0\n%s\n' "$first" + printf ' schema: k9-coordination\n' + } > "$disc" + QUIET=1 validate_one "$disc" >/dev/null 2>&1 + t "${shape%% *} file opening '$first' is $want" "$want" "$DIALECT" + done + rm -f "$disc" + echo "== no Nickel reserved word is used as an identifier ==" # D173 gives the body to Nickel's grammar rather than restating it in an # ABNF, which means Nickel's lexer is normative for identifiers and this From e737d70a52ed5e50dfbee3eef7b0d34146ad400b Mon Sep 17 00:00:00 2001 From: "coderabbitai[bot]" <136622811+coderabbitai[bot]@users.noreply.github.com> Date: Tue, 13 Oct 2026 21:20:51 +0000 Subject: [PATCH 2/5] docs(k9): describe validator self-test assertions --- 1-formats/k9/tools/k9-validate.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/1-formats/k9/tools/k9-validate.sh b/1-formats/k9/tools/k9-validate.sh index aca2d8f6a..58c607d97 100755 --- a/1-formats/k9/tools/k9-validate.sh +++ b/1-formats/k9/tools/k9-validate.sh @@ -712,6 +712,8 @@ t() { # t expect_ok() { if "$@"; then t "$* accepted" ok ok; else t "$* accepted" ok no; fi; } expect_bad() { if "$@"; then t "$* rejected" no ok; else t "$* rejected" no no; fi; } +# Run built-in assertions for contract mirrors, extraction, validation, and +# dialect routing; return nonzero if any assertion fails. self_test() { local n tmp facts stripped From 08f250784b9bb45f47450cd9e86d12d867a56956 Mon Sep 17 00:00:00 2001 From: "coderabbitai[bot]" <136622811+coderabbitai[bot]@users.noreply.github.com> Date: Tue, 13 Oct 2026 21:22:08 +0000 Subject: [PATCH 3/5] docs(k9): document check_l0 return values and side effects --- 1-formats/k9/tools/k9-validate.sh | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/1-formats/k9/tools/k9-validate.sh b/1-formats/k9/tools/k9-validate.sh index 58c607d97..20bee7086 100755 --- a/1-formats/k9/tools/k9-validate.sh +++ b/1-formats/k9/tools/k9-validate.sh @@ -253,6 +253,12 @@ is_todo() { case "$1" in *TODO*|*FIXME*|*XXX*) return 0 ;; esac; return 1; } # ════════════════════════════════════════════════════════════════════════ # L0 — ENVELOPE # ════════════════════════════════════════════════════════════════════════ +# Check the file at $1 for envelope and library-role violations, recording +# them in FINDINGS and ERRORS. Set HAS_MAGIC and DIALECT after the NUL check. +# Return 1 if the NUL check fails or the body is unclaimed; return 2 for the +# coordination dialect, whose grammar is not validated here; otherwise +# return 0. A zero status can still carry violations: callers must inspect +# ERRORS to determine whether the file passed. check_l0() { local f="$1" first head5 body_start From 51ff59378bcc5fadf749b2452acddc242016899d Mon Sep 17 00:00:00 2001 From: Claude Date: Tue, 13 Oct 2026 21:31:29 +0000 Subject: [PATCH 4/5] fix(prune-stale): stop wiping actions.lock when no workflow was deleted The deleted-workflow pass reads gone.txt first and told it apart with `NR == FNR`. gone.txt is usually empty, and then NR == FNR holds for every line of the lock, so the whole lock was swallowed and written back empty. The next --verify-local fails with "dependency lockfile version is required". It hit any run with a stale ref and no deleted workflow, which is exactly a Dependabot action bump, so the regen chain could never repair the #1231 drift. Tell the first file apart by FILENAME instead. Adds the missing regression case (stale ref, no deleted workflow): 0 lines left before the fix, whole lock kept and only the stale ref pruned after. On this repo's lock the fixed script prunes exactly the 18 refs #1231 orphaned. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01GqfpQtLuMczxtgG1U9PkLW --- scripts/prune-stale.sh | 5 ++++- scripts/tests/prune-stale-test.sh | 14 ++++++++++++++ 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/scripts/prune-stale.sh b/scripts/prune-stale.sh index 70585106e..772fad1b4 100755 --- a/scripts/prune-stale.sh +++ b/scripts/prune-stale.sh @@ -201,8 +201,11 @@ fi }' "$TMP/new.lock" > "$TMP/new2.lock" # Drop each gone key with its items, again scoped to the workflows: section. +# The gone list is told apart by FILENAME, not by NR == FNR: gone.txt is +# usually EMPTY, and then NR == FNR holds for every line of the lock, which +# swallowed the whole file and wrote the lock back empty. "$AWK" ' - NR == FNR { gone[$0] = 1; next } + FILENAME == ARGV[1] { gone[$0] = 1; next } /^workflows:[[:space:]]*$/ { inwf = 1; skip = 0; print; next } /^[a-z_]+:/ { inwf = 0; skip = 0; print; next } inwf && match($0, /^ '\''([^'\'']+)'\'':/, m) { diff --git a/scripts/tests/prune-stale-test.sh b/scripts/tests/prune-stale-test.sh index e2382b61f..08b554260 100755 --- a/scripts/tests/prune-stale-test.sh +++ b/scripts/tests/prune-stale-test.sh @@ -87,6 +87,20 @@ printf 'workflows:\n '\''.github/workflows/ci.yml'\'':\n - '\''actions ! grep -qF "gone.yml" "$g/actions.lock" && grep -qxF " - 'actions/checkout@$A'" "$g/actions.lock" \ && ok "only a deleted workflow [] key stale: key dropped, live ref kept" || bad "only a deleted workflow [] key stale: key dropped, live ref kept — $(cat "$g/actions.lock")" +# A stale ref with NO deleted workflow is the common case (a Dependabot bump). +# The deleted-workflow pass then reads an empty list first, and an `NR == FNR` +# guard is true for every line of the lock: the whole file was swallowed and +# the lock overwritten empty. The suite above always deletes a workflow, so it +# never reached this. +v="$WORK/v/.github/workflows"; mkdir -p "$v" +printf 'jobs:\n a:\n steps:\n - uses: actions/checkout@%s\n' "$B" > "$v/ci.yml" +printf "version: 'v0.0.2'\nworkflows:\n '.github/workflows/ci.yml':\n - 'actions/checkout@%s'\n - 'actions/checkout@%s'\ndependencies:\n 'actions/checkout@%s':\n commit: 'sha1-%s'\n" "$A" "$B" "$B" "$B" > "$v/actions.lock" +(cd "$WORK/v" && bash "$TARGET") >/dev/null 2>&1 +grep -qxF "version: 'v0.0.2'" "$v/actions.lock" && grep -qxF " - 'actions/checkout@$B'" "$v/actions.lock" \ + && ! grep -qF "checkout@$A" "$v/actions.lock" && grep -qxF " commit: 'sha1-$B'" "$v/actions.lock" \ + && ok "stale ref, no deleted workflow: lock kept whole, only the stale ref pruned" \ + || bad "stale ref, no deleted workflow: lock kept whole, only the stale ref pruned — $(wc -l < "$v/actions.lock") line(s) left" + mkdir -p "$WORK/n/.github/workflows"; (cd "$WORK/n" && bash "$TARGET") >/dev/null 2>&1; st=$? [ "$st" = 1 ] && ok "no lockfile → exit 1" || bad "no lockfile → exit 1 (got $st)" From 7a2d919e2f515d37ec429aef261af05c9e2f6ac8 Mon Sep 17 00:00:00 2001 From: "Jonathan D.A. Jewell" <6759885+hyperpolymath@users.noreply.github.com> Date: Tue, 13 Oct 2026 22:45:33 +0100 Subject: [PATCH 5/5] chore(deps): regenerate actions.lock for the #1231 action bump Regenerated with gh actions-lock and the repair chain (relock-sha-keys, complete-job-refs, close-lock, prune-stale). The asana/push-signed-commits and actions/setup-python@v2 records, used only by the local composite .github/actions/signed-push and invisible to gh actions-lock (#1122), were restored unchanged from the previous lock. --- .github/workflows/actions.lock | 65 ++++++++++++++++++---------------- 1 file changed, 35 insertions(+), 30 deletions(-) diff --git a/.github/workflows/actions.lock b/.github/workflows/actions.lock index 03d1ba482..08354b414 100644 --- a/.github/workflows/actions.lock +++ b/.github/workflows/actions.lock @@ -13,8 +13,8 @@ workflows: '.github/workflows/apply-workflow-pins.yml': - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' - 'actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1' - - 'actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a' - - 'step-security/harden-runner@e14015d583714f6e62063499dc959a02595150a1' + - 'actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9' + - 'step-security/harden-runner@ccd8616d44fd3846e67624a50d5aad6d37bf2d25' '.github/workflows/boj-build.yml': - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' '.github/workflows/canon-spine-lockstep.yml': @@ -49,7 +49,7 @@ workflows: '.github/workflows/dependabot-lock-regen.yml': - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' - 'actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1' - - 'step-security/harden-runner@e14015d583714f6e62063499dc959a02595150a1' + - 'step-security/harden-runner@ccd8616d44fd3846e67624a50d5aad6d37bf2d25' '.github/workflows/doc-format.yml': - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' '.github/workflows/dyadt-verify.yml': @@ -57,7 +57,7 @@ workflows: '.github/workflows/echidna-verify.yml': - 'actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9' - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' - - 'actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a' + - 'actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9' '.github/workflows/elixir-ci-reusable.yml': - 'actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9' - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' @@ -74,7 +74,7 @@ workflows: '.github/workflows/hypatia-scan-reusable.yml': - 'actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9' - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' - - 'actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a' + - 'actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9' - 'erlef/setup-beam@54075bcc5e249e4758d363f27d099f55d843f124' - 'github/codeql-action@b96794f015dfd88f77b49b1c93e0fa7110f94c63' '.github/workflows/hypatia-scan.yml': [] @@ -92,13 +92,13 @@ workflows: - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' '.github/workflows/lockfile-drift-detect.yml': - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' - - 'actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a' - - 'step-security/harden-runner@e14015d583714f6e62063499dc959a02595150a1' + - 'actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9' + - 'step-security/harden-runner@ccd8616d44fd3846e67624a50d5aad6d37bf2d25' '.github/workflows/makefile-blocker.yml': - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' '.github/workflows/mirror-reusable.yml': - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' - - 'dtolnay/rust-toolchain@7e38f4b43b4db5c8dd498af069a4f6196df1d067' + - 'dtolnay/rust-toolchain@e2a55d2ffb04f378e9626c28d38b36d230d1e12f' - 'webfactory/ssh-agent@e83874834305fe9a4a2997156cb26c5de65a8555' '.github/workflows/mirror.yml': - 'hyperpolymath/standards@b935e63937b1f1b5cbaeea7e375947d7b924038f' @@ -117,7 +117,7 @@ workflows: - 'actions/upload-pages-artifact@fc324d3547104276b827a68afc52ff2a11cc49c9' '.github/workflows/propagate-hooks.yml': - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' - - 'step-security/harden-runner@e14015d583714f6e62063499dc959a02595150a1' + - 'step-security/harden-runner@ccd8616d44fd3846e67624a50d5aad6d37bf2d25' '.github/workflows/provisioning-check-reusable.yml': - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' '.github/workflows/readme-derive-reusable.yml': @@ -125,17 +125,17 @@ workflows: '.github/workflows/readme-derive.yml': [] '.github/workflows/rust-ci-reusable.yml': - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' - - 'dtolnay/rust-toolchain@7e38f4b43b4db5c8dd498af069a4f6196df1d067' + - 'dtolnay/rust-toolchain@e2a55d2ffb04f378e9626c28d38b36d230d1e12f' - 'goto-bus-stop/setup-zig@abea47f85e598557f500fa1fd2ab7464fcb39406' - 'swatinem/rust-cache@6323deb102c322ba6fcbdcafc7e3dddab59af2b6' '.github/workflows/scorecard-enforcer.yml': - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' - - 'actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c' - - 'actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a' + - 'actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333' + - 'actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9' - 'ossf/scorecard-action@2d1146689b8cda280b9bc96326124645441f03bc' '.github/workflows/scorecard-reusable.yml': - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' - - 'actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a' + - 'actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9' - 'github/codeql-action@b96794f015dfd88f77b49b1c93e0fa7110f94c63' - 'ossf/scorecard-action@2d1146689b8cda280b9bc96326124645441f03bc' '.github/workflows/secret-scanner-reusable.yml': @@ -144,18 +144,18 @@ workflows: - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' '.github/workflows/settings-drift-detect.yml': - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' - - 'actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a' - - 'step-security/harden-runner@e14015d583714f6e62063499dc959a02595150a1' + - 'actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9' + - 'step-security/harden-runner@ccd8616d44fd3846e67624a50d5aad6d37bf2d25' '.github/workflows/signed-push-smoke.yml': - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' - - 'step-security/harden-runner@e14015d583714f6e62063499dc959a02595150a1' + - 'step-security/harden-runner@ccd8616d44fd3846e67624a50d5aad6d37bf2d25' '.github/workflows/spark-theatre-gate.yml': - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' '.github/workflows/tag-ruleset-canon.yml': - 'actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1' - 'actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1' - - 'actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a' - - 'step-security/harden-runner@e14015d583714f6e62063499dc959a02595150a1' + - 'actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9' + - 'step-security/harden-runner@ccd8616d44fd3846e67624a50d5aad6d37bf2d25' '.github/workflows/tailscale-connect-reusable.yml': - 'tailscale/github-action@d1b6cd204f8dceda5b3eaad7f1f767be390056cd' '.github/workflows/uuid-v7.yml': @@ -177,7 +177,7 @@ dependencies: owner_id: 44036562 repo_id: 513659658 'actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1': - ref: 'v3.2.0' + ref: 'bcd2ba49218906704ab6c1aa796996da409d3eb1' commit: 'sha1-bcd2ba49218906704ab6c1aa796996da409d3eb1' owner_id: 44036562 repo_id: 642580244 @@ -186,9 +186,9 @@ dependencies: commit: 'sha1-368f82528645a54fb793d4d04e342629a3f51346' owner_id: 44036562 repo_id: 438112499 - 'actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c': - ref: 'v8.0.1' - commit: 'sha1-3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c' + 'actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333': + ref: 'v8.0.2' + commit: 'sha1-9000827ccba6bdab643e8b6fd33ac0654aef8333' owner_id: 44036562 repo_id: 192626254 'actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3': @@ -201,16 +201,16 @@ dependencies: commit: 'sha1-e9aba2c848f5ebd159c070c61ea2c4e2b122355e' owner_id: 44036562 repo_id: 192625525 - 'actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a': - ref: '043fb46d1a93c77aae656e7c1c64a875d1fc6a0a' - commit: 'sha1-043fb46d1a93c77aae656e7c1c64a875d1fc6a0a' - owner_id: 44036562 - repo_id: 192625955 'actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f': ref: 'v7.0.0' commit: 'sha1-bbbca2ddaa5d8feaa63e36b76fdaad77386f024f' owner_id: 44036562 repo_id: 192625955 + 'actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9': + ref: 'v7.0.2' + commit: 'sha1-cf430e030ddbb5b0abf93d22962f4752f3646cd9' + owner_id: 44036562 + repo_id: 192625955 'actions/upload-pages-artifact@fc324d3547104276b827a68afc52ff2a11cc49c9': ref: 'fc324d3547104276b827a68afc52ff2a11cc49c9' commit: 'sha1-fc324d3547104276b827a68afc52ff2a11cc49c9' @@ -230,6 +230,11 @@ dependencies: commit: 'sha1-7e38f4b43b4db5c8dd498af069a4f6196df1d067' owner_id: 1940490 repo_id: 260749683 + 'dtolnay/rust-toolchain@e2a55d2ffb04f378e9626c28d38b36d230d1e12f': + ref: 'v1' + commit: 'sha1-e2a55d2ffb04f378e9626c28d38b36d230d1e12f' + owner_id: 1940490 + repo_id: 260749683 'editorconfig-checker/action-editorconfig-checker@51f63319f592f97930c73d9c46184d20bd206393': ref: 'v3.0.0' commit: 'sha1-51f63319f592f97930c73d9c46184d20bd206393' @@ -289,9 +294,9 @@ dependencies: commit: 'sha1-28959ce8df70de7be546dd1250a005dd32156697' owner_id: 18365890 repo_id: 220359305 - 'step-security/harden-runner@e14015d583714f6e62063499dc959a02595150a1': - ref: 'e14015d583714f6e62063499dc959a02595150a1' - commit: 'sha1-e14015d583714f6e62063499dc959a02595150a1' + 'step-security/harden-runner@ccd8616d44fd3846e67624a50d5aad6d37bf2d25': + ref: 'v2.22.1' + commit: 'sha1-ccd8616d44fd3846e67624a50d5aad6d37bf2d25' owner_id: 88700172 repo_id: 422287306 'swatinem/rust-cache@6323deb102c322ba6fcbdcafc7e3dddab59af2b6':