Repository navigation
Generate test credentials at run time - #30
Merged
Merged
Conversation
GitGuardian raised 28 incidents across laranail by 2026-10-18, 27 of them literal test credentials or false positives, each closed by hand. A provider secret spelled out in a test reads exactly like a leaked one. Every provider secret the suite configured is now generated by TestCredentials. The redaction tests hunt for the same generated value they configured, and the database-over-config test asserts its two secrets differ, since that is what proves the row won. A guard fails on any literal added later. package-tools 0.1.9 is the first release with TestCredentials and the guard, so the floor moves to ^0.1.9.
GitGuardian reads a compound purpose, two words joined by a hyphen, as the password itself, which turns a generated credential back into a reported one. package-tools 0.1.10 ships assertCredentialPurposesAreWordsIn(), so the floor moves to ^0.1.10 and the credential guard gains a second test that keeps every purpose a single plain lowercase word. No purpose in this suite needed renaming, and every remaining exemption marker is still required by the 0.1.10 scanner.
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.
Why
GitGuardian raised 28 incidents across laranail by 2026-10-18. 27 were literal test credentials or false positives, and each was closed by hand. A provider secret spelled out in a test reads exactly like a leaked one.
What changed
CredentialLiterals→ 0, 13 replaced, 0 exempted. Every provider secret the suite configured is nowTestCredentials::secret('<purpose>'). Two positional database secrets inCredentialResolutionTest(not flagged by the scanner) were converted too, so the file is consistent.AdapterContractTestputs the generated secret in the simulated connection error and asserts the result does not contain it;CommandsTest's "never prints a secret" hunts for the same generated value it configured.tests/Arch/NoLiteralCredentialsTest.php(the repo's existing architecture directory, already a test suite inphpunit.xml.dist),minFiles: 24(27 files scanned).laranail/package-toolsfloor raised to^0.1.9, the first release withTestCredentialsand the guard (laranail rule 3).[Unreleased]→### Changed.Verification (local, PHP 8.4)
laranail-pint --test: passed.'secret' => '…'appended toWidgetTest.phpturned the guard red, naming the file and line; reverted withgit checkout.Follow-up: package-tools 0.1.10
laranail/package-toolsfloor raised to^0.1.10.NoLiteralCredentialsTestgains a second test,assertCredentialPurposesAreWordsIn()(same dir,minFiles: 24).TestCredentials::password()call with a hyphenated purpose turned the new test red; the file was restored and nothing of it is committed.