Propel1 User Bundle Laravel Package

Technical Evaluation

Verdict: this is not a Laravel package, and a TPM should not treat the catalog's "Laravel/PHP" framing as an integration claim. friendsofsymfony/propel1-user-bundle is a Symfony bundle that supplies a Propel 1.x persistence backend for FOSUserBundle (user model, security user provider, manager/factory wiring). It is archived, has zero stars, zero dependents, and no maintainer. Its only defensible value to a TPM is as a signal in dependency inventory and a reference pattern for auth layering — not as an adopted dependency. The leveragable decision is "freeze-and-migrate vs. carry indefinitely," not "integrate."

Architecture fit — essentially zero against Laravel.

• Laravel has no bundle system. Symfony bundles register through a Bundle class plus a DI container extension; Laravel's service providers are not equivalent, and Laravel's HTTP kernel never executes Symfony bundle bootstrapping. There is no seam to hook into.
• Auth contracts don't match. Laravel's guard/provider model is keyed on Illuminate\Contracts\Auth\Authenticatable and Illuminate\Contracts\Auth\UserProvider. This package implements Symfony's UserProviderInterface and FOSUserBundle's UserManagerInterface. No shared interface, no adapter layer, no partial reuse.
• Data layer mismatch is total. Propel 1 generates model classes at build time from an XML schema via propel-gen; Laravel expects Eloquent models backed by migration-driven schema. Nothing transfers without a hand-written schema port plus an ETL.
• The one genuinely reusable artifact is the design idea: a user manager separated from a user provider, with centralized username/email canonicalization. Laravel already implements that natively. Reading the package costs less than porting it.

Integration feasibility. Not feasible as a dependency in any Laravel application, and only historically feasible in Symfony 2.3–2.8-era apps. A "port" is a rewrite in which no code survives: PHP 5-era syntax, Symfony DI wiring, and Propel Base* generated classes are all discarded. Estimate accordingly — the bundle is a rounding error in that budget; data migration and credential handling are the cost.

Technical risk (ranked).

1. Unmaintained code in the credential path. No upstream fixes, no CVE triage, no security response. For auth code this is a compliance finding under SOC 2 / ISO 27001 and a standing audit exception, not a footnote.
2. EOL runtime. Propel 1.x is unmaintained and predates modern PHP typing; PHP 8.x compatibility is unverified and plausibly broken by removed behavior. Test before planning anything — this is a hard gate, not a spike nice-to-have.
3. Pinned historical hashing defaults. A frozen implementation keeps whatever password hashing shipped at the time, with no upgrade path short of forking and owning it.
4. MIT license is the only clean positive. Forking and cherry-picking is legally unencumbered — which matters only if someone is prepared to own the result.

Key questions for the requesting team.

1. What is the actual requirement — net-new Laravel authentication, or running an inherited Symfony + Propel 1 app? These are different budgets and different owners.
2. If legacy: which exact FOSUserBundle, Propel, Symfony, and PHP versions are pinned in composer.lock, and is there a hard cutover date?
3. Who owns security patching for this code path, and what is the on-call model — today, before any fork decision?
4. Are there regulatory constraints (PCI, HIPAA) that make unmaintained credential handling disqualifying on their own?
5. What is the costed native alternative — Laravel Fortify/Breeze on the Laravel side, or current Symfony Security + MakerBundle on the Symfony side — versus a scoped port? Expect native to win on every axis.

Integration Approach

Stack fit.

Migration path — only if an existing deployment already depends on it.

1. Inventory, don't assume. Enumerate pinned versions and the generated Base* model classes actually referenced in application code. The blast radius is almost always wider than the bundle itself — it's the whole Propel model surface plus every FOSUserBundle extension point.
2. Frame it as a platform migration, not a bundle upgrade. There is no forward version of this package to upgrade to. Budget accordingly.
3. Port forward; do not patch. Reimplement the user manager/provider behind the target framework's native contract (Laravel UserProvider, or Symfony's current authenticator system) and ETL the data one time into migrations or Doctrine entities.
4. Preserve semantics only. Canonicalization rules, role mapping, and hash identification so existing credentials can be rehashed transparently on next login. Everything else is disposable.

Compatibility gates to validate before any estimate is credible: PHP 8.x runtime (hard gate), Symfony 4+ (excluded), FOSUserBundle successor path (none — deprecated upstream), Propel 1.x (do not introduce anywhere new).

Sequencing.

• Week 0 — timeboxed spike. Confirm whether the legacy app runs on a currently supported PHP. If not, this is a platform migration and the scope changes by an order of magnitude. Do not skip; do not fold into an existing sprint.
• Week 1 — decision record. Two options on paper: retain-and-freeze with a named security owner and dated exit criterion, or fund the auth-surface migration. "Integrate this bundle into Laravel" is not an option to be listed.
• Then — migrate in dependency order: data ETL and rehash-on-login first, session/token issuance cutover second, decommission the Propel schema last after a read-only shadow period.
• Throughout — block auth-adjacent roadmap items (SSO/OIDC, MFA, passwordless) on the migration. Scoping them against the legacy stack is wasted effort.

Operational Impact

Maintenance. Zero upstream maintenance; the repository is archived. Any fork transfers the security-advisory burden to your organization and converts a dependency into an owned product with an unbounded support tail. The Propel 1 toolchain also adds a second, parallel build step (propel-gen against XML schema) that must be sustained in CI — a recurring tax for a capability a native implementation provides for free.

Support. No maintainer, no issue triage, no CVE feed, no peer community at 0 stars / 0 dependents — there is nobody to escalate to and no vendor to buy support from. Internal support is a single named engineer or nothing.

Scaling. Authentication sits on every request, so latency and correctness are disproportionately visible. Propel 1's per-request connection handling works under PHP-FPM but offers no modern pooling or observability hooks; instrumentation is manual and will be built once and never maintained. Note that session/token storage is out of scope for this bundle — confirm independently that it scales before attributing any bottleneck here.

Failure modes.

• Runtime fatal on PHP upgrade — deprecation-to-error promotions in the Propel 1 runtime break auth for all users at once. This is a full outage, not a degraded path, and it is the most likely trigger for an unplanned migration.
• Silent generator drift — schema XML and generated classes desynchronize, surfacing only on rarely exercised paths: password reset, role changes, group membership. These are exactly the paths least covered by tests.
• Unpatched credential handling — highest severity, no mitigation short of forking and owning the code.
• Key-person dependency — the one engineer who understands the Propel build becomes a single point of failure for any auth change, including incident response.

Ramp-up. Cost is high and the hiring pool is near-zero; the knowledge does not transfer to anything else on the roadmap. Factor onboarding time into any "just maintain it" estimate — it is a permanent tax, not a one-off.

Portfolio recommendation. Do not add this to the dependency inventory. If it is already deployed, record it as a migration liability with a named security owner, a dated exit criterion, and an explicit exception in the security review — not a suppressed alert with no expiry. If it is not deployed, mark it not-evaluated / no-fit and redirect the request to framework-native authentication. The TPM action is consistently the same: fund a scoped migration, or freeze with an owner and a date, and refuse the third path of quietly carrying unpatchable auth code.