Encryption Bundle Laravel Package

Technical Evaluation

Headline finding (unchanged by v2.1.0): this is not a Laravel package. helppc/encryption-bundle is a Symfony bundle built around Symfony's DI extension, configuration tree, and container compilation phase. Laravel's container has no compile step, so the package's single most valuable property — a misconfigured encryption group failing the build rather than at runtime — does not exist in a Laravel application without us reimplementing it. Any plan that says "composer require and go" is wrong and should be rejected in review. v2.1.0 reinforces this: the release is entirely a widening of Symfony major-version support (7.4 LTS and 8.x), with no movement toward framework-agnostic container support.

Architecture fit. The good news is that the framework-agnostic part is the part that matters. spaze/encryption carries no framework coupling; the bundle is a thin typed facade plus configuration plumbing. That means a Laravel integration is feasible: adopt spaze/encryption directly, port the configuration schema (named encryption groups), and rebuild the compile-time guarantee as an explicit validation step in a service provider or in a config:cache / deploy hook. The narrow interfaces described by the maintainer are the right shape for this — narrow contracts are what make an adapter cheap.

Integration feasibility. Medium. Work items are small but non-trivial: a service provider to translate config/encryption.php into configured group instances, a boot-time validator that fails fast and loudly, an Eloquent cast or attribute for column-level use, and a rotation command modelled on GenerateEncryptionKeyCommand (libsodium random_bytes / sodium_crypto_box_keypair). None of this is research; it is genuine implementation and ongoing ownership. v2.1.0 does not reduce any of this work.

New in v2.1.0 — what it does and does not change.

• Scope: every Symfony requirement is now ^7.4 || ^8.0. src/ is byte-identical to 2.0.0. This is a constraints + CI release, not a capability release.
• Signal for us: the maintainer is investing in the Symfony coupling, not abstracting away from it. Treat "Symfony-only by design" as a settled fact rather than a gap that may close. Any plan that waits for first-class Laravel support is a plan that will not ship.
• Second-order technical evidence: the test fix reveals the DI extension reads kernel.environment and kernel.build_dir off the container. Those are Symfony kernel parameters with no Laravel analogue. This is concrete confirmation — beyond inference from the package type — that the configuration layer is bound to kernel semantics we would have to fabricate.
• Maturity: the release shows a real gate (PHPUnit, PHPStan level 10, PHPCS, Rector, composer validate --strict) running green across three pinned stacks, with Flex used to prevent transitive float between majors. That is better engineering hygiene than one star implies, and worth crediting — but hygiene is not adoption, and it does not change the ownership calculus.

Technical risk.

• PHP floor of >= 8.4. This is a hard constraint, and v2.1.0 does not relax it (it adds Symfony versions on the same two supported PHP versions). Most Laravel estates today run 8.2/8.3. Adopting this code forces a runtime upgrade across the fleet, or a fork that relaxes the constraint. That is a platform decision, not a library decision.
• Maturity and bus factor. One star, zero dependents, single maintainer, MIT. v2.1.0 improves the maintenance signal but not the bus factor. Treat it as source we intend to own, not a dependency we consume.
• Fork drift. The AGENTS notes reveal the same org publishes both a helppc/encryption fork (with extra contracts and a marker exception interface) and this bundle, which is explicitly forbidden from depending on the fork's additions. Two near-identical crypto packages in one org's namespace is a Composer resolution hazard and a long-term confusion hazard. Unchanged by this release.
• Release date anomaly. The stated last release (2026-08-17) postdates the assessment date; verify the tag actually exists and matches the default branch before planning around it. The v2.1.0 changelog URL is a good place to start that check.
• Rotation semantics remain unspecified in the public material. "Key rotation" can mean two very different things: adding a key so old ciphertext decrypts under a keyring while new writes use the new key, or actively re-encrypting stored data. The second is a data migration with a much larger blast radius. v2.1.0 does not address this.
• Symfony version sprawl is now our problem too, indirectly. Supporting 7.4 and 8.x means the reference implementation carries compatibility branches we must read past when porting configuration behaviour. Minor, but it adds noise to the "use the bundle as a spec" exercise.

Key questions to put to the maintainer (or answer ourselves before committing).

1. Does key rotation re-encrypt existing ciphertext, or only extend the decrypt keyring? Who orchestrates re-encryption of persisted rows?
2. Where is key material expected to live — filesystem, env var, secret manager, KMS? Is envelope encryption supported?
3. Which cipher and mode does spaze/encryption use, and is nonce/IV handling entirely internal? (The "never write a primitive" rule is correct and should be preserved verbatim in any fork.)
4. Is there any Laravel adapter, or is support for non-Symfony containers out of scope? (The 7.4/8.x-only v2.1.0 suggests the latter — get it stated.)
5. What is the support window and PHP version policy — will 8.4 remain a hard floor, and is Symfony 9 already on the roadmap?

Integration Approach

Stack fit. Do not install the bundle in a Laravel app. The correct shape is: depend on spaze/encryption for the crypto, adopt this bundle's configuration-group model and interface design as the reference specification, and write the Laravel wiring ourselves. The bundle functions as a well-reasoned design document plus a source of battle-tested defaults, not as a runtime dependency. v2.1.0 strengthens this reading: the project is deliberately tracking Symfony majors, so its centre of gravity is moving away from, not toward, framework neutrality. If an engineering team insists on the bundle, require them to demonstrate it booting outside a Symfony kernel first — and note that as of v2.1.0 the extension requires kernel-provided container parameters even in tests.

