Sodium Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy (still lands on "build trivial, skip the buy"): v1.0.3 contains no functional changes — CI PHP bump, PHPUnit/PHPStan config migration, Symfony 7.0 compatibility fixes, dependency updates. The package remains a thin DI wrapper around PHP's native sodium_* functions, not a cryptographic implementation. The build-vs-buy math is unchanged: the encryption capability comes from the PHP runtime we already ship.
• Compliance and data-protection roadmap: Still a useful comparison point for any PII-encryption-at-rest, GDPR/CCPA, or PCI-scope-reduction evaluation — it answers "what would a Sodium-based field encryption layer look like?" not "should we ship one?" The release adds nothing to that answer.
• Key management and crypto-agility posture: The model is unchanged — single symmetric key via Sodium secretbox, injected through Symfony config, no rotation, no per-tenant keys, no asymmetric recipients. Any of those requirements still outgrow the package immediately.
• Dependency hygiene policy — refined signal: The release is a good corrective to a one-shot "archived, therefore dead" judgment. It shows low-but-nonzero maintenance activity (chore-only, no security review, no feature work). The durable policy takeaway is to track dependency health signals — release cadence, whether releases are functional or chore-only, presence of a security policy, maintainer count, dependent count — rather than recording a single archived/alive snapshot at evaluation time.
• Deprioritization of a "custom crypto" workstream: Unchanged. Laravel's Crypt facade already provides authenticated encryption with key rotation via APP_PREVIOUS_KEYS; a bespoke Sodium layer remains a solution in search of a problem for our stack.

When to Consider This Package

Adoption criteria (all would need to hold):

• The application is a Symfony application, not Laravel. v1.0.3 explicitly targets Symfony ^6.0 | ^7.0; the bundle machinery is still unconsumable from Laravel, and a hand-written service provider would import the dependency while discarding the only thing that makes it a bundle.
• The team genuinely wants Sodium secretbox specifically (portability constraint, or an existing ciphertext format to remain compatible with).
• The requirement is a single symmetric key with no rotation, no per-tenant isolation, and no multi-recipient needs.
• The team accepts permanent ownership of the code. The 1.0.3 release is maintenance hygiene, not evidence of a security-response process — no advisory history, no stated disclosure policy, single maintainer. Assume we patch it.

Look elsewhere when:

• You are on Laravel — use Crypt::encryptString() / the encrypted Eloquent cast. Zero new dependencies, framework-native key rotation, well-trodden.
• Sodium primitives are what you actually want — call sodium_crypto_secretbox() or sodium_crypto_aead_xchacha20poly1305_ietf() directly. The Sodium extension ships with PHP 7.2+.
• You are below PHP 8.2 — v1.0.3 raises the minimum to PHP 8.2, so this release is a hard compatibility break for any 8.1 host. Note this cuts both ways: it is a forward-compatibility signal for modern Symfony shops and a non-starter for older fleets.
• You need more than secretbox — asymmetric sealing (sodium_crypto_box_seal), password hashing/KDF (sodium_crypto_pwhash), or a maintained higher-level library such as paragonie/halite (Symfony-friendly, versioned ciphertext, key rotation) or defuse/php-encryption.
• Any compliance regime applies — SOC 2, ISO 27001, or a security questionnaire will still flag a single-maintainer, low-adoption dependency in the encryption path. A chore release does not change that finding; it only changes the wording from "unmaintained" to "minimally maintained."
• Any team other than the original authors' one — 1 star and 0 dependents means no community to catch a regression, and no signal the API has been exercised outside its author's use case.

How to Pitch It (Stakeholders)

To executives: Recommendation stands — do not adopt. The v1.0.3 release is housekeeping (PHP 8.2 floor, Symfony 7 compatibility, test/CI config) with no new capability. The package is still a single-maintainer Symfony wrapper around encryption functions that ship inside PHP, contributing on the order of tens of lines of dependency-injection glue. Adoption would transfer indefinite maintenance and patching responsibility to us for near-zero saved effort. Laravel's built-in encryption or direct Sodium calls deliver the same capability with no new supply-chain surface. One nuance worth stating plainly: the dependency is not abandoned, it is minimally maintained — which for an encryption-path dependency is the same practical answer.

To engineering: Nothing in 1.0.3 changes the integration story. It is Symfony-shaped and Symfony-versioned; wiring it into Laravel means importing the package and bypassing the bundle. The version bump also raises our minimum PHP to 8.2, which is a real constraint if anything in the fleet is still on 8.1. Implement natively: sodium_crypto_secretbox is a two-function call, and a Laravel service provider around it can be written with the key rotation and ciphertext versioning we actually need — which this package still does not offer.

Cost/risk framing: Roughly 1–2 engineer-days to implement natively and correctly, versus a minimally maintained dependency in the encryption path for the life of the product. The 1.0.3 release does not reduce that risk; it only defers the question.

Recommendation: Reject for adoption — unchanged. Record the evaluation as a completed build-vs-buy exercise. If a Sodium-based requirement appears later, evaluate paragonie/halite or a first-party implementation, not this bundle. Re-check this package only if it gains a security policy, multiple maintainers, or functional (not chore-only) releases.