Product Decisions This Supports
- Upload-security hardening: The package provides archive safety checks (
ArchiveSafetyChecker), a validation rule (NoZipBomb), and safe extraction helpers (SafeExtractsZips). It directly supports product decisions around accepting ZIP/archive uploads from untrusted users without risking disk, memory, or CPU exhaustion.
- Build vs. buy: For Laravel products that accept archives, this is a narrowly scoped, low-cost Composer dependency rather than an in-house security control. v2.0.0 confirms continued maintenance, Laravel discovery metadata, CI coverage, and a Laravel 13 consumer upgrade path.
- Roadmap prioritization: The release is primarily a breaking namespace/identity change (
DineshUprety\ZipBombGuard\ → ZipBombGuard\), not a new product capability. PM action is dependency and migration planning, not feature discovery.
- Release/upgrade planning: Because old names are not aliased, any application code, container bindings, mocks, explicit provider/facade registrations, or persisted jobs referencing the old namespace must be migrated before deploying v2. PMs should schedule this as an engineering maintenance item and include it in upgrade/security review cycles.
- Use cases: Multi-tenant SaaS file uploads, customer data imports, backup/restore uploads, document management, marketplace attachments, and any workflow where users or integrations submit archives for processing.
- Risk/compliance support: Useful evidence for secure file-handling controls, resource-exhaustion defenses, and dependency-maintenance practices. It does not replace antivirus/content scanning or a broader upload security program.
When to Consider This Package
Consider adoption when:
- The product is built on Laravel/PHP and accepts ZIP or archive uploads from users, customers, or external systems.
- The team wants a maintained, focused control against zip bombs and unsafe archive extraction rather than building and maintaining custom checks.
- The application needs a Laravel-native validation rule, extraction concern, Artisan command, and configurable safety checks.
- The team can absorb the v2.0.0 namespace migration, including reviewing queued/persisted jobs for old class names.
- The product has security, reliability, or compliance requirements around file uploads and resource exhaustion.
Look elsewhere or defer when:
- The product does not accept archives or untrusted compressed files.
- The stack is not Laravel/PHP, or the team cannot adopt a Composer dependency.
- The requirement is full malware/antivirus scanning, DLP, or content inspection; this package is not a substitute for those controls.
- The team cannot yet perform the breaking namespace migration and needs a zero-change upgrade. In that case, remain on 1.x temporarily, but track the migration.
- The application already has equivalent archive-safety controls with stronger coverage and no migration benefit.
How to Pitch It (Stakeholders)
For executives: This is a small, focused Laravel security dependency that reduces the risk of users uploading malicious or oversized archives that could exhaust server resources. The new v2.0.0 is a maintenance release: archive-safety behavior is unchanged, but it introduces a namespace change that requires a planned engineering migration. The business benefit is continued, low-cost protection for file-upload workflows; the main cost is a one-time upgrade effort.
For engineering: Adopt dineshuprety/laravel-zip-bomb-guard:^2.0 only after migrating imports, fully qualified names, container bindings, mocks, and explicit provider/facade registrations from DineshUprety\ZipBombGuard\ to ZipBombGuard\. There are no aliases, so stale references will break. Review persisted jobs containing old class names before deployment. The package name, facade alias, config, Artisan command, supported PHP/Laravel versions, and safety behavior are unchanged. Validation includes 41 tests, 82 assertions, a seven-job CI matrix, and a Laravel 13 consumer upgrade covering discovery, facades, exceptions, validation, scanning, extraction, and config publishing. Treat this as a routine but breaking dependency upgrade, not a feature release.