Ldap Bundle Laravel Package

Technical Evaluation

Architecture fit. Unchanged. The package name and packaging convention (ldap-bundle) still indicate a Symfony bundle, not a Laravel package. v5.1.0 does not alter that: a changelog entry consisting solely of a PHP constraint is a packaging/metadata change, not evidence of a Laravel service provider, config publishing, or facade wiring. Symfony bundles bootstrap through Bundle classes, DI Extension classes, and compiler passes — mechanisms Laravel does not execute. Installing into a Laravel app remains possible at the Composer level and inert at runtime without a hand-written adapter service provider. The architecture mismatch against the "Laravel/PHP package" framing stands and still must be validated against the actual composer.json.

Integration feasibility. Unchanged and still low-to-moderate. The release supplies no README, no docs, no tests, and no usage examples; the note is one line. The description ("Authorisation bundle fot gepur apps") still signals an internal, org-specific authorization layer rather than a general-purpose LDAP client, so the coupling to gepur's user/role/tenant model is the dominant integration cost, not the LDAP protocol. Discovery cost remains "read every file." One marginal improvement: a release in the current period is weak evidence that someone can still cut a tag, which slightly raises confidence that a fork is buildable against a modern toolchain — but it does not reduce the reading required to understand behavior.

Technical risk. Still high, though the maintenance sub-risk has moved from "abandoned" to "minimally attended." Two things changed and one thing got worse:

• Positive but thin: a release after roughly four years of silence means the repo is not fully dead. Version 5.1.0 implies an active major line, so the 2021-era code the previous assessment described may no longer be the current state — there may have been a v4→v5 transition with breaking changes we have never seen.
• New specific risk — unbounded PHP constraint: the release note is php >=7.4 with no upper bound. That is a compatibility red flag, not a compatibility guarantee. It tells you the package will install on PHP 8.2/8.3/8.4 and future majors, not that it was tested there. It also gives no signal about framework-version constraints. Combined with a Laravel 11/12 target (PHP 8.2+), the constraint will resolve happily and any incompatibility will surface at runtime — the worst place for auth code to fail.
• Release hygiene is itself a finding: a changelog whose entire content is a constraint line means there is no record of what actually changed between the previously assessed state and v5.1.0. We cannot diff intent from the note.

Auth code still carries outsized blast radius. Supply-chain risk remains low (MIT, small surface, public repo); correctness and maintenance risk remain high with no community to catch regressions.

Key questions. Mostly the same, plus release-specific ones:

• What changed between the version assessed in 2021 and v5.1.0 — was there a v4→v5 major, and were there breaking changes to bind or group-mapping behavior?
• Is the package actually Symfony-only, and what are its composer.json PHP/Symfony constraints? Does it declare tested PHP versions or only >=7.4?
• Does the new release add or drop any dependency, and does it still wrap ext-ldap directly versus symfony/ldap?
• What is the authorization model — simple bind, search+bind, group-to-role mapping, or gepur-internal RBAC?
• Does it handle LDAPv3, StartTLS/LDAPS, referral chasing, paged results, and AD vs OpenLDAP differences?
• Are there transitive dependencies on private gepur packages that are not resolvable publicly?
• Does v5.1.0 come with a tag we can pin, a working build, and any CI evidence — or is it a metadata-only bump?
• Is there an internal maintainer still active, and is there a security contact?

Integration Approach

Stack fit. Still poor as-is, and the new release does not change the calculus. For a Laravel target the pragmatic path remains not to adopt this bundle but to reimplement its behavior on a Laravel-native foundation — ldaprecord-laravel or a thin custom package over ext-ldap. For a genuinely Symfony target, symfony/ldap plus a small security authenticator remains the better-supported equivalent. The package's value is as a reference implementation; v5.1.0 does not change that classification.

