Array Redactor Laravel Package

Technical Evaluation

Architecture fit. mtownsend/array-redactor remains a single-responsibility utility: given an associative array and a list of keys, it returns a copy with matching values replaced by a redaction token. The Laravel layer is still an optional service provider and facade. What changes with 1.0.1 is that the transform is no longer a pure data operation — callback support in the redaction method means arbitrary user-supplied code now executes inside the log/audit path. Architecturally it is still a cross-cutting concern with no I/O, no persistence, and no state of its own, and still trivially composable at logging middleware, Monolog processors, exception handlers, HTTP client taps, and audit writers. The shift is that determinism and testability now depend on callback discipline rather than on the library: a pure array transform plus a reviewer-approved callback is fine; a callback that queries a database, calls a service, or does regex detection turns a 50-line utility into an opaque, side-effecting step in the hot path. The implicit contract about which keys carry sensitive data still exists and will still drift.

Integration feasibility. Still a one-line composer require plus auto-discovery in Laravel, still no meaningful transitive dependencies. The new fact is that 1.0.1 exists — which is also the confusing fact. Our prior read had the last release in 2019; a 1.0.1 implies a 1.0.0 line that we have not assessed, so the release history between 2019 and now is unexamined. Pin to exactly 1.0.1 (not ^1.0) until we have read the diff from the 2019 tag. Two feasibility questions now gate install: (a) does 1.0.x widen the php constraint to our PHP matrix, and (b) what is the callback's signature and failure contract. Both are still a half-day spike, not a project.

Technical risk. Re-ranked:

