Account guide
One Apple password submit, with the second factor captured in the registered session.
The apple_login and create_developer_id trajectories bind three one-use Skarbiec capabilities to one authorization, run the browser on one Stado-selected worker, and obtain a trusted-device code only from the macOS user that the live identity registry names.
Placement is checked before a password is used#
Before Weles opens its browser, it resolves the account address from Skarbiec and asks Stado for the live apple-account binding. The binding must be observed on the named host, name the same macOS user as the current console, and report an Apple challenge session that is drivable.
The preflight also resolves the execution host's Weles broker and runs version 2 of the signed Stado Apple challenge helper with --preflight inside that exact Aqua session. This calls AXIsProcessTrusted without its prompt option: it scans no windows, opens no consent window, and refuses the trajectory before the password submit when Accessibility is unavailable.
The six digits take one managed path#
After Apple accepts the password and displays its trusted-device prompt, Weles asks Stado to relay that authorization. Stado resolves the same verified holder again, runs /usr/local/libexec/stado-apple-challenge-capture in its Aqua session, presses only an exact Apple Allow button, reads one six-digit code, and removes the owner-only capture file.
The digits then travel on standard input to skarbiec apple-challenge-put in the execution host's broker. They never enter an argument, registry value, receipt, or diagnostic. Weles redeems the pending challenge capability once, clears the plaintext after filling Apple's verification input, and cancels the remaining capabilities; their TTL still bounds them if cleanup cannot be confirmed.
authorizer -> Stado issues capabilities on the worker
preflight -> Stado verifies the registered Aqua session
Apple -> one authorized password submit
holder -> signed Stado helper reads the trusted-device prompt
worker -> Skarbiec stores challenge:apple/<authorization-id>
Weles -> one capability redemption fills the browserDeveloper ID returns both halves to the caller#
Developer ID Application is the Account Holder path. The authorizer creates the private key and CSR on the calling machine, writes the private key to the requested owner-only path, and sends only the CSR through the pinned Stado job.
The create_developer_id trajectory signs in through the same placement and capability path, uploads the CSR, and downloads the DER certificate. The authorizer waits for the terminal Stado job, validates exactly one returned DER X.509 certificate, and writes it to --certificate-out; the worker removes its request and certificate directory on every exit.
After Apple issues the certificate, the trajectory records a two_factor receipt tied to this authorization. It identifies the trusted-device holder, macOS user, destination, and capability source without returning the six digits. A filled verification input or a portal URL alone does not count as provider acceptance.
Probierz can pass --execution-runner with the absolute path of stado-action-runner.mjs in the staged Weles source. This runs the exact source under examination without replacing the installed worker; a relative path is refused. Normal authorizer calls omit this option and use the installed worker.
node scripts/auth/authorize-apple-developer-id.mjs \
--account-item weles-apple-control-account \
--confirm "AUTHORIZE ONE APPLE DEVELOPER ID" \
--execution-host <worker-target> \
--execution-agent weles-worker \
--expires-in-minutes 15 \
--private-key-out /absolute/developer-id.key \
--certificate-out /absolute/developer-id.cerVerify issuance through Probierz#
The weles-apple journey runs tests/apple/developer-id.spec.mjs from the selected Weles revision on charless-mac-mini. It requires a real Account Holder item and the registered trusted-device session. It performs one issuance attempt, so it can trigger the Apple consent prompt and notification required by that sign-in.
The journey checks malformed-account and duplicate-output refusals, the authorization-bound second-factor receipt, certificate validity, and the match between the issued certificate and the retained private key. Probierz retains the source identities, command output, trace, and public certificate; the private key stays in the owner's .stado/work directory. A preflight, queued job, or failed authorization is not a passing issuance test.
probierz stado run tui \
--app weles-apple \
--host stado:mini \
--node-source \
--app-repo /absolute/path/to/weles \
--spec '$PROBIERZ_APP_SOURCE/tests/apple/developer-id.spec.mjs' \
--env=WELES_APPLE_ACCOUNT_ITEM=weles-apple-control-account \
--env=WELES_APPLE_EXECUTION_HOST=charless-mac-mini \
--env=WELES_HEADLESS=1