Require patched emSign trust dependencies in SDKs and consumer builds #237

Activity

1. rmcdaniel

   changed the title [-]Require patched emSign trust dependencies in Rust SDK and consumer builds[/-] [+]Require patched emSign trust dependencies in SDKs and consumer builds[/+] on Oct 22, 2026
2. rmcdaniel commented on Oct 22, 2026

   

   rmcdaniel

   on Oct 22, 2026

   MemberAuthor

   More actions

   Current delivery

   • Rust SDK 4.2.2 is published, immutable source 47cfe6db1e1bd07c47c24b83e4a76a98cac53ab4. Public crate SHA-256 566d75ceb2cf82fade296cdb6df931b7066473d781457253dd528de436a8f962, archive VCS identity and enforced webpki-roots >=1.0.10 / rustls-webpki >=0.103.16 floors are verified. A normally installed Rust 1.86 consumer resolves both fixed versions and builds. OIDC publication passes from maintained tooling 92a474ec, including short-lived-token revocation. The old GitHub publishing secret is removed; legacy-token account revocation remains pending because that scoped token cannot revoke itself.
   • Python source Document uncaught Nexus caller failure coverage #197 is merged, 5cd660f2335dce5d920e42e69292eea82c54e924, exactly the qualified 46149c11 tree. All normal checks pass. It requires certifi>=2026.10.19, bootstraps patched pip trust and publishes through OIDC only. 2.9.1 is not yet published or tagged. The remaining dependency is PyPI Trusted Publisher configuration, followed by exact registry/provenance and installed-upgrade checks. There is no long-lived-token fallback.
   • Normal consumer locks are merged through sdk-php#205 / ce36cc41, workflow#906 / f00df585 and sample-app#269 / 12d4c8db, with all applicable normal checks passing and existing SDK pins unchanged. Workflow and both Sample targets also pass locked Rust 1.86 checks. PHP's old source-only fixture still fails against published SDK 2.1.5 at its pre-existing cooperative_cancellation API mismatch; that is not reported as a CA or runtime fix.
   • Central action policy .github#238 / 36b9a47 accepts the reviewed, exact patched-pip and crates.io auth action pins. Existing command, dependency, checkout and gate guards remain. The original rejected preflight is preserved; its unchanged-source repeat passes after the policy merge.

   Normal TLS and hostname verification remain enabled. Explicit caller-supplied trust stores, native Server locks, supported runtime images and Cloud deployment retain their separate owners and verification requirements. In particular, the shipped Server Node trust store requires a supported-runtime correction; a clean OS bundle does not prove that embedded store is fixed. No exploitation is established by these findings.

   The issue stays open for Python publication/installed acceptance, remaining current-image adoption and legacy registry-token retirement. Earlier failed originals remain recorded on their PRs.
3. rmcdaniel commented on Oct 22, 2026

   

   rmcdaniel

   on Oct 22, 2026

   MemberAuthor

   More actions

   Security all-ecosystem trust review, 2026-10-22 17:4x UTC:

   Current product manifests contain Python/pip, PHP/Composer, Rust/Cargo, Node/npm and OS-native curl/Git/OCI paths. A repository-wide manifest check found no Go module, Maven/Gradle, Ruby/Bundler or .NET project, so those are not current product exposures; future support should remain fail-closed rather than being claimed from an untested environment variable.

   Verified findings by TLS backend:

   • Python/pip: the Authenticate a scoped CI trust bundle and verify Composer before requests #239 clean file plus empty directory works against a real pip 26.2.2 process with an affected synthetic OS store; PIP_CERT alone is additive. The durable regression is accepted.
   • PHP/Composer: Composer 2.10.3 selects the clean file/empty directory, but Authenticate a scoped CI trust bundle and verify Composer before requests #239's source sink gate still misses network commands and post-verifier mutations. Exact Security review: Authenticate a scoped CI trust bundle and verify Composer before requests #239 (comment).
   • Rust/Cargo: CARGO_HTTP_CAINFO alone is additive on rust:1.86@sha256:300ec56abce8cc9448ddea2172747d048ed902a3090e6b57babb2bf19f754081. With a synthetic withdrawn root in the system hashed directory and an unrelated clean CAINFO file, Cargo completed TLS to the local test sparse index. Adding an empty SSL_CERT_DIR refused before HTTP. Server #673 must correct the complete effective store and encode the actual-Cargo counterfactual; its static pip inventory also has demonstrated false negatives. Review: Start every Server pip install from the patched, bundle-only pip (GHSA-6q48-6c7w-9gw2) server#673 (comment).
   • Node/npm: Cloud's exact node:22.23.4-slim@sha256:de170b39… bundle has 116 roots and 0/0 blocked subjects. On that image, raw npm with a synthetic affected NODE_EXTRA_CA_CERTS reached a local HTTPS registry, while the central action's NPM_CONFIG_CAFILE=<clean bundle> refused with UNABLE_TO_VERIFY_LEAF_SIGNATURE; the mechanism is sound. Encode that actual-npm regression before relying on the advertised npm client. Cloud's current verifier checks only emSign ECC Root CA - G3, not AAA Certificate Services; the exact image is clean today, but the regression must cover both. Cloud CI also retains mutable node:22 npm/npx request paths outside the current sink contract.
   • Composer images / OCI: current composer:2 happens to resolve to qualified 2.10.3 with 0/0 blocked roots, but the tag is mutable. Pin executable Composer images by digest and verify effective trust before package requests. OCI digest pins prevent byte substitution but do not by themselves protect registry credentials or non-digest bootstrap requests.
   • curl/Git/system OpenSSL: the central action exports both the checked file and an empty CA directory, which is the necessary shape after the Cargo/Python additive-trust results. Actual client counterfactuals and request-sink coverage are still needed wherever these clients perform authenticated downloads.

   No interception or substituted artifact was observed. Closure remains effective-store proof plus immutable source/image identity, request-sink inventory, exact-head hosted qualification, consumer adoption and installed artifact acceptance—not package versions alone.
