Bcrypt Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. use-the-stdlib for password hashing. The package's entire job — creating and verifying bcrypt hashes inside a Symfony service container — is already covered by PHP's password_hash() / password_verify() (PHP 5.5+) and by every modern framework's first-party hasher. The decision this supports is largely a negative one: do not add a dependency for a language primitive.
• Legacy stack disposition (keep / contain / migrate). A "Symfony2-context" bundle is evidence of an application on Symfony 2.x, EOL since 2018. Finding it in a dependency tree is an inventory signal — this app needs a modernization line item, not feature investment.
• Framework strategy and platform standardization. The framing of this request (a "Laravel package") doesn't match the artifact: it's a Symfony2 bundle and has no place in a Laravel app, where Hash::make() / Hash::check() is first-party. The decision input is to standardize hashing at the platform layer so teams stop reaching for framework-specific micro-bundles.
• Credential migration roadmap. If hashes were produced through this bundle, the product decision is a rehash-on-login path to argon2id (or bcrypt at a defined cost) using native hashers, with a sunset date for the legacy format.
• Feature scoping. There is no user-facing capability here and no differentiator. It should never appear on a roadmap as a feature enabler; at most it appears as a risk / technical-debt line item.

When to Consider This Package

Consider it only in narrow, defensive situations:

• You are maintaining an existing Symfony 2.x application that already depends on it and must preserve behavior during a freeze — not while adding capability.
• You must verify hashes this bundle wrote (custom cost/prefix or encoding conventions) and need compatibility during a migration window.
• A hard constraint keeps you on Symfony2 for a defined period and an interim fix beats a rewrite.

Look elsewhere — or more likely use nothing — when:

• You're on Laravel or any modern PHP framework. Use the built-in hasher; there is no reason to pull in a Symfony2 bundle.
• You're on Symfony 3.4+. Use the native password hashers in symfony/security-bundle.
• Maintenance and security posture matter. Zero stars, zero dependents, zero score means no community review, no CVE watch, no upgrade path. For a security-critical primitive, that is a bad trade against an audited stdlib function.
• You need modern algorithm choice — argon2id, tunable cost, rehash-on-verify. A bcrypt-only, Symfony2-era bundle won't offer the upgrade affordances current guidance expects.
• You need supply-chain assurance — SBOM inclusion, verifiable licensing, or vendor support.

Baseline criteria before any adoption: the EOL framework dependency is explicitly accepted and time-boxed, a named owner exists for security patches, hash-format compatibility with the stdlib is documented, and there is a written exit plan.

How to Pitch It (Stakeholders)

For executives: This is a small, unmaintained Symfony 2 plugin that wraps bcrypt password hashing — a capability PHP has shipped natively since 2015 and that both Symfony and Laravel now provide out of the box. It has no adoption, no dependents, and sits on a framework that stopped receiving security patches in 2018. My recommendation is not to adopt it: it adds supply-chain and maintenance risk in exchange for zero product capability. Its presence in our codebase should be read as a signal that an application needs a modernization and credential-migration plan.

For engineering:

• Don't add it. password_hash(PASSWORD_BCRYPT) or the framework's hasher does the job, is maintained by the people who own PHP security, and removes a dependency.
• If it's already in a legacy app: freeze, don't extend. Inventory where hashes are written and read, confirm compatibility with password_verify(), then move to rehash-on-login with argon2id (or bcrypt at cost ≥ 10 where argon2 isn't available), and delete the bundle once the last legacy hash is rotated.
• Treat any new service that "needs" it as a signal the service is being built on an EOL stack — not a reason to vendor this in.

Ask: approval to (1) reject adoption, (2) log the bundle's presence as technical debt with an owner and target date, and (3) standardize on the platform-native hasher so this question doesn't recur per team.