boost-skill-cli 1.2.76__tar.gz → 1.2.77__tar.gz

{boost_skill_cli-1.2.76/boost_skill_cli.egg-info → boost_skill_cli-1.2.77}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.76
+Version: 1.2.77
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0

{boost_skill_cli-1.2.76 → boost_skill_cli-1.2.77}/boost_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '1.2.76'
-__version_tuple__ = version_tuple = (1, 2, 76)
+__version__ = version = '1.2.77'
+__version_tuple__ = version_tuple = (1, 2, 77)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.76 → boost_skill_cli-1.2.77}/boost_cli/core/provenance.py

@@ -158,6 +158,18 @@ def verify_dir(clone: Path) -> Result:
             return Result(VERIFIED, key_name=name,
                           fingerprint=minisign.key_id_hex(pk.key_id),
                           trusted_comment=sig.trusted_comment)
+    # A signature carrying a *trusted* key's id that still fails to verify is
+    # not a merely-unknown signer — it is the tampering this module exists to
+    # catch (the manifest was edited after a trusted key signed it). Report it
+    # as INVALID, not UNTRUSTED, so callers that only alarm on INVALID (the
+    # `trust verify` sweep) don't wave a modified manifest through.
+    for name, pk in _public_keys():
+        if sig.key_id == pk.key_id:
+            return Result(INVALID, key_name=name,
+                          fingerprint=minisign.key_id_hex(pk.key_id),
+                          trusted_comment=sig.trusted_comment,
+                          detail="signature by trusted key %s does not verify"
+                                 " — manifest modified?" % name)
     return Result(UNTRUSTED, fingerprint=minisign.key_id_hex(sig.key_id),
                   trusted_comment=sig.trusted_comment,
                   detail="no trusted key verifies this signature")