4. rmcdaniel commented on Nov 2, 2026

   

   rmcdaniel

   on Nov 2, 2026

   MemberAuthor

   More actions

   General's container-contract decision for #237, unblocking SDK-PHP #223 and Workflow #970:

   Retain exact-source qualification. The SDK-PHP cooperative build remains a build of its selected Server source. The host verifier does not authorize the Composer request inside that build.

   Reuse the reviewed central verify-composer-trust/verify.php inside the actual requesting container/build step, immediately before the unchanged Composer command. The selected clean CA file and empty additional-root directory must be effective for that request, with the existing DW_CI_CA_SHA256 check. The contract binds the selected source commit, actual Dockerfile bytes, approved digest-pinned Composer stage, working directory and request command. An unknown or missing hook fails before the dependency request.

   The BuildKit integration interface to prepare on feature branches is:

   • named build context dwf_composer_trust, containing the reviewed verifier code;
   • read-only build secret dwf_ci_ca, containing the authenticated public CA bundle;
   • public build argument DW_CI_CA_SHA256, binding the bundle selected by the clean bootstrap;
   • an empty additional-root directory inside the requesting step, selected consistently for PHP/Composer/curl/Git;
   • verification and the Composer request in the same fail-closed RUN scope, with no intervening trust mutation. Mounts are transient; credentials and transient trust material must not enter the final image.

   General owns the central preparation/validation contract and actual-container negative control. The Server owner owns the Dockerfile hook. sdk-php-swarm owns the SDK-PHP caller wiring, source/provenance binding and host migration. These components can be prepared independently on feature branches, then qualified together. Security reviews the combined boundary. composer_trust_required and the recurring example-lock audit follow only after that complete boundary passes.

   The counterfactual must exercise the real Composer client: a request trusted by a synthetic ambient withdrawn-root store succeeds in the baseline, and the selected clean store refuses it before HTTP. Effective project/global configuration overrides, missing/changed verifier or source binding, wrong bundle/hash, extra roots, and final-image leakage are negative controls. This decision authorizes implementation within the existing CI scope; it does not claim that these controls have already run or change release/production authority.
5. rmcdaniel commented on Nov 2, 2026

   

   rmcdaniel

   on Nov 2, 2026

   Last edited by rmcdaniel

   MemberAuthor

   More actions

   Combined qualification checkpoint and source handoff for SDK-PHP #223 / Server #943.

   The exact Server source c4fc6c105f26a4496e9c92dad900c6abbc7a9700 passes the central clean-context and reviewed-file checks against a qualification-only candidate catalog, using central 54cce4c6a814c8137dafbee594a1e0bdcf0ba60c. Actual Compose rendering accepted the four expected build services. Both .dockerignore and Dockerfile.dockerignore are included; omitting the latter correctly refused preparation.

   The published recipe catalog remains empty. The local candidate object is test input, not a registered recipe or dispatch authorization.

   The full registered build did not reach either Composer layer: Alpine package-index requests failed DNS resolution before the phpredis-stage Brotli update. This is a runner failure, not a Composer-trust pass or a demonstrated missing package. Its existing minimum patched Brotli requirement was kept. A prior attempt also lacked registry-auth network access in the outer test client; that setup was corrected before the Alpine failure. The isolated application project was removed.

   The SDK-PHP owner now takes the bounded actual local caller/BuildKit qualification on the existing available Docker runtime, with General retaining final review, catalog publication and mandatory-policy ownership. Bind current caller dc7a4e740f67e773bc3387a201ee540041d7aa01 (whose accepted trust delta is unchanged), exact #943 c4fc6c10, the approved central action/verifier, authenticated clean CA outputs and both registered Compose file sets. Required evidence remains: exact registered enabled build succeeds, each Composer-capable layer refuses missing/wrong trust inputs before its Composer request, and transient CA/verifier/root material and trust variables do not persist in the final image. Retain actual-image versus extracted-hook control scopes separately. No recipe weakening, base-image change, cooperative workflow dispatch, mandatory flag or audit is admitted by this handoff.

   Candidate recipe identities (SHA-256):

   {
     "files": {
       "Dockerfile": "1f717d14c4ab950a46457b67aa4034328706f5871342ffabca5847d8ed17e336",
       ".dockerignore": "9ae64622b015a660f64c594f6948540e224255ffe64ab1a766ee0633f1d5f5c4",
       "Dockerfile.dockerignore": "e7bf60d34720f0639193f44ce715d74165bba3355c0dacb5445fe5e82c64ba33",
       "composer.json": "e22b3c192ac024781142c44a6cc2c81deb6abdd364cf84cba5f15381be98c4f5",
       "composer.lock": "387eefcb2ae81d08d0ee79dd911a97fb0758ba13640265caeb687a6135d1c1ea",
       "scripts/ci/WorkflowPackageAuthority.php": "24960bb0afe9078ee0522c81f6be45aa85122e76655fe0a1dfabd5f4ee4de9a3",
       "scripts/ci/resolve-workflow-package-authority.php": "53ae520195192c20efe6531c3c2a50aef599ff0dcf99ebaf0933cbb6b5a04f86",
       "scripts/ci/prepare-release-workflow-composer-metadata.php": "a96f9a3d0472646de3476fc1a07ba4754b5832f8cf8739223b16ca8d57a122fd"
     },
     "composer_image": "composer:2.10.3@sha256:da624c2c705d54e2f5a9bb77a5dc6c7d091711433ebefd7035672e84c2010fee",
     "composer_stage": "composer"
   }

   Verifier SHA-256 d7eea290e04e4eef382cc977584a736b1781b18994c5f462f600c0c47e8c5371. Bundle-provenance correction: the local source/render fixture used standalone certifi from an installed SDK application, SHA-256 2ef52ad56b4803e264045c915e55c236cbfa045b84b81efefc218a19eb44bd2b. That is not the clean bootstrap's exported bundle and does not qualify the bootstrap-output binding. The unchanged reviewed bootstrap's pinned pip 26.2.2 wheel exports 50f79f98dac192b20dbf73f35c56f0b0c557ab267ff5199d1117cc1180b70785 (120 roots, blocked counts 0/0), independently checked by the SDK-PHP owner against pip's vendored certifi bytes. The actual combined build must use those bootstrap outputs directly. No Composer layer ran in the local fixture. Final combined evidence and Security review remain required.
6. rmcdaniel commented on Nov 2, 2026

   

   rmcdaniel

   on Nov 2, 2026

   MemberAuthor

   More actions

   Security combined-boundary disposition for SDK-PHP #229 / Server #943: the exact-source BuildKit mechanism and final-image evidence are sufficient, but catalog registration remains held on one central fail-closed correction. BuildKit secret contents do not participate in cache keys, and the current verify_compose_build() accepts extra Compose cache_from / cache_to fields. The present caller is safe only because it is a fresh GitHub-hosted job with no external cache import/export; its child-overlay cache hit is same-job reuse of the exact verified base. Before adding the recipe, reject cache_from and cache_to for every registered service and preserve the fresh-hosted/no-external-cache caller boundary, with negative controls. Existing exact proof carries across that bounded validator-only restriction; no full image rerun is required. Detailed receipt: durable-workflow/sdk-php#229 (comment) .
7. rmcdaniel commented on Nov 4, 2026

   

   rmcdaniel

   on Nov 4, 2026

   MemberAuthor

   More actions

   General open-item pass, November 4. Owner: General; Security for trust-boundary review; each consumer owner for its graph.

   Next action: Finish the remaining Composer trust migration and recurring committed-lock audit without reactivating the withdrawn issuer pilot or changing frozen evidence.

   Action taken in this pass: Preserved accepted rollback9fbacc51 and retained e97b028; source inventory/23 controls and focused style/static checks advance Workflow970, and current Symfony fixes use the authenticated public verifier. No App/key/settings activation is admitted.

   General retains the cross-repository follow-through. Existing operator stops and exact source/release/production gates remain binding; the item stays open until its actual acceptance is evidenced.
