Crypto Bundle Laravel Package

Product Decisions This Supports

• Encryption-at-rest for sensitive fields — PII, payment metadata, API tokens, webhook signing secrets, OAuth refresh tokens. The package's actual job is narrow: make defuse/php-encryption injectable through Symfony's DI container and configurable (active key, legacy decrypt-only keys). v5.0.0 does not change that job; it only raises the platform floor.
• Build vs. buy for a crypto wrapper — the cryptographic work lives in defuse/php-encryption, an independently maintained library. This bundle is a thin configuration layer. v5.0.0 sharpens the answer: the wrapper now imposes a Symfony 8.x + PHP 8.5 constraint in exchange for ~30 lines of service wiring, which pushes the trade decisively toward "write the wiring ourselves."
• Compliance roadmap — SOC 2 / ISO 27001 / GDPR "encryption of personal data at rest" controls. A versioned, HMAC-authenticated ciphertext format is far easier to evidence to an auditor than a homegrown base64(openssl_encrypt(...)). Note that the evidence value lives in defuse/php-encryption, not in this bundle — so the compliance argument survives dropping the wrapper.
• Key rotation planning — bundles of this shape typically support a current key plus legacy decrypt-only keys, which turns rotation from a migration project into a config change. Still a roadmap item worth scoping early, and still achievable without the wrapper.
• Platform-fit and platform-version fit — this is now the dominant consideration. v5.0.0 requires Symfony 8.x and PHP 8.5, both bleeding-edge. For a Laravel product this was already the wrong artifact class (Illuminate\Encryption\Encrypter covers it, and Laravel's Symfony component constraints make a Symfony 8.x bundle an outright Composer conflict). For a Symfony product on 6.x/7.x LTS, v5.0.0 is not installable, so adoption means pinning to 4.x with no stated backport or security-fix policy.
• Dependency lifecycle risk on the roadmap — a major version bump that contains only a platform-floor change (no features, no fixes) is a maintenance signal: the package moves in lockstep with the vendor's own application upgrades, not with an external user base. That belongs in the dependency-review conversation, not the encryption conversation.

When to Consider This Package

Consider it when:

• The codebase is genuinely Symfony 8.x on PHP 8.5 (or you are already tracking that upgrade) and you want the encrypter wired via the container rather than instantiated ad hoc.
• The need is scoped: encrypt a handful of DB columns, tokens, or serialized payloads — not a full envelope-encryption architecture.
• You specifically want defuse/php-encryption's properties: authenticated ciphertext, a self-describing versioned format, explicit key separation, no nonce-reuse footguns.
• You need multi-key decrypt (rotation) with minimal code.
• You're willing to vendor or fork it — the surface area is small enough that pinning a copy is realistic, and v5.0.0's platform floor makes a pinned local copy more attractive than a Composer constraint.

Look elsewhere when:

• Laravel is the stack. Use Crypt::encryptString() or the encrypted cast. v5.0.0 widens the gap: requiring Symfony 8.x means this cannot coexist cleanly in a Laravel dependency graph at all.
• You are on Symfony 6.x/7.x or PHP 8.2–8.4. v5.0.0 is not installable. You would be on 4.x indefinitely, with no published support window — a poor place to sit for a security-relevant dependency.
• Upgrade cadence is set by your release train, not the vendor's. A breaking release whose sole content is a framework/PHP floor bump tells you the maintainer's primary consumer is their own platform. Budget for forced major upgrades on someone else's schedule.
• You need KMS/HSM-backed envelope encryption (AWS KMS, GCP KMS, Vault Transit). Local-key crypto won't satisfy key-custody requirements; use the cloud SDK or aws/aws-encryption-sdk.
• You need searchable, deterministic, or format-preserving encryption — this won't do it.
• Supportability outranks convenience. Signals remain thin and are now slightly worse: negligible stars and dependents, single-vendor maintenance (Gdbots/Triniti ecosystem), no evidence of third-party security review, and a major-version policy driven by the vendor's own framework upgrades. A recent release date is not the same as an actively maintained project.
• You need a community, a CVE response process, or a documented security posture to put in front of a customer's security team.

Default recommendation (unchanged, now stronger): read the bundle's config, copy the ~30-line service definition, and depend on defuse/php-encryption directly. v5.0.0 makes this the clear default for anyone not already on Symfony 8.x/PHP 8.5: you keep the crypto, you keep your current framework and PHP versions, you drop the transitive bundle risk, and you own the key-handling code your auditors will actually ask about.

How to Pitch It (Stakeholders)

To executives: This is a small Apache-2.0 Symfony bundle that wires a reputable encryption library into an application's config. Its new v5.0.0 release is a breaking change with no new functionality — it only requires Symfony 8.x and PHP 8.5. Practically, that means it is now usable only by teams already on the newest framework and language versions; everyone else must pin to the older 4.x line with no stated support window. It remains cheap to evaluate and cheap to remove, and should still not be presented as a compliance solution on its own — the strategic value sits in the underlying library, not this wrapper. Given negligible community adoption, single-vendor maintenance, and a release cadence tied to the vendor's own upgrades, treat it as a pattern to borrow rather than a dependency to standardize on. Effort either way is under a day; the new constraint is a reason to borrow, not a reason to block anything.

To engineering: The bundle contributes DI wiring and key configuration over defuse/php-encryption; v5.0.0 changes only the floor to Symfony 8.x and PHP 8.5. On Symfony 8.x with container-managed keys and rotation, it's a reasonable shortcut. On Symfony 6/7 or PHP 8.2–8.4 it is not installable, and on Laravel Encrypter already covers this — do not introduce a Symfony bundle there, and expect Composer conflicts if you try. For a security-relevant dependency, an unpublishable-on-your-platform major bump with no backport policy is a reason to vendor the ~30-line service definition rather than constrain against it. Either path, settle three things before code: key custody (env vars vs. secrets manager), the rotation story, and exactly which columns are encrypted. The wrapper shouldn't be allowed to mask those design questions, and the version bump shouldn't be allowed to force a framework upgrade on its schedule.