* ci(security): scan new commits on push/PR and the current tree weekly
`base: main` made every push to main rescan the whole history. Nova's own
Infura keys, removed from the files in #72 but still in history and live,
kept Secret Scan red on every push since at least 2026-09-21, so a new leak
would have read as the same old red.
- push and pull_request: no `base`, so the action scans only the commits the
event brings (before..after, or the PR's base..head)
- schedule: scan a `git archive HEAD` copy of today's tree
- pin the action to v3.99.2 by commit and the image to 3.99.2 (was @main and
latest)
* ci(security): exempt the TruffleHog action from the AGPL licence denial
Pinning the action made dependency review evaluate it for the first time.
It runs unmodified in CI and is not linked into or shipped with anything.
The organisation's code security configuration enables CodeQL default
setup, and GitHub refuses to apply it while a workflow runs CodeQL itself:
the configuration failed on this repository with "Code scanning conflict".
Default setup covers what this job did. The job ran the default query
suite with no config file, path filters or packs, and the languages it
analysed are among those default setup detects here. Default setup takes
over the scan; this workflow keeps its other jobs.
security-events: write served only the SARIF upload, so it goes with it.
contents: read is all the remaining jobs need.
The hardcoded-secret scan flags any 64-hex 0x value in JSON as a possible
private key. The restored balance-test fixtures store public 32-byte
account IDs under "account" fields - public data by definition, tripping
the scan as a false positive. Scope the exclusion to the exact field name
rather than loosening the pattern itself.
The live Play Store release (wallet-android 85bde7e, published 2026-06-15)
was built against whatever was on this branch's HEAD at the time - which,
since master had received no commits between 2026-03-02 and this week, was
commit 7a087cf. This week's changes (nova-base sync, Tron config/icons,
balance test fixtures, etc.) are real and wanted, but they've made master
incompatible with that still-live app version, and live users installing
fresh right now get a completely empty tokens list because of it (the app's
chain sync silently fails whole-hog on any single malformed/incompatible
chain entry, leaving new installs with zero locally-cached chains).
This makes master's served content match 7a087cf exactly, stopping the
bleeding for current live users without needing an emergency app release.
None of this week's work is lost - it's all preserved on
pending/post-fix-release and will come back once wallet-android's Tron
send feature is complete and both repos can ship together in one
coordinated release.
master is where real development happens and gets pushed to directly
(main is the auto-synced mirror) - branch protection was just added to
master requiring these exact check contexts, but the workflows only
fired for PRs/pushes targeting main, so the required checks could never
actually run for a master PR, permanently blocking every future merge.
Every account_overrides.json/chains_for_testBalance.json entry has a
32-byte hex "account" field - a public AccountId32 (Substrate's public
account identifier), not a private key. The two share the same byte
length/hex format, but are fundamentally different: one is meant to be
public (it's literally how you address a chain account), the other
must stay secret. The scanner's regex can't tell them apart and flags
every single one, which just triggered a false "Possible private key
found" failure on PR #33 (the master->main sync).
This isn't a one-off - it'll fire on every future sync PR too, since
chains_for_testBalance.json always has these fields. Left as "FAILURE"
long-term, it trains reviewers to ignore this specific check, which is
exactly the alarm-fatigue failure mode that would let a real leaked
secret slip through unnoticed.
SatoshiQaziMuhammed