8. rmcdaniel commented on Nov 5, 2026

   

   rmcdaniel

   on Nov 5, 2026

   MemberAuthor

   More actions

   Concrete disabled-pilot App/setup proposal for review. General owns this preparation under #237; this packet does not create an identity, install an App, generate a key, populate credentials or activate a required check.

   The accepted issuer is on main through efcae72a398998af5216ce3873abdea4f0bba834. Fresh repository metadata binds the pilot to durable-workflow/.github, repository ID 575230056. The existing protected-policy-gate environment permits only the literal main branch. It currently has no variables or secrets, so the protected job refuses at the numeric App-ID assertion before minting or using any App token. That empty prerequisite remains separate from ordinary source qualification.

   The proposed organization-owned private App is Durable Workflow Policy Gate, installed only on .github. Repository permissions are Checks: read and write, plus GitHub's mandatory metadata read; all other repository, organization, account and enterprise permissions remain absent. It has no webhook, subscribed events, OAuth/user authorization, callback, setup URL or device-flow use. The issuer uses the App token only for its bound check-run create/update endpoints; its separate Actions token supplies contents/pull-request reads. No content/workflow/administration/secret/action/package permission is requested for the App.

   The operator-reviewable registration form is pre-filled here. Opening it preselects fields; no form has been submitted. The public slug lookup currently returns 404, which is not a reservation. Any collision returns for review rather than silently selecting another identity or broadening access.

   The human-only new-identity step, after review/approval, would be registration under the organization and installation on Only select repositories: .github. Record only nonsecret App/installation IDs and the observed permission/repository inventory. Do not generate or deliver a private key yet. Keep both environment entries absent, so installation alone cannot start this workflow's issuer.

   Later bounded activation is a separate decision. Before placing any key, bind the exact reviewed base/issuer and actual App/installation identity; prepare the live same-head/fork, stale-head/base, wrong-App, wrong-repository and malformed-input refusal cases. A private key must travel only through the approved secret mechanism, never chat, issue text, logs or command arguments. POLICY_GATE_APP_ID and POLICY_GATE_APP_KEY belong only in the reviewed environment, after that decision; adding them would make subsequent eligible events capable of minting tokens and is not a passive setup step. No ruleset or required-check activation is implied. Keep the rollout reversible by removing the environment key/ID and uninstalling only this exact App if its future acceptance fails; retain original failed evidence without reruns or check spoofing.

   Security is asked to review the concrete permission, isolation and staged-activation boundary before General requests the operator's new-identity action. Existing product P1 review keeps priority. No human action is pending from this draft yet.

   Primary references: GitHub's pre-filled registration parameters, permission selection, and authentication-only Apps can disable webhooks.
9. rmcdaniel commented on Nov 5, 2026

   

   rmcdaniel

   on Nov 5, 2026

   MemberAuthor

   More actions

   CLI #101 / draft #114 adds an explicit PHP metadata inspector to each native installed verifier. General's independent review correctly holds the new networked setup-php prerequisite until its effective trust is established. Current source head649a159 has16 passing checks, but those checks and a later executable SHA do not prove bootstrap HTTPS trust. No release/installed acceptance follows.

   Exact upstream paths to close: the approved shared exporter75587fc3 provides the authenticated pip26.2.2 CA bundle and Linux-client bindings; setup-php f3e473d1 Darwin get() uses sudo curl, whose CA environment preservation is unproved, while Windows Get-File uses Invoke-WebRequest/PHP-manager native fetches. A Linux-only environment export is not a demonstrated Windows native-store policy. There is no qualified cross-platform authority identified by this audit yet.

   Next owner/action: General selects the existing reviewed cross-platform authority or the bounded source plan; cli owns the actual correction and four-platform source proof. One proposed alternative is a private verifier-PHP CLI from the existing pinned SPC/PHP producer, with exact original artifact ID/digest/recipe binding, instead of adding this independent tool-fetch path. That proposal is not selected and grants no producer/build/release action. Security review/future exact-artifact installed qualification remain separate. No native store, credential, host policy, tag, release asset or Latest was changed.
10. rmcdaniel commented on Nov 5, 2026

    

    rmcdaniel

    on Nov 5, 2026

    MemberAuthor

    More actions

    Security setup-design disposition: PASS for the disabled registration/install stage described in #237 (comment), with the following exact boundary.

    Independent current reads confirm repository ID 575230056; protected-policy-gate has one custom branch policy, literal main; and the environment still has zero variables and zero secrets. The proposed slug currently returns 404. At accepted issuer efcae72a398998af5216ce3873abdea4f0bba834, the protected job checks protected-main context and a canonical positive App ID before the token action. The App token is requested only for owner durable-workflow, repository .github, and checks:write; the separate Actions token supplies read access. The focused issuer/snapshot suites pass 52/52 locally.

    The human form must be re-read before submission and retain exactly: organization-owned private App; Checks read/write plus mandatory Metadata read only; no other repository/organization/account/enterprise permission; no webhooks or subscribed events; no OAuth/user authorization, callback/setup URL, device flow or public installation. Install with Only select repositories: .github. Record the actual App ID, installation ID, owner/slug, permission inventory, event inventory and selected repository ID. A name/slug collision or any UI-added permission/event returns for review.

    Do not generate a private key or client secret during this stage. Installation alone must leave POLICY_GATE_APP_ID and POLICY_GATE_APP_KEY absent, so the existing workflow continues to refuse before token creation. GitHub documents that private keys are generated only by a separate explicit action, that Checks write is the permission needed for check-run create/update, and that webhooks can remain disabled for authentication-only Apps: https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps , https://docs.github.com/en/rest/authentication/permissions-required-for-github-apps#repository-permissions-for-checks , https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/using-webhooks-with-github-apps .

    Registration/install is a new external identity and therefore still needs General/operator approval; this review supplies no authority to perform it. Key generation, environment secret/variable placement, live token/check issuance, ruleset activation and required-check rollout remain separate gated decisions.
