Encryptor Bundle Laravel Package

Product Decisions This Supports

• At-rest encryption scope: deciding whether to encrypt individual fields (PII, tokens, API credentials, small config blobs) in the application layer, versus relying on database/disk/KMS-level encryption. This bundle only addresses the former.
• Build vs. buy vs. wire-up: it clarifies that "adoption" here means wiring an existing crypto primitive into Symfony's DI container — a ~50-line service class and one YAML/PHP service definition. That reframes the buy decision as a trivial build.
• Symfony upgrade roadmap: any evaluation of this bundle is a forcing function for asking "what Symfony and PHP versions are we targeting?" A 2017-era bundle is a blocker for Symfony 5.4+/6/7 and PHP 8.1+ plans.
• Security-review gate: whether we require maintained, audited crypto dependencies for anything touching customer data — this package fails that test, which is itself a useful precedent to set.
• Use cases it nominally serves: encrypting session/token payloads, encrypting specific columns before persistence, obfuscating non-secret identifiers. It does not serve key management, key rotation, envelope encryption, FIPS compliance, or full-database encryption.

When to Consider This Package

Adopt only under a narrow set of conditions:

• You are maintaining a legacy Symfony 2.x/3.x or PHP 7.x application with no near-term upgrade path.
• You are already using nmure/encryptor as a library and simply want the container wiring done for you.
• The need is genuinely small and internal (a config value, a token format), not customer-facing or regulated data.
• You accept that you own the code from day one: 2 stars, 0 dependents, and a last release of December 2017 mean effectively no community, no security response, and no compatibility guarantees.

Look elsewhere when:

• You are on Symfony 5.4+/6/7 or PHP 8+ — bundle conventions, autowiring, return types, and deprecations have all moved on.
• You need active maintenance, CVE response, or an audit trail (PCI-DSS, HIPAA, SOC 2, GDPR-driven encryption requirements).
• You need key rotation, envelope encryption, or HSM/KMS integration — use AWS KMS, GCP KMS, HashiCorp Vault, or Symfony's Secrets Vault.
• You want a maintained application-layer crypto library instead: defuse/php-encryption, paragonie/halide, or PHP's built-in sodium_crypto_secretbox. In most cases, registering one of these as a service yourself is less work than adopting an abandoned bundle.

How to Pitch It (Stakeholders)

For executives: This is a low-leverage, effectively unmaintained dependency. It wraps a small encryption utility for Symfony's container — useful convenience, no strategic value, and zero ecosystem support since 2017. Do not let it into customer-facing or regulated systems. The cost of replacing it is measured in hours, not sprints, so the real risk is inertia, not migration.

For engineering: It's thin glue: a service definition plus a factory around nmure/encryptor, which is itself a compact AES + HMAC helper. It will not survive a Symfony 6/7 upgrade without work. Recommendation: decline adoption; spend half a day writing an EncryptorInterface + OpenSslEncryptor/SodiumEncryptor service with a single services.yaml entry, or adopt defuse/php-encryption. Either path gives us a maintained, testable, upgrade-safe dependency and keeps the crypto decision in our own hands rather than in a two-star repository last touched seven years ago.