Follow-up from #3351, as suggested in review.
#3351 keeps the exact text of a sensitive fill (--text-stdin, --record-as) out of responses and errors. Two places can still carry a changed form of that text, which no literal match catches:
- Error: the iOS runner's
TEXT_ENTRY_MISMATCH message quotes both sides: text entry read-back did not match: expected "…", observed "…" (RunnerTests+TypeExecution.swift:111). expected is the exact value and is now redacted. observed is what the field read back. Per the fill help this error covers dropped characters, so it can be the value with a character or two missing.
- Success: a fill that settles on a different value returns
verification: "unconfirmed" with requested, before and after (FillUnconfirmedVerification in packages/contracts/src/fill-evidence.ts). requested is the exact value, but after can be a formatted form of it, like the help's "00 062 91 77" for "000629177".
I found these by reading the code and have not reproduced them on a device, since that needs a field that alters its input.
A possible direction: for a sensitive fill, drop the read-back values instead of matching them. For example, keep the error code with a generic message, and replace before/after with the placeholder. Related: #3261 (the same value in native XCTest logs).
Follow-up from #3351, as suggested in review.
#3351 keeps the exact text of a sensitive fill (
--text-stdin,--record-as) out of responses and errors. Two places can still carry a changed form of that text, which no literal match catches:TEXT_ENTRY_MISMATCHmessage quotes both sides:text entry read-back did not match: expected "…", observed "…"(RunnerTests+TypeExecution.swift:111).expectedis the exact value and is now redacted.observedis what the field read back. Per thefillhelp this error covers dropped characters, so it can be the value with a character or two missing.verification: "unconfirmed"withrequested,beforeandafter(FillUnconfirmedVerificationinpackages/contracts/src/fill-evidence.ts).requestedis the exact value, butaftercan be a formatted form of it, like the help's"00 062 91 77"for"000629177".I found these by reading the code and have not reproduced them on a device, since that needs a field that alters its input.
A possible direction: for a sensitive fill, drop the read-back values instead of matching them. For example, keep the error code with a generic message, and replace
before/afterwith the placeholder. Related: #3261 (the same value in native XCTest logs).