Skip to content

chore(deps): bump docker/login-action from 3 to 4#2

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/github_actions/docker/login-action-4
Open

chore(deps): bump docker/login-action from 3 to 4#2
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/github_actions/docker/login-action-4

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Apr 22, 2026

Copy link
Copy Markdown
Contributor

Bumps docker/login-action from 3 to 4.

Release notes

Sourced from docker/login-action's releases.

v4.0.0

Full Changelog: docker/login-action@v3.7.0...v4.0.0

v3.7.0

Full Changelog: docker/login-action@v3.6.0...v3.7.0

v3.6.0

Full Changelog: docker/login-action@v3.5.0...v3.6.0

v3.5.0

Full Changelog: docker/login-action@v3.4.0...v3.5.0

v3.4.0

Full Changelog: docker/login-action@v3.3.0...v3.4.0

... (truncated)

Commits
  • 4907a6d Merge pull request #930 from docker/dependabot/npm_and_yarn/aws-sdk-dependenc...
  • 1e233e6 chore: update generated content
  • 6c24ead build(deps): bump the aws-sdk-dependencies group with 2 updates
  • ee034d7 Merge pull request #958 from docker/dependabot/npm_and_yarn/lodash-4.18.1
  • 1527209 Merge pull request #937 from docker/dependabot/npm_and_yarn/proxy-agent-depen...
  • d39362a build(deps): bump lodash from 4.17.23 to 4.18.1
  • a6f092b chore: update generated content
  • 60953f0 build(deps): bump the proxy-agent-dependencies group with 2 updates
  • 62c6885 Merge pull request #936 from docker/dependabot/npm_and_yarn/docker/actions-to...
  • 102c0e6 chore: update generated content
  • Additional commits viewable in compare view

@dependabot dependabot Bot added dependencies Pull requests that update a dependency file github_actions Pull requests that update GitHub Actions code labels Apr 22, 2026
@dependabot dependabot Bot changed the title Bump docker/login-action from 3 to 4 chore(deps): Bump docker/login-action from 3 to 4 Apr 22, 2026
@dependabot dependabot Bot force-pushed the dependabot/github_actions/docker/login-action-4 branch 3 times, most recently from 811f59c to d20b526 Compare April 24, 2026 05:34
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.
@dependabot dependabot Bot changed the title chore(deps): Bump docker/login-action from 3 to 4 chore(deps): bump docker/login-action from 3 to 4 May 10, 2026
@dependabot dependabot Bot force-pushed the dependabot/github_actions/docker/login-action-4 branch 2 times, most recently from a7f0726 to 96794a2 Compare May 11, 2026 03:50
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>
@dependabot dependabot Bot force-pushed the dependabot/github_actions/docker/login-action-4 branch from 96794a2 to 4c9adae Compare May 11, 2026 04:00
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file github_actions Pull requests that update GitHub Actions code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants