fix(installer): skip Step-5 pre-verify for freshly-minted credentials (→ v1.8.3)#293
Merged
Merged
Conversation
Third R8 install regression found running curl|bash end to end: the #279 reorder mints the credential (Step 3) and deploys the client pod (Step 4) BEFORE Step 5's verify_credentials. A freshly minted client is "set to enroll" — it goes active only once the deployed pod connects — so verify_credentials (api-token-auth) returns 400/invalid and hard-fails a perfectly good install: "TRACEBLOC_CLIENT_ID / TRACEBLOC_CLIENT_PASSWORD was rejected by tracebloc". A minted credential is valid by construction (client create just made it), so pre-verifying it adds no correctness value and only races enrollment. Trust the mint; the deployed pod enrolls the client. - provision.sh: export TRACEBLOC_CLIENT_MINTED=1 on the mint path (cleared up front, not set on adopt / dual-mode). - install_client_helm Step 5: when minted, skip verify_credentials and show a non-fatal "Provisioned client N — it will connect shortly" instead of erroring. User-entered / dual-mode creds still verify (those can be wrong). - manifest.sha256 regenerated (provision.sh + install-client-helm.sh are pinned); chart 1.8.2 -> 1.8.3. Tests: provision.bats asserts the mint sets MINTED (adopt doesn't); install-client- helm.bats adds a test that a minted credential skips verify and succeeds even when verify would return invalid. shellcheck clean; gen-manifest --check passes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
aptracebloc
approved these changes
Jul 1, 2026
This was referenced Jul 1, 2026
Merged
Merged
saadqbal
added a commit
that referenced
this pull request
Jul 2, 2026
…vert #293 → v1.8.4) (#295) #293 skipped verify_credentials for freshly-minted credentials on the premise that a minted client is "set to enroll" and only goes active once the pod connects, so the api-token-auth pre-verify would 400 on a valid credential. That premise was wrong. The real reason verify 400'd was a CLI bug (tracebloc/cli#125): `client create` wrote the numeric dashboard id — not the UUID username — as TRACEBLOC_CLIENT_ID, which is the auth username. The credential was genuinely invalid; verify_credentials was a correct canary that #293 masked, letting the install "succeed" while the pod crash-looped on "Unable to log in with provided credentials". With cli#125 fixed (v0.5.1), a minted credential is valid and verify passes. Restore the canary so a bad credential fails loudly at install time (Step 5) instead of silently at pod runtime: - install-client-helm.sh: drop the TRACEBLOC_CLIENT_MINTED skip branch; always verify_credentials in Step 5 (mint, adopt, and dual-mode alike). - provision.sh: drop the TRACEBLOC_CLIENT_MINTED marker (now unused). - tests + manifest.sha256: reverted to the pre-#293 state. - Chart: 1.8.3 → 1.8.4 (forward; not a version rollback). DEPENDS ON tracebloc/cli#125 (v0.5.1) being the latest CLI release — the installer fetches the CLI fresh, so the canary only passes once v0.5.1 mints the correct UUID username. Do not release this chart before v0.5.1 is out. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Third R8
curl | bashinstall regression from the #279 reorder — found by running the installer end to end (Step 5 this time).The bug
The reorder mints the credential (Step 3) and deploys the client pod (Step 4) before Step 5's
verify_credentials. A freshly-minted client is "set to enroll" — it activates only once the deployed pod connects — soverify_credentials(sameapi-token-authjobs-manager uses) returns 400/invalid and hard-fails a perfectly good install:(Confirmed on a real install: Step 3 provisioned client 1052, Step 4 Helm-installed, Step 5 rejected it.)
Fix (Option 1 — trust the mint)
A minted credential is valid by construction, so pre-verifying adds no correctness value and only races enrollment.
provision.sh: exportsTRACEBLOC_CLIENT_MINTED=1on the mint path (cleared up front; not set on adopt / dual-mode).install_client_helmStep 5: when minted, skipverify_credentials— show non-fatal "Provisioned client N — it will connect and appear at ai.tracebloc.io/clients shortly". User-entered / dual-mode creds still verify (those can be wrong).Chart 1.8.2 → 1.8.3;
manifest.sha256regenerated (both scripts are R8-pinned).Tests
MINTED=1, adopt doesn't.gen-manifest --checkpasses; provision.bats 12/12.Lands on develop; a matching PR to
maincuts v1.8.3.Note
Medium Risk
Changes installer credential handling for the mint path only; user-entered and preset env creds still go through api-token-auth verification.
Overview
Fixes a
curl | bashinstall failure where Step 5verify_credentialsrejects credentials that Step 3 just minted: new clients stay “set to enroll” until the pod connects, soapi-token-authreturns 400 even when the install is valid.provision.shclearsTRACEBLOC_CLIENT_MINTEDat entry (so a stale env cannot skip verify), setsTRACEBLOC_CLIENT_MINTED=1only on theclient createmint path—not on adopt or dual-mode preset creds.install_client_helmStep 5 skipsverify_credentialswhenTRACEBLOC_CLIENT_MINTED=1and shows a success message that the client will connect shortly; user-supplied / env creds without the mint flag still verify as before.Helm chart 1.8.2 → 1.8.3;
manifest.sha256updated for the touched install scripts. Bats cover mintMINTED=1, adopt without it, and the minted skip even when verify would return invalid.Reviewed by Cursor Bugbot for commit c9274fc. Bugbot is set up for automated code reviews on this repo. Configure here.