{boost_skill_cli-1.2.76 → boost_skill_cli-1.2.77/boost_skill_cli.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.76
+Version: 1.2.77
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0

{boost_skill_cli-1.2.76 → boost_skill_cli-1.2.77}/docs/roadmap/items/audit-trust-verify-labels-a-manifest-tampered-after-signing-by-a-t.md

@@ -2,15 +2,15 @@
 id: audit-trust-verify-labels-a-manifest-tampered-after-signing-by-a-t
 board: code
 section: trust
-status: planned
+status: inflight
 category: Safety · Bug
 complexity: S
 impact: High
 wow: 2
 note: the tampering case the feature exists for reads as "key unknown", and the sweep exits 0
 order: 221
-owner:
-pr:
+owner: loop/trust-verify-tamper
+pr: 675
 title: "<code>trust verify</code> labels a manifest tampered after signing by a TRUSTED key 'untrusted'; sweep exits 0"
 ---
 Sign a tap's manifest with a trusted key, then edit the manifest &mdash; the exact tampering <code>trust verify</code> exists to catch. The sweep reports <code>iktakahiro/python-fastapi-ddd-sk&hellip;&nbsp; untrusted&nbsp; no trusted key verifies this sig&hellip;</code> and <b>exits 0</b>; <code>--json</code> says <code>{"status": "untrusted", "key_name": null, "fingerprint": "1122334455667788"}</code> &mdash; and that fingerprint is the trusted <code>acme</code> key's own. So a modified manifest is indistinguishable from a merely unknown signer, and a scripted sweep sails past it. One narrowing from verification: the named-tap path (<code>trust verify TAP</code>) does exit 1; the exit-0 hole is the sweep, whose alarm at <code>boost_cli/commands/quality.py:1329</code> fires only on INVALID. The 'untrusted / key unknown' mislabel affects both paths.

{boost_skill_cli-1.2.76 → boost_skill_cli-1.2.77}/docs/roadmap.html

@@ -16787,7 +16787,7 @@ end to end through <code>boost install</code> for a tapped rule and a tapped wor
       </article>
 
       <article class="cap rcard" id="audit-trust-verify-labels-a-manifest-tampered-after-signing-by-a-t">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Safety · Bug</span></div>
+        <div class="head"><span class="pill inflight">In flight</span><span class="cat">Safety · Bug</span></div>
         <h3><code>trust verify</code> labels a manifest tampered after signing by a TRUSTED key 'untrusted'; sweep exits 0</h3>
         <p>Sign a tap's manifest with a trusted key, then edit the manifest &mdash; the exact tampering <code>trust verify</code> exists to catch. The sweep reports <code>iktakahiro/python-fastapi-ddd-sk&hellip;&nbsp; untrusted&nbsp; no trusted key verifies this sig&hellip;</code> and <b>exits 0</b>; <code>--json</code> says <code>{"status": "untrusted", "key_name": null, "fingerprint": "1122334455667788"}</code> &mdash; and that fingerprint is the trusted <code>acme</code> key's own. So a modified manifest is indistinguishable from a merely unknown signer, and a scripted sweep sails past it. One narrowing from verification: the named-tap path (<code>trust verify TAP</code>) does exit 1; the exit-0 hole is the sweep, whose alarm at <code>boost_cli/commands/quality.py:1329</code> fires only on INVALID. The 'untrusted / key unknown' mislabel affects both paths.
 

{boost_skill_cli-1.2.76 → boost_skill_cli-1.2.77}/docs/security-design.md

@@ -103,6 +103,12 @@ posture is reachable without a surprise breakage first.
 minisign signatures over tap content against a trusted Ed25519 public key. Both
 are **verify-only** — boost holds no private key material and cannot sign.
 Correctness is pinned by the RFC 8032 §7.1 test vectors in the unit suite.
+`core/provenance.verify_dir` distinguishes a signature no trusted key accepts
+(`untrusted` — an unrecognised signer) from one whose key id names a *trusted*
+key but that no longer verifies (`invalid` — the tampering this feature exists
+to catch: a manifest edited after a trusted key signed it). `boost trust
+verify`'s sweep alarms — and exits non-zero — on `invalid`, so it must never be
+reported as the merely-unrecognised `untrusted` case.
 
 **Tamper evidence.** Every installed item records a sha256 of its content and
 the commit it came from in the v3 lock file. `core/integrity.py` promotes that

{boost_skill_cli-1.2.76 → boost_skill_cli-1.2.77}/tests/functional/test_tap_signing.py

@@ -108,6 +108,41 @@ def test_unsigned_tap_shows_unsigned(boost, tapped):
     assert "unsigned" in boost("trust", "verify").out
 
 
+def test_tampered_manifest_from_trusted_key_reports_invalid_not_untrusted(
+        boost, fixture_tap_src, tmp_path, signer):
+    """Editing a manifest after a TRUSTED key signed it must not read as an
+    unknown signer.
+
+    A signature whose key id belongs to a trusted key but that no longer
+    verifies is exactly the tampering `trust verify` exists to catch — it must
+    not be indistinguishable from a merely-unrecognised signer.
+    """
+    from boost_cli.core import provenance, registry
+
+    tap = _signed_tap(fixture_tap_src, tmp_path, signer, name="tampered")
+    boost("tap", tap)
+    boost("trust", "add", "acme", signer.public_key_text())
+
+    # Tamper with the CLONE's manifest post-signing, without re-signing — the
+    # signature on disk now belongs to a trusted key id but fails to verify.
+    clone = registry.get("tampered").path
+    manifest = clone / provenance.SIGNED_FILE
+    manifest.write_bytes(manifest.read_bytes() + b"tampered\n")
+
+    r = boost("trust", "verify", "tampered", expect=1)
+    assert "invalid" in r.out
+    assert "untrusted" not in r.out
+
+    data = json.loads(boost("trust", "verify", "tampered", "--json", expect=1).out)
+    assert data[0]["status"] == "invalid"
+    assert data[0]["key_name"] == "acme"
+    assert data[0]["fingerprint"] == "1122334455667788"
+
+    # The sweep (no tap name) must alarm on this too, not exit 0.
+    sweep = boost("trust", "verify", expect=1)
+    assert "invalid" in sweep.out
+
+
 # ── enforcement: require_signed_taps ─────────────────────────────────────
 
 @pytest.fixture()

{boost_skill_cli-1.2.76 → boost_skill_cli-1.2.77}/tests/unit/test_provenance.py

@@ -103,13 +103,31 @@ def test_untrusted_when_key_not_registered(sandbox, signer, tmp_path):
     assert r.fingerprint == "1122334455667788"    # still reports whose key
 
 
-def test_untrusted_when_content_tampered(sandbox, signer, tmp_path):
+def test_invalid_when_trusted_keys_content_tampered(sandbox, signer, tmp_path):
+    """A manifest edited after a TRUSTED key signed it is INVALID, not merely
+    UNTRUSTED — the signature's key id still matches a trusted key, so this is
+    the tampering `trust verify` exists to catch, not an unknown signer."""
     provenance.add_trusted_key("acme", signer.public_key_text())
     clone = tmp_path / "clone"
     clone.mkdir()
     signer.write_signed(clone, manifest=b"original\n")
     (clone / provenance.SIGNED_FILE).write_bytes(b"tampered\n")
-    assert provenance.verify_dir(clone).status == provenance.UNTRUSTED
+    r = provenance.verify_dir(clone)
+    assert r.status == provenance.INVALID and not r.ok
+    assert r.key_name == "acme"
+    assert r.fingerprint == "1122334455667788"
+
+
+def test_untrusted_when_content_tampered_and_key_unknown(sandbox, signer, tmp_path):
+    """Tampering under a key that was never trusted stays UNTRUSTED — there is
+    no trusted key to blame, so it reads as an unrecognised signer."""
+    clone = tmp_path / "clone"
+    clone.mkdir()
+    signer.write_signed(clone, manifest=b"original\n")
+    (clone / provenance.SIGNED_FILE).write_bytes(b"tampered\n")
+    r = provenance.verify_dir(clone)
+    assert r.status == provenance.UNTRUSTED
+    assert r.fingerprint == "1122334455667788"
 
 
 def test_invalid_when_signature_present_but_manifest_missing(sandbox, signer, tmp_path):