Phpseclib2 Compat Laravel Package

Product Decisions This Supports

• Tech-debt and platform-upgrade sequencing. This is a bridge dependency, not a destination. It lets you decouple two roadmap items that are usually bundled: "get off an end-of-life crypto library / support PHP 8+" and "rewrite every crypto call site." You can ship the first without blocking on the second.
• Build vs. buy (build vs. adopt). The alternative to this package is an internal shim you write and maintain yourself. Unless your usage is trivial, adopting a maintained polyfill is almost always cheaper than owning a compatibility layer in-house.
• Security posture and EOL exposure. phpseclib 2.0 is past end-of-life; 3.0 is the supported line. This package is a mechanism to reduce security risk in a legacy product line without a large-budget rewrite approval.
• Scope decisions for legacy/enterprise product lines. If you must keep supporting old customer integrations, on-prem deployments, or a plugin ecosystem that references Crypt_RSA, Net_SSH2, Crypt_AES, etc., this is how you keep those contracts alive while modernizing underneath.
• Dependency governance / SBOM policy. Adopting it forces an explicit policy decision: transitional dependencies are allowed, but only with an owner, a removal date, and a CI guard against new usage.
• Use cases it directly enables: monoliths with crypto calls scattered across many files; legacy packages or vendor bundles you don't control that depend on the 2.0 API; incremental migrations where you want tests green throughout.

When to Consider This Package

Adopt it when:

• You have real phpseclib 2.0 usage that you cannot rewrite this quarter, and you need 3.0's security fixes and modern PHP support now.
• You treat it as a timeboxed, reversible step with a named owner and a scheduled removal.
• You have verified your specific usage falls inside the covered API surface. Do not assume parity: class coverage, constants, streaming behavior, and edge-case return values are not guaranteed to match 2.0 exactly. Write characterization tests around every call site before switching.
• You can put a gate in CI (a lint/static-analysis rule) that fails on new 2.0-style usage, so the bridge doesn't silently become permanent.

Look elsewhere when:

• Greenfield or new code — use phpseclib 3.0 directly. There is no reason to start on the legacy API.
• Only a handful of call sites — a direct rewrite is cheaper and leaves no residual dependency. Count first; the answer is often "just migrate."
• You need a foundation, not a crutch. This project is a thin adapter. Signals here are weak: 12 stars is minimal community adoption, the repository metadata is unverified in this assessment, and the project is effectively single-maintainer. There is no vendor SLA and a real bus-factor risk.
• You need long-term support guarantees, security response commitments, or broad ecosystem validation. A low-adoption compatibility shim will not satisfy a procurement or security review that demands those.
• Performance-sensitive paths. An indirection layer over the real implementation adds overhead and a second place for behavior to diverge.

Before adoption, verify: the actual repository identity and maintainer, the license (MIT is claimed), the release cadence, and whether the latest release date is real rather than a metadata artifact. Pin an exact version and run an SCA/security scan as you would for any crypto-adjacent dependency.

How to Pitch It (Stakeholders)

For executives: We are carrying an end-of-life cryptography library that blocks our PHP upgrade and is a standing security finding. This change lets us replace the unsafe internals without rewriting the code that calls into it, so we retire the risk on a short timeline and move the larger refactor into normal roadmap sequencing instead of a special project. Cost is small and the change is reversible. The main caveat is that the compatibility layer is a thin, low-adoption project with a single maintainer, so we are deliberately treating it as a bridge with a removal date rather than a long-term foundation.

For engineering: Install it, keep your existing Crypt_* / Net_* call sites, and get 3.0 internals plus modern PHP support behind them. Three conditions: (1) write characterization tests around every call site first, because behavioral parity isn't guaranteed; (2) add a CI rule that fails on any new 2.0-style API usage; (3) file the true 3.0 namespaced migration as its own backlog item with an owner and a target date. The dependency is transitional by policy — if it's still in the tree a year from now, that's the failure mode we're guarding against.