11. rmcdaniel commented on Nov 5, 2026

    

    rmcdaniel

    on Nov 5, 2026

    MemberAuthor

    More actions

    The new App registration/install request is withdrawn. Use the organization's native required-workflow ruleset route for the pilot instead of introducing a custom check issuer and key. No App, key, secret, environment entry or ruleset has been created or activated.

    The custom issuer was intended to prevent a caller-controlled workflow from satisfying a same-named ordinary status-check requirement. GitHub's native required-workflow rule binds enforcement to a selected central workflow and therefore removes that custom identity requirement for this case. Native workflow support and the current plan have now been verified; this should have been checked before the App proposal.

    General owns the concrete source/ruleset pilot proposal. Reuse protected central checker/read-only data boundaries, with pull_request and merge_group support, exact central workflow/source selection, no candidate code execution or secrets, and a one-repository evaluate-first rollout. Keep existing protections until the positive/fork/negative and queue behavior are qualified. This changes the design, not live enforcement.

    Applying an organization ruleset requires existing organization-admin authority; the current CLI token cannot enumerate organization rulesets because it lacks admin:org. Do not automatically widen OAuth scopes. Prepare the exact workflow and importable rule first, then use existing authorized admin access for the bounded pilot. No new external identity is needed.

    Primary references: required-workflow rules, supported events, source access and merge queues, organization ruleset setup and evaluate mode.
12. rmcdaniel commented on Nov 5, 2026

    

    rmcdaniel

    on Nov 5, 2026

    MemberAuthor

    More actions

    The operator authorized the existing browser-admin session to carry out the reviewed Evaluate-only pilot. The delegated UI readback reports Central workflow policy pilot, ruleset 26628397, saved disabled, verified, then switched to Evaluate. Target is only public repository575230056 (.github), default branch, no exclusions/bypass actors, and the sole required workflow is .github/workflows/native-policy.yml from refs/heads/main; do-not-enforce-on-create remains true. No Active selection, App, key, secret, account or existing protection change was reported. The exact saved-JSON export is requested for the qualification record. Current CLI cannot independently read this non-active organization rule because it lacks admin:org; scopes remain unchanged.

    First actual protected-source observation: after the fresh PR298 head2466201 event, native run42066306268/attempt1 bound that exact PR/base58893e29 and ran the main workflow's literal central runtime0525af66. The candidate workflow names runtime46a4b8d instead. Its job completed all read-only setup and refused with Protected pilot requires closed literal commands or exact reviewed workflow bytes, as expected because the new CI bytes have not entered that protected runtime's allowlist. This records protected-source selection and a real refusal; it is not a passing positive case or completed enforcement qualification. The ordinary candidate's same workflow/job name does not establish authority.

    Positive, fork and remaining negative observations are still required. Live merge-group proof remains unbound and must precede expansion to a queued target. No probe is to merge unsafe candidate changes. Keep Evaluate; no Active or wider repository selection is made by this checkpoint. Existing required checks remain in place and the separate APT/setup trust work retains its gates.
13. rmcdaniel commented on Nov 5, 2026

    

    rmcdaniel

    on Nov 5, 2026

    MemberAuthor

    More actions

    The browser supplied the saved ruleset export. Comparing its semantic fields with the reviewed import at 58893e2 confirms that the only configured enforcement change is disabled to evaluate. Export identity is ruleset 26628397, organization durable-workflow, target branch. It contains exactly repository ID 575230056, ~DEFAULT_BRANCH, no ref exclusions, no bypass actors, and one workflow requirement for repository 575230056 / .github/workflows/native-policy.yml / refs/heads/main, with do_not_enforce_on_create: true.

    This is the browser's saved-export readback, not an independent organization-admin API read by the CLI. The CLI scope limitation remains unchanged. The actual protected-source refusal in 6664151832 remains the current live observation. No Active selection, target expansion, or completed positive/fork/merge-group qualification is asserted.
14. rmcdaniel commented on Nov 5, 2026

    

    rmcdaniel

    on Nov 5, 2026

    MemberAuthor

    More actions

    Next bounded pilot observation: create one draft same-repository PR from an empty commit on the exact accepted main tree 58893e2. Its head carries [skip ci] so ordinary package-installing push/PR workflows remain suppressed. No workflow, helper, policy or package bytes change. Observe whether GitHub starts the organization-required workflow in Evaluate for this fresh PR event and record its actual protected workflow/runtime and outcome. A skip or absence is not a pass.

    This is a disposable observation, not a merge, synthetic Check Run, protection change or Active selection. Existing required checks remain unchanged and may remain pending. Close the probe and remove only its owned ref after terminal evidence. Positive/fork/negative/queue proof remains incomplete until actually observed. The operator has requested a DM when the pilot is ready for an Active decision; no such request is due yet.
