Propel1 User Bundle Laravel Package

Product Decisions This Supports

• Legacy triage, not adoption. This package is a Symfony 2-era bridge (friendsofsymfony/propel1-user-bundle) that plugs Propel 1.x persistence into FOSUserBundle. The only product decision it genuinely informs is "do we keep this running, and for how long?" — not "what do we standardize on for auth?" If it appears in a composer.json, that file is a map of inherited technical debt, not a candidate for new work.
• Build vs. buy collapses to retain vs. replace. There is no vendor to buy from (archived upstream, zero stars, zero dependents, no maintainer) and nothing to build on (no shared contracts with Laravel's guard/provider model, no forward version to upgrade to). The realistic option set is: freeze in place as-is, or fund a scoped migration. Any roadmap line item framed as "integrate/extend this bundle" should be rejected at intake.
• Modernization roadmap signal. Finding this dependency is a reliable proxy that the product is carrying two end-of-life layers (Propel 1.x ORM + FOSUserBundle) directly in the login and credential path. That justifies a named, time-boxed modernization epic with its own budget line, scoped against the user-facing surface that touches registration, authentication, profile, and password reset.
• Security/compliance risk classification. Auth and credential handling sit in the highest-sensitivity tier. An unmaintained bridge there is a standing audit finding for SOC 2 / ISO 27001 review. This supports explicitly excluding the legacy auth stack from new compliance commitments and pen-test remediation SLAs until it is migrated — not because it's exempt, but because it's unfixable as-is.
• Scope guard for feature requests. SSO/OIDC, MFA, passwordless, session-hardening, and any auth-adjacent roadmap item should be blocked on migration until proven otherwise. These are migration projects wearing a feature hat, and pricing them as features produces a systematically wrong estimate.
• Explicitly does not support: greenfield auth decisions, Laravel architecture choices, vendor selection, or "which package do we adopt for user management." For Laravel, the answer is framework-native (Fortify/Breeze/Jetstream) and this package is not in the consideration set at all.

When to Consider This Package

Consider it only when all of the following hold:

• You have inherited (not chosen) a Symfony 2.x/3.x application.
• That application already runs Propel 1.x as its ORM and FOSUserBundle for user management.
• There is a concrete near-term business reason the app must keep running unchanged — contractual commitment, pending divestiture, seasonal freeze, or a hard customer cutover date.
• You will pin the exact version, vendor the source into the repo, and treat it as frozen: no forks, no patches, no new features, no extensions.
• You have a named owner (individual or team) accountable for security patching on that code path, plus dependency-scanning and CVE-watching tooling that actually reaches it.

Look elsewhere in every other case:

• Any greenfield or actively developed product. Use framework-native auth — Symfony's current Security component on a supported Symfony version, or Laravel Fortify/Breeze. There is no scenario where introducing Propel 1 into a Laravel app is the lower-risk choice; the two stacks share no interfaces (Symfony UserProviderInterface / UserManagerInterface vs. Laravel's Authenticatable / UserProvider), and Propel's build-time propel-gen model generation has no analogue in Eloquent's migration-driven schema.
• Any app where you control the ORM choice. Switching to Doctrine just to reach a slightly less abandoned FOSUserBundle integration is not an upgrade — it's the same migration with extra steps.
• Any team without a named legacy-PHP owner. Unmaintained auth code without an accountable maintainer is an unbounded liability, and the hiring pool for Propel 1 + Symfony 2 experience is near zero with no transferable skills.
• Red flags that override the "consider it" case entirely: the app is internet-facing with real customer credentials; PHP 8.x compatibility is unverified (it almost certainly breaks — removed functions and deprecations-to-errors in the Propel 1 runtime cause a full auth outage, not a degraded path); or there's no dependency-scanning coverage. In those cases, freeze-and-migrate becomes urgent rather than tactical.
• If the actual request is "add auth to a Laravel app," this package is not a candidate and should not reach an evaluation queue.

How to Pitch It (Stakeholders)

To executives: This is not a package we should adopt — it's a marker of technical debt we should retire. Licensing is free (MIT), but the ownership cost is real and open-ended: it is archived upstream, has no maintainers, no downstream users, and receives no security patches, while sitting directly in the login and credential path. No new investment should flow to it. The decision on the table is a modest, time-boxed migration budget versus the alternative of carrying an unpatchable authentication layer indefinitely. Frame it as risk retirement, not platform modernization — that's both more accurate and easier to fund. Concretely: approve a one-week spike to confirm the app runs on a supported PHP version, then a scoped migration estimate for the auth surface only. That spend is cheap and is the prerequisite for any larger decision.

To engineering: Freeze it. Pin the version, vendor the source, and add a comment in composer.json explaining why it exists — so nobody mistakes it for a live dependency or assumes it's a safe place to add features. Do not fork, do not patch, do not build on top. Map the real dependency chain (composer.lock for the pinned Propel 1.x and FOSUserBundle versions, plus every generated Base* model class actually referenced) — the blast radius is almost always larger than the bundle itself. Then produce a migration estimate covering only the auth surface. The port-forward path is: reimplement the user manager/provider behind the target framework's native contract, run a one-time ETL out of the Propel schema, and preserve only semantics — username/email canonicalization, password-hash identification so credentials rehash on next login, and role mapping. Everything else is disposable. Sequence data ETL and rehash-on-login ahead of cutting over session/token issuance, and decommission the Propel schema only after a read-only shadow period. Treat any auth-adjacent roadmap request as blocked on this migration until proven otherwise.

One-line framing for both audiences: zero stars, zero dependents, archived upstream, sitting in the credential path — the only thing to decide is the migration date, not whether to adopt it.