chore(deps): bump docker/login-action from 3 to 4#2
Open
dependabot[bot] wants to merge 1 commit into
Open
Conversation
811f59c to
d20b526
Compare
blackbeardONE
pushed a commit
that referenced
this pull request
Apr 24, 2026
The consensus-maintained backing store for the nvidia-hmac-v1
registry that pkg/mining/attest/hmac has been consuming through
an in-memory stub since Phase 2c-i. Wire format + validation
+ state-view adapter only — the pkg/chain state-transition
hook that actually debits the sender's balance and inserts the
record is a separate follow-on commit (kept isolated because
consensus-critical diffs deserve their own review).
SECURITY MODEL (documented exhaustively in doc.go)
The nvidia-hmac-v1 HMAC key lives on-chain as public state.
That is by design under the ratified tiered trust-anchor
model: datacenter GPUs use nvidia-cc-v1 (real AIK crypto,
Phase 2c-iv), consumer GPUs use nvidia-hmac-v1 where
security comes from identity pinning + stake bond, NOT key
secrecy. An adversary who reads the chain can produce valid
bundles for any enrolled node_id, but the reward still flows
to the enrolled owner — so the rational worst case is
operators leaking their own keys, which is what the protocol
rewards anyway.
PACKAGE SURFACE
EnrollPayload wire format, stored in Tx.Payload
with ContractID = "qsdm/enroll/v1"
UnenrollPayload companion wire format
EnrollmentRecord on-chain state entry, keyed by
NodeID; covers stake, unbond
maturity, owner, memo
EnrollmentState read-only interface (Lookup,
GPUUUIDBound) that the chain's
state store will implement
InMemoryState reference implementation — ApplyEnroll,
ApplyUnenroll, SweepMaturedUnbonds
StateBackedRegistry adapts EnrollmentState to
hmac.Registry; defensive-copies
HMACKey so callers can't corrupt
state through returned entries
EncodeEnrollPayload canonical JSON encoder —
DecodeEnrollPayload - SetEscapeHTML(false) for cross-
EncodeUnenrollPayload platform determinism
DecodeUnenrollPayload - DisallowUnknownFields on decode so
attackers can't smuggle extras
past un-updated validators
- no trailing newline (json.Encoder
appends one; we strip)
PeekKind lenient kind-lookup for dispatch
before full decode
ValidateEnrollFields stateless check: Kind, node_id
character set (a-z0-9_-), gpu_uuid
printable-ASCII + case check,
hmac_key length [32..128],
stake_dust == mining.MinEnrollStakeDust,
memo ≤ 256 bytes, sender non-empty
ValidateEnrollAgainstState stateful: sender balance ≥
stake, node_id uniqueness,
gpu_uuid uniqueness among
ACTIVE records
ValidateUnenrollFields stateless for unenroll
ValidateUnenrollAgainstState sender == Owner, not
already unenrolled
KEY DESIGN DECISIONS
- Node_id character set [a-z0-9_-]: avoids unicode-
normalization pitfalls, matches existing miner tooling
conventions. Uppercase rejected to prevent "Alice" vs
"alice" ambiguity.
- gpu_uuid: case-preserved, must start with "GPU-" (upper)
if the prefix is present, no embedded whitespace. Looser
than RFC 4122 because nvidia-smi output varies by driver;
strict enough that "GPU-abc" ≠ "GPU-abc ".
- Stake exact-equals, not ≥: overpayment would leave surplus
in limbo. Operators who try to pay more get a clean
validation error.
- gpu_uuid released immediately on unenroll, BUT node_id
reserved until unbond matures: operators can unenroll rig
#1 and immediately enroll rig #2 with the same physical
GPU. The NAME stays locked so slashing can still target
the revoked record during its window.
- UnbondWindow = 7 days at 3s blocks = 201,600 blocks.
Genesis default, exported as var for future governance
adjustment.
- InMemoryState.ApplyEnroll / ApplyUnenroll return errors
on duplicate / missing rather than silently ignoring —
catches programmer errors where validation was skipped.
TESTS (54 new, 328 total across ./pkg/api/... ./pkg/mining/...)
codec_test.go (11):
- EnrollPayload round-trip (ensures tx signatures cover
bytes that decode back to the same struct)
- canonical bytes have no trailing newline
- encoding is deterministic across calls
- DisallowUnknownFields rejects smuggled fields
- trailing-data rejection (JSON-smuggling guard)
- wrong-kind rejection on both decoders
- PeekKind covers both variants + missing kind + non-JSON
- default-Kind on encode convenience path
validate_test.go (24):
- ValidateEnrollFields accept + 14-case table of rejects
covering every field + sentinel
- ValidateUnenrollFields accept + 4 rejects
- ValidateEnrollAgainstState accept, insufficient balance,
node_id taken, gpu_uuid taken, nil-state
- ValidateUnenrollAgainstState accept, wrong owner, already
unenrolled, unknown node
registry_test.go (11):
- StateBackedRegistry Lookup for active/not-registered/
revoked + defensive-copy check
- NilState panics (fail-loud contract)
- InMemoryState duplicate enroll fails, double unenroll
fails
- GPURebind after unenroll succeeds (physical binding
released)
- NodeID reserved during unbond (name-squatting guard)
- SweepMaturedUnbonds respects UnbondWindow boundary
- EnrollmentRecord.Active / MatureForUnbond
integration_test.go (1, crown jewel):
- Full path: payload → stateless validate → stateful
validate → ApplyEnroll → StateBackedRegistry →
NewProductionDispatcher → miner assembles bundle with
real operator key → validator accepts.
- Then ApplyUnenroll; fresh proof from the (now-revoked)
node is rejected, proving the revocation path reaches
the hmac verifier through the adapter.
EXPLICITLY NOT IN SCOPE (follow-on commits):
1. pkg/chain integration: debit sender's balance by
StakeDust, insert record into chain state, credit
released stakes to owners on sweep. Touches account
store + block sealer + receipt formatter — its own
review.
2. Block-time sweep trigger. Currently SweepMaturedUnbonds
exists but nothing calls it; the chain commit wires it
into block finalization.
3. Slashing path: governance-triggered tx that burns a
revoked record's StakeDust. Phase 2c-v.
4. HTTP/JSON-RPC surface for submitting enrollments (the
miner toolchain). Follows after chain integration.
a7f0726 to
96794a2
Compare
Bumps [docker/login-action](https://github.com/docker/login-action) from 3 to 4. - [Release notes](https://github.com/docker/login-action/releases) - [Commits](docker/login-action@v3...v4) --- updated-dependencies: - dependency-name: docker/login-action dependency-version: '4' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
96794a2 to
4c9adae
Compare
blackbeardONE
pushed a commit
that referenced
this pull request
May 11, 2026
…ld queue The macos-build.yml workflow had never actually completed a run end-to-end because the hosted macOS pool was queue-limited and concurrency.cancel-in-progress only cancels runs in the same head-ref group. 14h of backlog + 6 dependabot PRs sitting queued kept everything from ever reaching a runner. Cancelled 10 stale queued runs via the REST API (kept the latest v0.3.0 run). On the first run that actually got a runner, the no-CGO macos-14 job failed within 0.4s with: go: cannot find main module, but found .git/config in /Users/runner/work/QSDM/QSDM Root cause: build_macos.sh runs from working-directory=QSDM (the macos-build.yml convention), but go.mod lives at QSDM/source/go.mod. The CGO branch already handled the source/-indirection. The no-CGO branch did not -- it just called go build directly against the QSDM root, which has no go.mod. Fix: mirror the same `if [[ -f source/go.mod ]]; cd source` guard into the no-CGO branch. Also in this session: * Merged dependabot PR #11 (libp2p-pubsub 0.15.0 -> 0.16.0) after confirming all 24 PR-CI checks were green across build-test, govulncheck, trivy, docker, trustcheck, and wasm. * PR #12 (mattn/go-sqlite3 1.14.28 -> 1.14.44) hit a go.sum conflict after PR #11 merged -- triggered @dependabot rebase. * Posted @dependabot rebase on #1, #5, #6, #7, #8, #10 so they pick up the session-75 ripgrep fix and re-run cleanly. * Deferred PR #2 (login-action 3->4) and PR #13 (build-push-action 6->7): PR CI doesn't trigger release-container.yml (which runs only on push: tags: v*), so merging risks re-breaking the release pipeline we just stabilised in sessions 75-78. Path forward documented in RELEASE_NOTES_v0.3.0.md. Co-authored-by: Cursor <cursoragent@cursor.com>
blackbeardONE
pushed a commit
that referenced
this pull request
May 12, 2026
Documents the deploy of b1f72ef to api.qsdm.tech (BLR1): * binary cross-compiled linux/amd64, sha256 738796c3ddcd6efd8e38305549d9b8a4d445dd70ac392595e835152a3a5b46f3 * /etc/systemd/system/qsdm.service.d/host-key.conf drop-in sets QSDM_NETWORK_HOST_KEY_PATH=/opt/qsdm/host_key * restart #1 generated and persisted /opt/qsdm/host_key (93 bytes, 0600, sha256 03c91b27...) * restart #2 reloaded the same key * pre-deploy node_id: 12D3KooWBY9zdQ... * post-deploy node_id: 12D3KooWRH4MGi... (stable across restart) Includes an honest scope note: the post-restart "attested=0" trust- summary blip is NOT cured by this change. The NGC sidecar identifies bundles by a config-set qsdmplus_node_id (e.g. "vps-blr1-validator"), independent of the libp2p peer.ID. The real cause is the validator's in-memory accepted-attestation ring being wiped on every restart. Filed as a new follow-up named trust-attest-persist (mirror recentrejections.FilePersister).
blackbeardONE
pushed a commit
that referenced
this pull request
May 13, 2026
…ocs (Session 96)
Completes the v0.4.0 self-custody send story. Phase A (Session 95)
shipped the server backend (POST /api/v1/wallet/submit-signed);
this commit ships the browser-side signer + wire-up + documentation
so an end-user can move CELL from the qsdm.tech browser wallet
without their private key ever leaving the tab.
What landed:
- wasm_modules/wallet/cmd/qsdm-wallet/main.go exports a new global
qsdm_wallet_sign_transaction(envelope_json, private_key_hex,
public_key_hex). It parses the envelope into a struct
byte-shape-identical to pkg/wallet.TransactionData,
defensively clears any signature + public_key the caller put
on the envelope, enforces sender == hex(sha256(public_key)),
json.Marshal-s the canonical bytes, ML-DSA-87-signs via
walletcrypto, and re-marshals the final signed envelope as JSON.
Doing the canonicalisation inside the WASM module guarantees
byte-equality with the server's canonicalisation
(pkg/api/handlers.go::SubmitSignedTransaction) by reusing Go's
json.Marshal — sidesteps the JS/Go float-format drift (e.g.
1e-7 → Go: "1e-07", JS: "1e-7"). API version bumped from
"qsdm-wallet v1 / ml-dsa-87 / circl" to
"qsdm-wallet v2 / ml-dsa-87 / circl".
- QSDM/deploy/landing/wallet.html: 5th tab "Send transaction".
Form fields: keystore + passphrase + recipient + amount + fee
+ geotag + optional parent_cells + overridable validator
endpoint. UI calls out the v0.4.0 replay/atomicity gaps inline
so users understand the scope before clicking Send.
- QSDM/deploy/landing/wallet.js: full Send flow — read keystore,
decrypt with passphrase, derive sender (already validated as
hex(sha256(public_key)) by validateKeystore on the open path),
build envelope, call qsdm_wallet_sign_transaction, zero the
decrypted private key buffer, POST the signed envelope to
/api/v1/wallet/submit-signed (configurable endpoint), render
HTTP 200/409/4xx uniformly. Renders amount/fee via formatCell,
shows raw response body for debugging.
- QSDM/deploy/landing/wallet.wasm rebuilt from the v0.4.0+
source. Confirmed qsdm_wallet_sign_transaction global is in
the binary; size 3.88 MB (up from 3.24 MB — the json import
and the new handler account for the delta).
- QSDM/deploy/landing/wallet.html + wallet.js SRI hashes
refreshed via QSDM/scripts/build_wallet_wasm.sh
--refresh-sri-only:
wallet.wasm → sha384-XKMSFMnk27ul5OLXqm2zFMPtsdSVUGNXK8sChbKc/Y2nIqVLEB330Ll+UDhz0Eb6
wallet.js → sha384-RhWdFOoBDj5QlZ5eRwbYEpB3l2HVjLomt2F99v6OVWklQij/UogtRsNqoEl3P0O2
wasm_exec.js → unchanged (toolchain shim, no Go-side bump)
- QSDM/docs/docs/openapi.yaml: full /wallet/submit-signed entry
documenting the canonical-payload contract, the eight server
result tags, all error responses (400/402/405/409/422/500/503),
the v0.4.0 known gaps, and example envelope shapes.
- QSDM/docs/docs/MINER_QUICKSTART.md: Appendix B refresh. The
"Transfer from an existing CELL holder" row split into a
validator-signed row (existing /wallet/send) and a
self-custody row (new /wallet/submit-signed). Updated the
"Practical outcome for a fresh outside operator" bullet
#2 to point at the browser wallet's Send tab as the de-facto
social-bootstrap path for v0.3.x → v0.4.x.
- QSDM/docs/docs/V040_WALLET_SEND_DESIGN.md: Status header
bumped to "Phase B SHIPPED" with the full Session-96 delta
inline. Listed Phase-B-deferred items as v0.4.1 work
(qsdmcli wallet sign-tx, tag cut + cosign signing, BLR1
deploy, replay protection, atomic debit).
- pkg/audit/checklist.go api-06 row bumped from "BACKEND
IMPLEMENTED" to "FULLY IMPLEMENTED" with the WASM + browser
+ OpenAPI + docs deltas inline, plus the explicit "PENDING
for v0.4.0 release: tag cut + cosign-signed binaries +
BLR1 production deploy" line so the audit surfaces the
remaining release-cut work.
Verification:
$env:CGO_ENABLED="0"; go build ./... → green
$env:CGO_ENABLED="0"; go vet ./... → clean
$env:CGO_ENABLED="0"; go test ./pkg/api/ ./pkg/audit/
./pkg/monitoring/ ./pkg/wallet/ → 4/4 green
GOOS=js GOARCH=wasm go vet ./wasm_modules/wallet/... → clean
GOOS=js GOARCH=wasm go build -trimpath -ldflags '-s -w'
-o ../deploy/landing/wallet.wasm
./wasm_modules/wallet/cmd/qsdm-wallet → 3.88 MB, magic 00 61 73 6d
binary contains "qsdm-wallet v2" → yes
binary contains "qsdm_wallet_sign_transaction" → yes
Production-deploy posture: source tree only. BLR1 still serves
v0.3.3-s91; /api/v1/wallet/submit-signed is NOT reachable on
mainnet yet. The v0.4.0 tag cut + release-container.yml +
BLR1 binary swap is the next session's deliverable.
Known gaps (intentional, tracked in V040_WALLET_SEND_DESIGN.md
Future work and api-06 audit row, must close before
mining-05 testnet exposure):
1. No per-account nonce → cross-tx_id replay possible. Fix
planned for v0.4.1 (per-sender monotonic nonce).
2. Storage debit isn't atomic with the balance check → race
between two concurrent submit-signed calls from the same
sender can drive on-disk balance below zero. Fix planned
for v0.4.1 (atomic debit/credit + CHECK constraint).
blackbeardONE
pushed a commit
that referenced
this pull request
May 18, 2026
Fixes a previously-silent transparency-surface bug and adds two
industry-standard discovery files at the same time.
The bug
-------
Direct probes of the live site found that:
/.well-known/security.txt 200 (body: index.html — wrong)
/security.txt 200 (body: index.html — wrong)
/humans.txt 200 (body: index.html — wrong)
Caddy's SPA "try_files {path} {path}/index.html /index.html"
catch-all was matching every unknown path, so security researchers
or crawlers checking for an RFC 9116 vulnerability-disclosure file
got <!doctype html> back. That is arguably worse than a clean 404
because the 200 inflates uptime + crawler-success counters while
actually delivering nothing useful. Root cause was simple absence:
no .well-known/ directory on the webroot, no security.txt or
humans.txt files anywhere in source or on the server.
Also: sitemap.xml had every <lastmod> stuck at 2026-05-13 even
though the SVG audit badge, per-row deep-links, category
breakdown, homepage trust strip, trust.html callout, four
landing-page callouts, and JSON-LD Dataset structured-data work
have all shipped since.
The fix
-------
New files at QSDM/deploy/landing/:
.well-known/security.txt — canonical RFC 9116 disclosure file
(text/plain). 8 fields:
Contact: GitHub Security Advisory form
Contact: mailto:admin@qsdm.tech
Expires: 2027-05-17T00:00:00Z
Preferred-Languages: en
Canonical: well-known path
Canonical: root path
Policy: SECURITY_AUDIT.md on main
Acknowledgments: advisories page
Header comment documents the
response-time policy (72h ack /
14d fix-or-mitigate for crit/high)
and asks reporters to reference
audit-row IDs when applicable.
security.txt — byte-identical compatibility copy
at the root (RFC 9116 §3 fallback
for scanners that still probe the
legacy location).
humans.txt — W3C humanstxt.org TEAM / THANKS /
SITE blocks. Credits the project
lead, calls out the Cursor/Claude
pair-programming partnership, the
load-bearing open-source projects,
and a complete index of every
transparency surface the site
publishes.
Modified:
sitemap.xml — every <lastmod> bumped to its
file's actual last-meaningful-edit
date; audit.html priority raised
0.7 → 0.95 (now #2 behind the apex
landing, reflecting its cross-
referenced role on every product
page); trust.html raised 0.6 → 0.85
(same rationale); new 9th entry
for /.well-known/security.txt at
priority 0.3 (yearly changefreq).
Header comment documents the
priority calibration.
Verification
------------
Local:
sitemap.xml parses as valid XML (9 url entries).
security.txt × 2: 8 RFC 9116 fields each, identical body.
humans.txt: 3 W3C blocks present.
Live (after scp + chown caddy:caddy + chmod 644):
/.well-known/security.txt 200 text/plain 1558 bytes has Contact:
/security.txt 200 text/plain 1865 bytes has Contact:
/humans.txt 200 text/plain 2541 bytes has /* TEAM */
/sitemap.xml 200 text/xml 3299 bytes has <urlset
/robots.txt 200 text/plain 524 bytes has Sitemap:
Industry-standard surface; many enterprise vendor-security
checklists require security.txt presence during procurement /
due diligence (Mozilla Observatory docks points without it, as
does Google web.dev transparency scoring).
CHANGELOG entry under ## [Unreleased] / ### Fixed + ### Added.
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
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.
Bumps docker/login-action from 3 to 4.
Release notes
Sourced from docker/login-action's releases.
... (truncated)
Commits
4907a6dMerge pull request #930 from docker/dependabot/npm_and_yarn/aws-sdk-dependenc...1e233e6chore: update generated content6c24eadbuild(deps): bump the aws-sdk-dependencies group with 2 updatesee034d7Merge pull request #958 from docker/dependabot/npm_and_yarn/lodash-4.18.11527209Merge pull request #937 from docker/dependabot/npm_and_yarn/proxy-agent-depen...d39362abuild(deps): bump lodash from 4.17.23 to 4.18.1a6f092bchore: update generated content60953f0build(deps): bump the proxy-agent-dependencies group with 2 updates62c6885Merge pull request #936 from docker/dependabot/npm_and_yarn/docker/actions-to...102c0e6chore: update generated content