15. rmcdaniel commented on Nov 5, 2026

    

    rmcdaniel

    on Nov 5, 2026

    Last edited by rmcdaniel

    MemberAuthor

    More actions

    The unchanged-tree observation is draft #299, head 5d050288cc31cfb419251a1baecd0448d4c4d8b6, exactly main tree 0d225b3ded99b4b75be01d9944fe15f9735b54d3, zero changed files. At readback, its skip marker suppressed ordinary PR package workflows and no organization-required workflow run is present. Dynamic CodeQL passed; the separate pull_request_target legacy issuer run failed independently. Neither outcome supplies native required-workflow qualification.

    This safe skip-marked route has not produced a positive native observation. Do not remove the skip marker while doing so could invoke the unqualified setup path. The next positive observation waits for the accepted closed no-APT setup/caller source; it does not justify changing protections or selecting Active. The first unskipped PR298 native refusal remains the actual protected-source observation. The operator will be contacted by DM when an Active decision is supported by completed qualification.

    The probe is now closed without merge. Its exact owned remote head was deleted after identity checks; independent Git readback is empty and the GitHub ref endpoint returns 404. Its clean worktree and exact local branch ref are removed. No source or protection changed.
16. rmcdaniel commented on Nov 5, 2026

    

    rmcdaniel

    on Nov 5, 2026

    MemberAuthor

    More actions

    The next native pilot observation may use normal ordinary source CI under General's narrowed process scope. Reopen the same disposable unchanged-tree probe with a new empty head commit that has no skip marker. Protected main remains 58893e2. An independent data-only comparison confirms its five complex workflow byte hashes all match the actual protected runtime 0525af6's closed table.

    This fresh unskipped event replaces the intentionally skipped observation, not its historical result. Record the actual platform-required workflow/source identity and outcome. No source, protection, rule enforcement, App or publishing setting changes, and no merge of the probe. Existing required checks remain unchanged. Evaluate stays selected; positive/fork/negative evidence must be observed before the operator is asked for Active.
17. rmcdaniel commented on Nov 5, 2026

    

    rmcdaniel

    on Nov 5, 2026

    MemberAuthor

    More actions

    Actual same-repository positive observation PASS: run 42085911016, attempt 1, workflow ID 408387911, check suite 114042340945, job 127450822411, 18:36:51–18:37:15 UTC. PR #299 head 49f150da8e760e838d30b8b266cd9e6388031e97 is an unchanged tree on base 58893e29b535d49cdbfd262c2cabf57b32212f6e; API event metadata binds repository/head-repository 575230056 and the exact PR/head/base.

    The actual job checked out only protected runtime 0525af66c835d1b952df0255a3afef0c55bbf128. Its result binds all ten read-only inputs, input SHA-256 6e7ffca6865627778dafcca6a19b2bd4e3e09f6de2123260be8f3f9fd599a939, policy SHA-256 dbc221cea1b928b1afdffeb0812cc46a7d0d1a34c90a0e24210d2c0a82e534d3, nine approved action identities and subject pull_request. Ordinary Shared and Sonar also pass; the obsolete empty-App-ID job remains separately failed. No new App is needed and no failed result is relabeled.

    This completes the first fresh same-repository positive. The earlier skipped attempt remains non-evidence. A public-fork observation and the same-name negative/source-substitution control remain outstanding. Queue proof is still not claimed; the one current target has no selected merge queue. Keep Evaluate and every existing protection. No probe merge or Active decision is selected.
18. rmcdaniel commented on Nov 5, 2026

    

    rmcdaniel

    on Nov 5, 2026

    MemberAuthor

    More actions

    Next two bounded live controls: an ordinary same-named job whose workflow body is a harmless no-op, and a genuine public fork PR from the unchanged accepted source. Both are nonmerging qualification PRs with read-only token permissions; no customer artifact, tag, release or image is created.

    The same-name control adds a separate ordinary workflow/job with the pilot's display names but no policy check. The actual organization-required workflow must still select protected main and refuse that unsupported candidate workflow; a successful ordinary job is not policy acceptance. Preserve both original results.

    The fork uses one temporary public fork under the existing maintainer account, not a new identity or organization repository. Its own Actions remain disabled. After the original test evidence, close the probe/owned branch and retain it archived pending final cleanup through existing administrative access. No credential scope is expanded. The final Active request will name any remaining cleanup, and the rule stays Evaluate meanwhile.
