Phpseclib2 Compat Laravel Package

Technical Evaluation

• Architecture fit: Best treated as a transitional adapter, not a strategic dependency. It lets legacy Laravel/PHP code continue calling phpseclib 2.x-style classes while phpseclib 3.x performs the underlying cryptography. This fits an application with hard-coded phpseclib\Crypt\* usage, especially SSH/SFTP, RSA, or AES calls spread across jobs, commands, and services.
• Integration feasibility: Composer-level integration is straightforward in principle: add the compat package, ensure phpseclib 3.x is present, and remove direct reliance on phpseclib 2.x. Laravel should not need a service provider or facade. Feasibility depends on whether the shim covers the exact v2 classes, constants, exceptions, and key formats in use.
• Technical risk: High for a cryptography-adjacent dependency with only 12 stars, an unknown repository, and a future-dated release (2026-06-14) relative to this review. The shim may not cover all phpseclib 2 APIs or behavioral edge cases. Crypto correctness still depends on phpseclib 3.x, but compatibility gaps can create subtle failures in key handling, signatures, SSH negotiation, or exception flows.
• TPM recommendation: Approve only as a time-boxed migration aid with explicit exit criteria. Do not adopt for greenfield code; use phpseclib 3.x directly. Require provenance review, API-coverage inventory, and cryptographic regression tests before production use.
• Key questions:
  • Is this package official, community-maintained, or a personal fork? Why is the repository unknown?
  • Does it cover every phpseclib 2 class and method used by our codebase, or only common paths?
  • Which phpseclib 3.x versions and PHP/Laravel versions are supported?
  • How are upstream phpseclib security advisories tracked and patched?
  • Are there namespace/autoload conflicts if phpseclib 2.x remains installed transitively?
  • What is the test coverage for SSH/SFTP, RSA/ECDSA keys, encryption modes, and exception compatibility?
  • Is the release artifact reproducible and signed or otherwise verifiable?

Integration Approach

• Stack fit: Fits Laravel via Composer and autoloading, with no framework-specific wiring. It is most useful where existing application code, packages, or internal libraries still type-hint or instantiate phpseclib 2.x APIs.
• Migration path: Inventory all phpseclib 2 usage, replace the direct phpseclib 2 dependency with this compat package plus phpseclib 3.x, run the full test suite, then progressively rewrite call sites to native phpseclib 3.x APIs. Treat the shim as temporary scaffolding.
• Compatibility: Verify PHP version, Laravel version, required PHP extensions, and phpseclib 3.x constraints. Check for duplicate namespace providers and transitive dependencies still requiring phpseclib/phpseclib:^2. Confirm key formats, cipher defaults, and exception classes match legacy behavior.
• Sequencing:
  1. Freeze dependency versions and capture an SBOM.
  2. Run a spike branch with the compat package in CI.
  3. Add characterization tests around every cryptographic operation in use.
  4. Compare outputs or interoperability against the existing phpseclib 2 implementation where feasible.
  5. Deploy behind a canary or low-risk job path.
  6. Track a burn-down list to migrate call sites to phpseclib 3.x and remove the shim.
• TPM guardrails: Set an expiration date for the shim, assign an owner, and require a rollback plan that restores the prior dependency lockfile.

Operational Impact

• Maintenance: Low-effort to install, but maintenance risk is concentrated in an unknown, low-adoption package. If it lags phpseclib 3.x releases, security patches may be delayed. Prefer forking or vendoring only if provenance and license permit, and only with an owner.
• Support: Expect community-only support. There is no evidence of vendor backing. Internal runbooks should document the shim, its covered APIs, and the native phpseclib 3.x replacement path.
• Scaling: Runtime overhead should be minimal because cryptography remains in phpseclib 3.x, but the extra indirection can complicate profiling and debugging. Scale risk is less about throughput and more about broad blast radius if a shared crypto path breaks.
• Failure modes: Class-not-found or method-not-found errors for uncovered v2 APIs; namespace collisions with lingering phpseclib 2.x; exception-type mismatches; changed defaults for ciphers, key formats, or signature schemes; SSH/SFTP interoperability failures; silent behavioral drift that only appears with specific key sizes or servers.
• Ramp-up: Laravel developers familiar with phpseclib 2.x should ramp quickly on call-site usage, but crypto correctness validation requires senior review. Allocate TPM and security-engineering time for provenance checks, test design, and migration tracking rather than treating this as a routine Composer addition.