Sftp Bundle Laravel Package

Technical Evaluation

Architecture fit. The first thing a TPM needs to flag is a stack mismatch: sf2h/sftp-bundle is a Symfony bundle, not a Laravel package. Its value is split between a thin SFTP wrapper (built on phpseclib) and Symfony-specific plumbing — a DependencyInjection/*Extension, Resources/config/services.*, and bundle registration — none of which is meaningful in a Laravel service-container world. The real reusable asset is the phpseclib-backed client logic, which is small enough to read in an afternoon. In a Laravel codebase the natural fit is league/flysystem-sftp-v3 behind Laravel's Storage facade, which is maintained, integrates with the filesystem abstraction, and is what the rest of the ecosystem uses.

Integration feasibility. Low technical effort, low strategic value. Extracting the client into a Laravel service provider is a few hours; the harder question is whether the extracted code is worth owning. The bundle's advertised surface is "quite simple functions" — connect, list, get, put — with no evidence of connection pooling, retry/backoff, atomic rename-on-write, resumable transfers, or host-key verification. All of those are things you will build or bolt on regardless.

Technical risk. High, concentrated in sustainability rather than capability:

• Last release 2020-12-22, ~3 stars, 0 dependents — no community pressure to fix anything, no security-response path, and no signal that anyone is watching CVEs in its transitive dependencies.
• phpseclib major-version drift: v2 vs v3 changed namespaces and behavior, and older phpseclib versions carry PHP 8.x deprecation and correctness issues. The package's composer.json constraints determine whether you inherit that debt.
• Host-key verification is the single biggest unknown. If the wrapper does not verify server fingerprints, every transfer is exposed to MITM — disqualifying for partner integrations carrying PII or payment data.
• No visible CI or test suite; a fork becomes your test suite.

Key questions to put to engineering and the business:

1. Which phpseclib version is pinned, and does it run clean on our current PHP (8.2/8.3) with E_ALL?
2. Does it verify host keys, and can we pin fingerprints per endpoint?
3. Does it support key-based auth with passphrases, non-standard ports, chrooted paths, and configurable timeouts/keep-alives?
4. Who owns the counterparty SFTP endpoints, and are there contractual SLAs on file arrival windows?
5. What are the actual volumes — files/day, max file size, peak concurrency — and do we need idempotent re-delivery or resumable transfers?
6. Is there an existing internal standard (Flysystem, league/flysystem-sftp-v3, or an ext-ssh2 wrapper) we should conform to instead?

Integration Approach

Stack fit. Treat this as a reference implementation, not a dependency. Read it for the phpseclib invocation pattern, then implement against league/flysystem-sftp-v3 exposed through a Storage::disk('sftp_<partner>') driver. That keeps SFTP behind Laravel's filesystem contract, gives you put/get/exists/files for free, and makes the transport swappable to local disk or S3 in tests. If a spike shows the bundle's client does something Flysystem cannot (unlikely), vendor the minimum code into app/Support/Sftp/ with the license header retained — do not install the bundle and do not add Symfony's DI layer.

Migration path.

• Phase 0 (1–2 days): spike connectivity to one real endpoint from a Laravel command, on our PHP version, with host-key pinning on. This either kills the option cheaply or confirms it.
• Phase 1: define an internal SftpGateway interface (push, pull, list, exists) so no application code ever imports phpseclib or Flysystem directly.
• Phase 2: implement the gateway on Flysystem; add config-driven disk definitions per partner.
• Phase 3: if anything from the bundle survives the spike, port it privately behind the same interface and delete the rest.

Compatibility. Verify ext-openssl and ext-mbstring are present in every runtime (phpseclib needs pure-PHP crypto otherwise), confirm container images are not missing ext-ssh2 if we later prefer it for performance, and check that composer's platform config matches production. Pin phpseclib explicitly in our own composer.json rather than inheriting a transitively resolved version.

Sequencing. Requirements and endpoint inventory → interface definition → spike → transport decision (Flysystem vs. vendored code) → implementation with observability → parallel run against one partner → cutover per partner → retire. Do not start with the library choice; start with the endpoint inventory and data classification.

Operational Impact

Maintenance. Effectively zero upstream maintenance. The package has been quiet for over four years with negligible adoption, so the realistic model is adopt-and-fork: we own the code, the phpseclib upgrade path, and the security review. Budget a recurring line item for that, or avoid it entirely by using Flysystem.

Support. No vendor, no maintainer SLA, no issue-tracker activity to rely on. Escalation is internal — name an owning team and an on-call rotation before the first production file moves. For partner-facing file exchange, the failure conversation is with the counterparty, not with GitHub.

Scaling. SFTP is connection-per-transfer, and pure-PHP crypto is CPU-bound: throughput per core will be materially lower than an ext-ssh2 or native sftp binary path for large payloads. Expect to need a queue worker per concurrent transfer, bounded concurrency to avoid overwhelming partner servers, and a chunked/streamed read path so multi-hundred-MB files don't land in PHP memory. None of this is provided by the package.

Failure modes to instrument explicitly:

• Partial writes with no temp-file-plus-rename, leaving truncated files that look valid to the consumer.
• Credential rotation without connection invalidation — stale sessions failing after key rotation.
• Missing or unenforced host-key verification (security incident, not an outage).
• Timeouts and half-open connections under network partition; files resent or never resent depending on idempotency.
• Disk-full or permission errors on the remote side surfacing as generic exceptions.
• Silent success when the remote put returns true but the file lands in the wrong directory.

Mitigate with: temp-file write then atomic rename, checksum verification post-transfer, structured logs per transfer (partner, filename, bytes, duration, attempt), alerting on missed arrival windows, and a dead-letter queue for failed pushes.

Ramp-up. The API is trivially learnable — a mid-level PHP developer is productive in hours. The real ramp is organizational: understanding each partner's directory layout, naming conventions, retry expectations, and cutoff times. Plan roughly one engineering week to production-harden a single integration, plus partner-specific onboarding time, and treat the package itself as contributing almost nothing to that estimate.