1. Silent under-redaction (still highest). Key-based redaction is a deny-list. Renamed, re-cased, or unexpectedly-nested fields pass through unredacted and nothing throws. Callbacks do not fix this — the callback only fires for keys you already matched, so the miss happens upstream of any new flexibility.
2. Callback leakage and callback failure (new, closely coupled to #1). A callback that returns the original value, returns null, or throws converts a redaction step into either a leak, a blank field, or a broken logger. A callback that receives the raw value and logs, traces, or serializes it in a debug path defeats the entire purpose. This is a new attack surface and a new code-review obligation, and it sits inside the path that handles the most sensitive data we have.
3. False assurance (unchanged, arguably worsened). Stakeholders may read callback support as "we can detect PII now." It still does not detect PII, scan values, or understand patterns — it gives you a place to write detection, which is a very different claim and a much larger maintenance burden if anyone actually does it.
4. Abandonment (downgraded, not resolved). A patch release after a multi-year gap moves this from "abandoned" to "sporadic." That is not a support commitment, not a disclosure process, and not a second maintainer. Zero dependents still means no community CVE watch — we are the monitor.
5. Provenance / ownership. A release appearing after years of dormancy on a low-traffic package is a supply-chain question, not just a feature question. We need to know who published 1.0.0 and 1.0.1, whether the repository changed hands, and whether the 2019 code is even the same code. This is now a prerequisite, not a nice-to-have.
6. Low community validation (unchanged). ~145 stars, 0 dependents. The new callback path has effectively no battle-testing at all.
7. Behavioral ambiguity (partially reduced, partially relocated). The replacement token is now configurable per-case via callback, which answers part of our earlier question. In exchange, the callback's argument list, invocation frequency, return contract, and error behavior are unspecified in the notes and must be read from source.

Key questions.

• What is the callback signature — does it receive value, key, key path, and the full array? Is it invoked per matched leaf, per matched key, or once per payload?
• Is the return value used verbatim? What happens on null, false, a non-string return, or a thrown exception — swallowed, propagated, or does the original value survive?
• Does the callback fire for nested matches, and does it compose with (or replace) whatever recursion behavior already exists?
• Terminology check: the release note refers to "the ink method." Our prior read assumed the entry point was redact. Confirm the actual public API surface and whether 1.0.0 renamed anything — a rename is a breaking change we have not accounted for.
• What is the version-to-version diff between the 2019 release and 1.0.1, and did the php constraint, namespace, or Laravel provider change?
• Who published 1.0.0/1.0.1, and has the repository or Packagist ownership changed since 2019?
• Can callbacks be closures only, or also callable strings/arrays? If closures, are they safe with config:cache, queued jobs, and anything that serializes configuration?
• Is there still no allowlist inversion — i.e. can we redact everything except known-safe keys, with callbacks as the fallback for unknown shapes?
• Who owns the fork, and what is our patch SLA for a security-adjacent dependency that has just demonstrated it can ship code into our logging path?

Integration Approach

Stack fit. Standalone PHP with an optional Laravel provider; fits Laravel 8–11 if the constraint is forked or already widened in 1.0.x. Still a natural fit for our logging pipeline and any place we serialize payloads for human review. Callbacks make it a plausible host for value-level masking (a token format, an account-number pattern), but hosting detection logic inside a logging dependency is a deliberate trade: it removes a dependency and adds bespoke security code we own. Default position: use callbacks for token shaping and formatting only, not for detection.

Migration path. Unchanged and now more valuable: never call the facade or the library's method directly from application code. Keep the narrow internal boundary — Redactor::redact(array $payload, array $keys): array — and treat callbacks as an implementation detail behind it. That boundary is what converts sporadic upstream releases, API renames, and abandonment into a one-file swap, and it is what prevents callbacks from proliferating across call sites where nobody reviews them as security code. Golden-file tests must now cover both the token path and the callback path: nested positives, case variants, renamed-key negatives, callback-throws, and callback-returns-null.

Compatibility. Pin 1.0.1 exactly during evaluation, then move to a caret constraint only after reading the changelog and diff for the 1.0.0 line. Confirm the PHP constraint before anything else; if it blocks install, fork to acme/array-redactor rather than using --ignore-platform-reqs. Verify the Laravel provider still uses deferred binding and that config publishing remains optional. If we only need the core class, skip the provider — the facade buys us nothing and the callback feature is available without it.

Sequencing.

1. Provenance and diff review (2 hours, new first step). Confirm publisher, repository state, and read the diff from the 2019 tag to 1.0.1 end to end. If provenance is unclear, stop and fork before proceeding.
2. Spike (½ day). Install 1.0.1 pinned, run the suite on our PHP matrix, read the callback implementation, and document its exact signature, invocation count, and error behavior.
3. Boundary (1 day). Land the internal interface + adapter + golden-file tests behind a feature flag, including callback cases. Callbacks defined only inside the adapter.
4. Non-prod rollout (2–3 days). Staging logging and exception reporting only. Diff pre/post payloads, confirm every sensitive key is covered, and confirm a deliberately throwing callback cannot take down logging.
5. Production, read-only paths first. Audit/log sinks before request/response taps; add a sampled assertion that known-sensitive keys are present-and-redacted so drift alerts.
6. Decide (end of sprint). Fork-and-maintain vs. reimplement in-house vs. keep as-is with a documented exception. Callbacks slightly raise the value of keeping it and slightly raise the cost of owning it; the reimplementation option remains credible.

Operational Impact

Maintenance. Still near-zero churn on the core, but 1.0.1 adds a surface we must now track: the callback contract. If we use callbacks, we own that code as security code — reviewed, tested, and covered by the same drift assertions as the key list. The upstream release does not reduce our governance load (SBOM entry, named owner, unmaintained-fork note, periodic review); it adds a small amount of upgrade diligence and a provenance check. Budget roughly one engineer-day per year plus a one-time fork effort, and add half a day for the 1.0.0→1.0.1 diff review now.

Support. Unchanged: no vendor, no SLA, no security contact. A single patch release is not a support relationship, and we should not present it internally as "actively maintained." Support is us, and any callback we write is supported exclusively by us.

Scaling. The base transform is still O(n) and negligible against log I/O and JSON encoding. Callbacks add per-matched-value invocation cost, which is fine for string formatting and not fine for regex over long free-text fields, per-value service calls, or anything that touches a database — those turn a hot-path utility into a latency and failure amplifier. Bound payload size before redaction, keep callbacks O(1) and allocation-light, and never let a callback open a socket.

Failure modes.

• Silent pass-through on key mismatch, rename, case difference, or unexpected nesting — still the dominant risk, still mitigated only by drift assertions and a safe-key allowlist.
• Callback leak where a callback returns the original value, an empty value, or logs the raw input to a debug sink.
• Callback exception in the logging path — depending on the error contract, this either swallows the log record (blind spot during an incident) or propagates into application code (outage caused by logging).
• Callback as unowned detection logic — bespoke PII matching drifting inside a dependency nobody reviews.
• Serialization hazards if callbacks are closures held in configuration consumed by config:cache or queued/lazy log contexts.
• Partial redaction of objects and JsonSerializable payloads if only plain arrays are traversed — unaddressed by this release.
• Token bleed where the replacement string is indexed or aggregated downstream as a real value.
• Ordering hazard if another processor rehydrates or re-serializes the payload after redaction.
• Dependency rot / provenance surprise on a future PHP major or an unexpected upstream release we did not vet.

Ramp-up. Hours for the core API; the callback path adds a short but non-trivial onboarding item — engineers must understand that a callback is security code in a hot path, that it receives the raw value, and that its failure modes are silent. The real learning cost is still the key inventory: someone must own and review the list of sensitive fields and prove it matches the schemas actually flowing. Staff against the policy, not the package.

TPM recommendation. Use it, pinned to 1.0.1, behind our internal interface, on a fork we control, with the redaction key list as a reviewed configuration artifact. Add two conditions this release forces: (1) clear the provenance and 2019→1.0.1 diff review before the dependency lands anywhere near production, and (2) permit callbacks only inside our adapter, only for token shaping and formatting, and only under the same review bar as security code. Keep the written caveat that this is key-based redaction, not PII detection — callback support makes that caveat more important, not less, because it now looks like a detection hook.