Read the deployment key instead of writing it into the command - #148
Conversation
The documented invocation prefixed `DEPLOYMENT_KEY=0x...` to the command, which puts a private key with real money behind it into the shell's history file, where it outlives the run and the terminal. This is the only place in the repo that documents a key on a command line at all — the deploy reaches its key through a workflow secret — so it was also the only place that could teach the habit. `read -rs` takes the key off the terminal without echoing it and without a history entry carrying its value. Same variable, same script, nothing about the mechanism changes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 45 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Follow-up to #147, which merged while this was being written, so the fix missed
the merge by about a minute rather than being left out on purpose.
CodeRabbit's merge-risk note on #147 was right: the invocation that PR
documented prefixed
DEPLOYMENT_KEY=0x...to the command, which writes aprivate key with real money behind it into the shell's history file, where it
outlives both the run and the terminal.
maincurrently carries thatinstruction in the README and in the
CreditHyperCoreNatSpec.It is the only place in the repo that documents a key on a command line at all
— the deploy reaches its key through a workflow secret and never spells one out
— so it is also the only place that could teach the habit.
read -rstakes the key off the terminal without echoing it and without ahistory entry carrying its value:
Same variable, same script, same env read in
run(). Nothing about themechanism changes and no Solidity outside a comment is touched.
QA
block that mirrors it. There is no behaviour here to discriminate on: the
compiled artifact is byte-identical, because the only
.solchange is insidea
///comment. A test asserting the text of a comment would pin the mirrorrather than the source, which is the failure mode section 4 of the QA guide
names.
library this documents was mutation-tested in Credit the deployer's HyperCore account from HyperEVM #147 (13 mutants, 12 killed, M10
disclosed as surviving and unreachable), and this diff does not touch it.
VAR=value cmdprefix is part of the command line and lands in
HISTFILEunder default bashand zsh settings;
read -rsassigns without echoing and without putting thevalue in the history entry. Verified against
mainthat the pattern beingreplaced is the only one of its kind in the repo:
grep -rn 'DEPLOYMENT_KEY='finds it inREADME.mdandscript/CreditHyperCore.soland nowhere else.places the command is written out, not just the README it was raised against.
Deliberately not covered: how the key gets onto the machine in the first
place, and any change to
run()or its env reads, both of which aremechanism rather than documentation and neither of which the finding is
about.
forge fmt --checkclean andLibHyperCoreTest13/13 locally on this tree.