Migration path. Unchanged in shape, with one added step at the front. Because v5.1.0 may sit several majors away from the code the previous assessment described, the audit must begin by establishing what the current tag actually is — clone v5.1.0 specifically, diff against the last release we can identify, and only then extract behavior. From there: (1) read the source and extract bind strategy, attribute mapping, group resolution, caching, error handling; (2) define an internal LdapAuthenticator interface expressing that behavior; (3) implement against a maintained library; (4) run legacy and new paths in parallel against a staging directory; (5) cut over and remove the dependency. If direct adoption is unavoidable short-term, isolate it behind an anti-corruption layer and pin to an exact tag, not a range.

Compatibility. The release appears to answer the PHP-ceiling question and does not. php >=7.4 removes the suspected 8.0/8.1 ceiling but substitutes an untested open range. Expected findings on source review: no upper bound on PHP, unknown or absent Symfony-version constraints, ext-ldap availability in the runtime image, TLS certificate handling against the corporate directory, and behavior against the specific directory flavor in use (AD vs OpenLDAP). Each is a hard blocker that surfaces at integration time. Treat the new constraint as permission to try, not evidence of support.

Sequencing. Unchanged, and still gated on the spike. Do the source audit plus a compatibility spike first — one to two days, now explicitly including "install v5.1.0 on the current PHP runtime and boot it in a throwaway Symfony harness to confirm it does not fatal." Gate the decision on that output: greenfield Laravel project → do not adopt; existing Symfony-gepur codebase → adopt with fork-and-pin at v5.1.0; otherwise → replace. Schedule outside an auth-sensitive release window and never combine with a directory-side change. Note the new release resets the staleness clock but not the architecture verdict — do not let a version bump be read as a green light by stakeholders.

Operational Impact

Maintenance. Improved from "effectively zero upstream" to "minimal, unverified upstream." There is now a release in the current period, which suggests someone can tag. That is not the same as sustained maintenance: no evidence of tests, CI, issue triage, or a security disclosure process accompanies the note, and the changelog is too thin to reconstruct intent. Plan as before — someone on the team must be able to read and patch PHP auth code indefinitely — but with a slightly better fork base (a current tag to branch from) than existed previously.

Support. Unchanged. No vendor, no community, no SLA, no dependents to absorb fixes. A recent tag does not create a support channel; incidents still route to whoever adopted it. For an authentication path that remains the wrong support posture.

Scaling. Unchanged. LDAP scales; the wrapper is the question. Watch for per-request binds, no connection reuse, no caching of group lookups, and synchronous calls on the request path against a possibly remote directory. Under load these become latency and connection-exhaustion problems the package was never benchmarked for. The release note offers no performance or pooling changes.

Failure modes. The dangerous set is unchanged: directory unreachable → hanging or blocked login; misconfigured bind DN → silent auth failures indistinguishable from bad passwords; group-mapping drift → privilege escalation or de-escalation; TLS misconfiguration → credential exposure on the wire; version drift between the pinned package and a PHP upgrade → fatal errors at boot. The new release adds a sixth: an unbounded PHP constraint that lets Composer install the package on a runtime no one has tested, converting a would-be install-time failure into a production login outage. None of these are mitigated upstream; all require deliberate error handling, health checks, and a pinned exact tag that you add yourself.

Ramp-up. Unchanged: high relative to package size. Still no docs, so onboarding is a source-reading exercise, and the internal coupling means the mental model is "how gepur modeled authorization," not "how LDAP works." The new release does not lower this — a single constraint line is not documentation. Estimate days, not hours, for a new engineer to safely modify it, and expect knowledge to concentrate in whoever did the original audit, which remains its own bus-factor risk.

Recommendation. Unchanged: do not adopt as a dependency for a Laravel codebase. v5.1.0 is a metadata-level release that resets the staleness clock without addressing the Symfony/Laravel architecture mismatch, the missing documentation and tests, the org-specific authorization coupling, or the unbounded PHP support claim. Use it only as behavioral documentation, pin to the exact tag if you must fork, and replace with a maintained LDAP library behind an internal interface. Re-review only if a future release ships tests, docs, or evidence of current-PHP verification.