test(config,deploy): map the secret field-name and raw StrKey rejection boundaries

[ridercoder4]

Summary

Two P0 security-sensitive issues, both pure test additions with no fixture or
network cost. Neither area had the coverage its risk profile implies.

SW-081 (#181) — the secret field-name guard was barely mapped

The guard is one regex (src/config/schema.ts):

/(?:secret|private[_-]?key|seed|mnemonic|password|passphrase|token)/i

The existing configuration-secret-reflection.test.ts covers fifteen names, but
they cluster into a few shapes and never vary casing or separator style across the
set. Two properties were therefore completely unpinned:

1. Casing is irrelevant. Nothing asserted that SECRET_KEY, SecretKey or
   sEcReTkEy are rejected — so dropping the /i flag would leave the suite green.
2. Separator style is inconsistent by design. Only private[_-]?key permits a
   separator inside the term; every other alternative matches on its head word
   alone. seed_phrase, api-token and refresh_token all match via seed /
   token, not via a separator rule.

41 recognised names now cover casing, separator style and scope prefixes, exercised
both through validateStellarForgeConfig directly and through the real
loadProjectConfig file path, each asserting the value is never reflected.

The second group is the more interesting half. Eight names look secret but are
not recognised by the regex, and are therefore refused as ordinary unsupported
fields rather than as secret material:

pass_phrase · pass-phrase · encryptionKey · encryption_key · signingKey
· signing-key · signing_key · hdAccountIndex

passphrase is the only multi-word alternative in the pattern and it tolerates no
separator; there is no alternative matching a bare key. All eight are still
refused before the config is usable — just via the generic path. That boundary is
now asserted explicitly, so widening the regex has to be a deliberate change rather
than a side effect of an edit.

The legitimate-field half of the acceptance criteria is covered too: all three
networks, five alias shapes and a fully populated config still validate, plus an
ordinary typo (nickname) still reports "unsupported field" rather than being
mislabelled as secret material.

SW-086 (#186) — where the raw-StrKey rule actually starts and stops

validateIdentityAlias is the single gate in front of both the deploy --source
and the config identity:

/^[GS][A-Z2-7]{55}$/        → reject
!/^[A-Za-z][A-Za-z0-9_-]{0,63}$/ → reject

The existing deploy-source-rejection.test.ts proves the rule fires with two
cases. It does not describe where the edge is — and the edge is asymmetric:

• a canonical 56-character G… / S… StrKey is rejected (5 shapes, including the
  full base32 alphabet and the digit range 2-7);
• a near-miss is accepted as an ordinary alias and forwarded to the Stellar
  CLI as an identity name.

The near-miss group is 12 cases: wrong length (55, 57), lowercased G/S,
mixed-case, muxed M, contract C, and tails carrying 0, 1, 8, - or _
— none of which are in the base32 alphabet.

No secret material is exposed by that group, because none of those values is a
valid Stellar seed, so the CLI simply fails to resolve them as an identity. But it
is a real asymmetry and worth knowing about, so it is asserted rather than left to
be discovered. I did not change the regex — that would be a behaviour change beyond
this issue's scope, and narrowing it could reject legitimate aliases. Flagging it
for a maintainer decision instead.

Also covered: 14 values refused by the alias rule rather than the StrKey rule, the
exact 64/65-character alias boundary, the error never reflecting any rejected
value, rejection happening before any subprocess is planned for both groups,
and network validation taking precedence over source validation.

Issue references

Closes #173

Closes #174

Closes #181

Closes #186

What this PR actually changes

Implemented in full — #181 (config-secret-field-name-variants.test.ts) and
#186 (deploy-strkey-rejection-matrix.test.ts).

Not implemented here, and why:

• SW-073 — Integrate generated API Service with stellarforge test #173 (SW-073) requires generating an API Service and running
  stellarforge test inside it. The generated project is a Node template, so the
  fixture needs node_modules installed before it has any npm test to run — I was
  asked not to install dependencies. Related behaviour (exit-code propagation,
  plan resolution) is covered directly in test(test): cover Cargo exit propagation and platform-correct plan resolution #267 by another contributor in this wave.
• SW-074 — Integrate generated Smart Contract test plan #174 (SW-074) is the Cargo equivalent. Generating the Smart Contract workspace
  is feasible, but executing cargo test in it needs to fetch crate dependencies
  from the network, and the issue's own acceptance criteria ask for no network.
  The plan-resolution half of it is covered in test(test): cover Cargo exit propagation and platform-correct plan resolution #267.

Both are the same fixture-boundary problem, and both would need a dependency
install to be meaningful — which is why I took the two P0 security issues instead.
They were the higher-risk gap and the only pair that needs nothing installed.

How this was verified

Every field name and StrKey value in this PR was checked against the actual
regexes in the source rather than by eye — including confirming that the eight
"unrecognised" config names genuinely do not match, and that all twelve near-miss
StrKeys genuinely are accepted. Two entries that would have been wrong
(passphrase, privateSecretKeyBase) were caught and corrected that way.

Not run

node_modules was not installed and the suite was not executed, per your
constraint. Worth one local run before merge. Everything here is pure regex
behaviour with no platform or subprocess dependency, so I expect it to pass as
written — but the it.each matrices are wide enough that a run is worth having.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 767272f0-e30b-4571-a8dc-bbeb285a66b1

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}