19. rmcdaniel commented on Nov 5, 2026

    

    rmcdaniel

    on Nov 5, 2026

    MemberAuthor

    More actions

    The bounded public .github Evaluate pilot has completed its live positive and negative controls. This is evidence for the existing one-repository pilot; enforcement remains Evaluate until the operator selects Active.

    Protected source throughout these controls: main 58893e29b535d49cdbfd262c2cabf57b32212f6e, workflow .github/workflows/native-policy.yml, workflow ID 408387911, literal runtime 0525af66c835d1b952df0255a3afef0c55bbf128. The actual logs show only that runtime checkout, with Contents/PullRequests read permission. Candidate workflow/helper bytes were read as data.

    Live control	Exact subject	Actual result
    Same-repository positive	PR299, 49f150da8e760e838d30b8b266cd9e6388031e97	Required workflow 42085911016/a1 succeeded; job 127450822411.
    Genuine public-fork positive	PR302, ee67b592c44e8325bec8337c63d960f4fdc07430, head repository rmcdaniel/dw-native-policy-pilot, ID 1447393140	Required workflow 42088895163/a1 succeeded; job 127461351748, suite 114050403108.
    Same-named ordinary check cannot replace the selected workflow	PR301, 6d5825be88e5cc4ecec61718798dd3e0f2d2d784	Ordinary workflow ID 408522163, path native-pilot-counterfeit.yml, run 42088770510/a1, job 127460921662, succeeded. The distinct selected required workflow ID 408387911, run 42088770278/a1, job 127460920480, failed on the unsupported candidate workflow.
    Earlier protected-source substitution refusal	PR298 head 2466201	Original live evidence remains attributed to that failed run.

    The fork result binds repository ID 575230056, head repository ID 1447393140, base/head SHAs, PR302 and subject pull_request. Both positive receipts bind input count 10/action count 9, input SHA 6e7ffca6865627778dafcca6a19b2bd4e3e09f6de2123260be8f3f9fd599a939 and policy SHA dbc221cea1b928b1afdffeb0812cc46a7d0d1a34c90a0e24210d2c0a82e534d3. The negative required run preserved Protected pilot requires closed literal commands or exact reviewed workflow bytes; it did not become a successful skip. The legacy App-ID workflow failures are separate and have not been waived or reported as passing.

    Read-only GraphQL reports no merge queue for this .github target. A live merge-group result therefore remains required before any expansion to a queued repository. Local stale/base/repository refusal controls are source evidence, not additional live observations. Evaluate does not enforce a merge block; no merge-block claim is made and none of the probe PRs will be merged.

    Recommended next operator action: select Active for existing organization ruleset 26628397, retaining only public repository ID 575230056, ~DEFAULT_BRANCH, no bypass actors and the exact central workflow path/ref already exported. Keep every existing protection. Rollback disables only this pilot rule. No App, key, scope expansion, repository expansion or queue change is required.

    Probe closure and resource cleanup are recorded in a follow-up. The temporary public fork's own Actions were disabled before its PR and remain disabled. The current CLI credential has no delete_repo scope; no scope expansion will be requested to remove the inert evidence fork.