Migration path.

1. Inventory and classify. Identify which columns, files, and payloads actually need encryption, and which need searchable or sortable access (those constrain the design early). Do this before any code.
2. Key custody decision. Pick the key store and the envelope strategy. This is irreversible in practice — changing it later is a re-encryption project.
3. Pilot behind an interface. Introduce a single application-level Encryptor contract with one group, one non-critical data set. Bind it in a service provider. No framework coupling leaks into domain code.
4. Port configuration and fail-fast validation. Replicate the named-group config schema; add a validator that runs at boot and in CI so a missing or malformed group fails the build, recovering the bundle's headline property.
5. Add ergonomics. Eloquent cast for column-level fields; a rotate/generate artisan command wrapping the libsodium keygen pattern.
6. Rotation runbook and rollout. Only after the above is stable in one service.

Compatibility. Verify the Laravel version matrix against the PHP 8.4 floor. The new ^7.4 || ^8.0 Symfony constraints are irrelevant to a Laravel runtime only if we never install the bundle — if any transitive path pulls it in, we inherit two Symfony majors of constraint surface for no benefit. Pin spaze/encryption explicitly and add a Composer conflict or explicit rejection of both the bundle and the helppc/encryption fork so no one accidentally resolves to divergent contracts. Consider mirroring the maintainer's Flex-style single-major pinning discipline in our own CI matrix, since it is the one practice from this release directly portable to us.

Sequencing. Custody and data classification gate everything. Do not start with the library. A team that begins by installing the package will end up retrofitting a key management story around already-encrypted data — the worst possible order. v2.1.0 changes nothing here: it is a compatibility release, and there is no new capability that alters our build order.

Operational Impact

Maintenance. Assume ownership. One star and zero dependents means we will be the largest consumer of this code and its de facto maintainer. Budget for a named owner, a vendored or forked copy, and quarterly review against upstream spaze/encryption. The MIT license makes forking clean; the AGENTS.md rules (no hand-rolled primitives, strict_types, PHPStan level 10, all crypto through upstream) are good governance and should be carried into any fork verbatim. v2.1.0 is a positive maintenance datapoint — a real, green, multi-stack quality gate and disciplined CI — and that rigor is worth copying even though the code is not.

Support. There is no community to escalate to. Support burden falls on our own team, plus tracking spaze/encryption and libsodium for security advisories. Require an SBOM entry and a documented CVE-watch process, because encryption libraries are exactly where "low adoption" and "high consequence" intersect badly. Note that the bundle's expanding Symfony matrix means more upstream surface to watch over time, even for a component we do not install.

Scaling. AEAD per-field encryption is CPU-bound and fast enough for typical record volume; throughput becomes a concern only for bulk reads of large result sets or full-table scans. Key rotation does not scale gracefully if it means re-encrypting a large table — plan a batched, resumable, idempotent migration with the old key retained in the keyring for the entire window. Envelope encryption (data keys wrapped by a KMS master key) is the design that keeps rotation cheap, and it should be a strong preference in step 2 above.

Failure modes to design against explicitly.

• Lost or rotated-away key → permanent, unrecoverable data loss. There is no support ticket that fixes this. Keyring retention must outlive the longest-lived ciphertext, and deletion needs a deliberate, logged ceremony.
• Boot-time validation gap → in Laravel, the bundle's compile-time guarantee becomes a runtime explosion. If validation is missing, a bad config surfaces in production requests rather than in CI. This is the single most likely way this integration goes wrong; enforce it in the pipeline.
• Partial rotation → mixed key generations in one table, with reads succeeding on some rows and throwing on others. Requires per-row key identifier and idempotent re-encryption.
• Accidental nonce reuse or a hand-rolled tweak → silent, total loss of confidentiality. The "no primitive writing" rule must be a lint-enforced review gate, not a convention.
• Silent dependency pull-in → if the bundle or the sibling fork resolves into our tree during a routine composer update, we inherit Symfony container coupling and divergent contracts without anyone choosing them. Lock this down with explicit conflict entries.

Ramp-up. Low for consumption, high for ownership. The typed facade and narrow interfaces mean application developers learn the API in an afternoon. The team that owns key custody and rotation needs real cryptographic literacy, and that is a hiring or consulting decision, not a training-video decision.

Overall recommendation (unchanged). The design instincts here — narrow interfaces, configuration-driven groups, fail-fast on misconfiguration, no bespoke crypto — are better than the project's adoption numbers suggest. v2.1.0 is a competent, honest, zero-risk compatibility release that improves our read on the maintainer's discipline and confirms the bundle's Symfony-only trajectory, but it does not alter the core calculus: the package as shipped cannot be dropped into a Laravel application, its PHP 8.4 floor is a platform-level commitment, and its single-maintainer status means we inherit the codebase. Proceed only as a design-informed internal build on top of spaze/encryption, scoped to a pilot with a named owner and a key-custody decision made first. Treat the bundle itself — at any 2.x version — as reference material, not a dependency.