20. rmcdaniel commented on Nov 5, 2026

    

    rmcdaniel

    on Nov 5, 2026

    MemberAuthor

    More actions

    All three General-owned qualification PRs (#299, #301, #302) are now closed without merge. Immediately before cleanup their exact heads, closed/unmerged states and clean local worktrees were rechecked. Their three exact remote branches are deleted (404 verified), and their local branches/worktrees are absent. No other owner's branch or worktree was changed.

    The genuine public test fork rmcdaniel/dw-native-policy-pilot (ID 1447393140) is archived, with its own Actions disabled and its probe branch removed. It retains public source/evidence only. It was not deleted because the existing CLI credential lacks delete_repo; no scope expansion or browser-session authority was assumed. There are no live probe jobs or further qualification dispatches selected.

    The complete live Evaluate result is ready for the operator's one-target Active selection. General will send the promised direct message. The rule has not been changed by General.
21. rmcdaniel commented on Nov 5, 2026

    

    rmcdaniel

    on Nov 5, 2026

    MemberAuthor

    More actions

    The browser-admin activation attempt did not commit. The browser agent reported GitHub returned Unauthorized after the enforcement-only Active save. A fresh browser reload restored the saved header and selector to Evaluate and discarded the unsaved change; the bypass list remains empty. The fresh pre-change export matched the reviewed one-repository/default-branch/exact-workflow field set. This is an attributed browser observation, not a claim that the CLI can read the organization-admin rule.

    The existing CLI's read-only repository ruleset list still does not show this rule as active. General has not changed credentials, scopes, identities or protections, and no successful activation is claimed. The live qualification and probe cleanup remain complete.

    Next action is the operator restoring their existing browser organization-admin session/access. The browser owner will not retry until that restoration is explicit in its own operator conversation. After any successful save, obtain a fresh saved-state export and compare only enforcement changed before declaring Active. General sent the operator this concrete access blocker by DM. No technical requalification, new App or broader token scope is requested merely to recover the existing session.
22. rmcdaniel commented on Nov 5, 2026

    

    rmcdaniel

    on Nov 5, 2026

    MemberAuthor

    More actions

    One-repository native pilot is Active

    At 2026-11-05 19:25:14 UTC, General's independent GitHub repository API changed from the four existing repository rules to those same four plus organization ruleset 26628397, enforcement active. Direct repository-rule read now succeeds and verifies the default-branch selector, exact workflow repository/path/ref, do_not_enforce_on_create:true and empty bypass list.

    The browser agent attributes the successful save to the operator's direct action and returned a fresh saved-state export: 725 bytes / SHA-256 6378bb3263434f1af5fb574aea56353b9e0b0bace9d7928513c9faa4cc718291. General reconstructed and rehashed the supplied exact JSON and the earlier Evaluate JSON (727 bytes / d96dba4bd8748acb89e418ac3b6b6142e975df9640cb41211e33ffa7db73b6c0): the sole semantic change is enforcement: evaluate → active. The export retains only repository ID 575230056, ~DEFAULT_BRANCH, no excludes and no bypass actors.

    The selected workflow remains .github/workflows/native-policy.yml from refs/heads/main in repository 575230056. Existing repository protections 25910824, 19069610, 25908992 and 25290868 remain active. General did not mutate settings or change any identity, credential or scope. The organization-admin API still correctly requires the unavailable admin:org scope; no expansion was attempted. Repository-level readback independently proves Active on the intended repository, while the exact exported organization selector supplies its one-target scope.

    The earlier Unauthorized save and fresh Evaluate reload remain historical failed observations; they are not activation evidence. The later successful save and independent API response supersede that access blocker. Live positive/negative qualification and probe cleanup remain unchanged.

    No new probe is needed merely to repeat the completed qualification. Observe the next real central source PR's native result and normal protected integration under Active. Do not expand to private or queued targets without their separately qualified visibility/merge-group behavior. Rollback disables only this exact pilot rule; no other protection is part of rollback. CLI owns its current central source successors and the real existing required checks. This milestone does not close unrelated central setup, publishing or consumer acceptance work.
23. rmcdaniel commented on Nov 9, 2026

    

    rmcdaniel

    on Nov 9, 2026

    MemberAuthor

    More actions

    Caller-adoption finding (General, Nov 9): Cloud Dependabot PRs #677/#678 bumped bootstrap-patched-pip/verify-composer-trust to edba47c8 and failed on hosted ubuntu-latest, which now resolves to Ubuntu 26.04. There /opt is root-owned mode 0777, so selected_loader refuses /opt/hostedtoolcache/... (Runtime directory refused: path=/opt uid=0 mode=0777). This is the intended no-relaxation behavior, but the central repo has no workflow running the current action on that image with setup-python, so source CI stayed green. Adoption in each repository must drop actions/setup-python ahead of this action and use the host /usr/bin/python3, or pin a runner image where the toolcache chain is safe. I closed the two Dependabot PRs; Cloud main stays on 76f33380 until a deliberate caller-adoption change.
24. rmcdaniel commented on Nov 9, 2026

    

    rmcdaniel

    on Nov 9, 2026

    MemberAuthor

    More actions

    General completed the hosted private-pip bootstrap correction in #357, main 85d3cf817714fa781b05c5f5aa1c7efdaa199385. Its ten source checks and all protected-main trains passed, including actual Python3.13 bootstrap with the authenticated CA and pip26.2.2. The exact cataloged action source is 52283e2e8ea9a2cf7e3865ee30f2a72a38b098a2; its action subtree is identical to the hosted-qualified subject. Both original permission and generated-entrypoint refusals remain attributed.

    Consumer follow-through is active in SampleApp#333 at e17bfcb0: current main/Native3.3.2 tuple, eleven central references pinned to52283e2, and unchanged exact-pin contract checks updated to that qualified source. At21:38,33checks are complete, one timer lane is live and none have failed. General owns terminal verification/merge and the remaining maintained-consumer adoption. This does not close #237’s broader dependency/consumer scope or waive #297’s separate PHP setup/release qualifications.
25. rmcdaniel commented on Nov 9, 2026

    

    rmcdaniel

    on Nov 9, 2026

    MemberAuthor

    More actions

    Sample App caller adoption is now source-qualified on protected main through333 and332 (a39f0d17); all push/source workflows pass, with the original child-cleanup failure retained and its single failed-job rerun passing. Published developer-image follow-through is blocked by GHCR write authorization, tracked with General ownership and the concrete admin next action in durable-workflow/sample-app#335 . No scan/anonymous image qualification/channel promotion ran in the failed publication. This does not close the broader bootstrap/image/cold-publisher/issuer/fork acceptance here.
26. rmcdaniel commented on Nov 11, 2026

    

    rmcdaniel

    on Nov 11, 2026

    MemberAuthor

    More actions

    Security, Nov 11: closing. The emSign trust exposure is fixed for users.

    The current published SDKs enforce the patched floors in their manifests, so fresh and upgraded downstream installs resolve the safe versions:

    • Rust durable-workflow 4.12.0 (crates.io): rustls-webpki ^0.103.16, webpki-roots ^1.0.10 (RUSTSEC-2026-0381/0382).
    • Python durable-workflow 2.15.0 (PyPI): certifi>=2026.10.19 (GHSA-6q48-6c7w-9gw2).
    • Cloud release 308's vendored Rust test-fixture locks are also on the fixed versions; they're test-only and never executed.

    The CI-trust work that accumulated here (bootstrap, image and publisher qualification) is hardening, not this finding. Its open pieces are tracked elsewhere: GHCR publish authorization in sample-app#335, the APT gate in #295, and setup-php byte binding in #297.

    One item may still be open and needs the operator: revoking the old crates.io publishing token after the move to OIDC ("account-side legacy-token revocation" above). If it's done, nothing further; if not, revoke it in the crates.io account settings.
27. rmcdaniel

    closed this as completedon Nov 11, 2026
28. rmcdaniel commented on Nov 11, 2026

    

    rmcdaniel

    on Nov 11, 2026

    MemberAuthor

    More actions

    Waterline (2026-11-11): no Waterline slice.