Tissue Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony 3.x Focus: The bundle is tightly coupled to Symfony 3.x, which may introduce compatibility risks if the application is on Symfony 4/5/6+ or a non-Symfony PHP stack (e.g., Laravel). The core functionality (virus scanning) is reusable, but the bundle’s integration layer (e.g., CleanFile constraint, service tags) is Symfony-specific.
• Modularity: The underlying Tissue library is adapter-based, allowing custom virus-scanning engines (e.g., ClamAV, custom scripts). This aligns with extensibility needs but requires upfront adapter configuration.
• Validation Hooks: The bundle leverages Symfony’s validation system (e.g., CleanFile constraint) for upload-time scanning, which is a clean architectural pattern for pre-processing. In Laravel, this would need a custom solution (e.g., middleware, form requests, or validation rules).

Integration Feasibility

• Laravel Compatibility: The bundle is not natively compatible with Laravel due to:
  • Symfony-specific components (e.g., ConstraintValidator, ServiceContainer tags).
  • Laravel’s validation system (e.g., FormRequest, Validator) differs from Symfony’s Constraint system.
• Core Logic Portability: The Tissue library itself (PHP-only, no Symfony dependencies) could be adapted for Laravel. The ClamAV adapter or custom adapters would need to be reimplemented as Laravel services.
• File Upload Handling: Laravel’s file uploads (e.g., Request->file(), UploadedFile) would require custom middleware or validation logic to integrate with Tissue.

Technical Risk

• High Integration Effort: Rewriting Symfony-specific components (e.g., constraints, service tags) for Laravel would require significant development time. Risks include:
  • Incomplete feature parity (e.g., batch scanning via service injection).
  • Potential performance overhead if not optimized for Laravel’s service container.
• Dependency Age: Last release in 2017 raises concerns about:
  • Compatibility with modern PHP (7.4+), Symfony (5/6), or Laravel (9/10).
  • Security vulnerabilities in ClamAV or Tissue (though the MIT license allows forks).
• Testing Gap: No dependents or stars indicate unproven reliability. Custom adapters or Laravel-specific implementations would need rigorous testing.

Key Questions

1. Is Symfony 3.x a Hard Dependency?
   • If the application is not Symfony, can the Tissue library be used standalone with custom Laravel integration (e.g., middleware for uploads)?
2. What Are the Scanning Requirements?
   • Are real-time upload scans (like Symfony’s CleanFile) critical, or can batch scans (e.g., via Laravel queues) suffice?
3. Adapter Flexibility
   • Does the team have expertise to build a Laravel-compatible adapter for ClamAV or another engine (e.g., PHP-ClamAV)?
4. Performance Impact
   • How will ClamAV scans scale with high-traffic uploads? Are there caching or async processing strategies?
5. Maintenance Plan
   • Given the package’s age, is there a plan to maintain or fork it for Laravel? Alternatively, would a Laravel-specific package (e.g., spatie/laravel-virus-scanner) be preferable?

Integration Approach

Stack Fit

• Laravel Unfit: The bundle is not a drop-in solution for Laravel. Key mismatches:
  • Symfony’s ConstraintValidator → Laravel’s FormRequest/Validator.
  • Service tags (cl_tissue.adapter) → Laravel’s service providers/binding.
• Workarounds:
  • Option 1: Standalone Tissue Library Use the Tissue library directly with a custom Laravel wrapper. Example:

    // Laravel service provider
    $this->app->bind(ScannerInterface::class, function ($app) {
        return new ClamAVAdapter('/path/to/clamav');
    });
    

    Then integrate with:
    • Uploads: Middleware or FormRequest validation.
    • Batch Scans: Laravel queues (e.g., ScanFileJob).
  • Option 2: Fork and Adapt Fork the bundle, replace Symfony dependencies with Laravel equivalents (e.g., Illuminate\Validation\Rule), and publish as a new package.

Migration Path

1. Assess Scope:
   • Decide if real-time upload scanning or batch processing is prioritized.
   • Identify the virus-scanning engine (ClamAV or alternative like php-clamav).
2. Prototype Core Logic:
   • Test Tissue library standalone in Laravel to validate scanning functionality.
   • Example:

     use Bubnov\Tissue\Scanner;
     use Bubnov\Tissue\Adapter\ClamAVAdapter;
     
     $scanner = new Scanner(new ClamAVAdapter('/usr/bin/clamscan'));
     $result = $scanner->scan('/path/to/file');
     

3. Integrate with Laravel Ecosystem:
   • Uploads: Create a ScanFile rule for Laravel validation:

     use Illuminate\Contracts\Validation\Rule;
     
     class ScanFile implements Rule {
         public function passes($attribute, $file) {
             return (new Scanner($this->adapter))->scan($file->path()) === null;
         }
     }
     

   • Batch Processing: Use Laravel queues to offload scans:

     ScanFileJob::dispatch($file)->onQueue('scans');
     

4. Replace Symfony-Specific Components:
   • Replace CleanFile constraint with Laravel’s FormRequest or Validator extensions.
   • Replace service tags with Laravel’s service binding.

Compatibility

• PHP Version: Ensure Tissue/ClamAV support PHP 8.x (may require polyfills or forks).
• ClamAV Dependency:
  • Verify ClamAV is installed and accessible on the server.
  • Test with a lightweight alternative (e.g., VirusTotal API) if ClamAV is unreliable.
• Laravel Version: Test with the target Laravel version (e.g., 9/10) to catch deprecation issues.

Sequencing

1. Phase 1: Proof of Concept (2–4 weeks)
   • Validate Tissue library works in Laravel.
   • Implement basic scanning logic (e.g., CLI script for batch scans).
2. Phase 2: Laravel Integration (3–6 weeks)
   • Build ScanFile validation rule.
   • Integrate with file uploads (middleware/FormRequest).
3. Phase 3: Scaling and Optimization (2–4 weeks)
   • Add queue-based batch scanning.
   • Implement caching (e.g., Redis) for repeated scans.
4. Phase 4: Testing and Deployment
   • Unit/integration tests for scanning logic.
   • Load testing for high-upload scenarios.

Operational Impact

Maintenance

• High Ongoing Effort:
  • No active maintenance for the original bundle → team must own updates (e.g., PHP/ClamAV compatibility).
  • Custom Laravel integration may diverge from Tissue’s updates.
• Dependency Risks:
  • ClamAV updates may break scanning (e.g., CLI argument changes).
  • Tissue library may lack PHP 8.x support (require forks or polyfills).
• Mitigation:
  • Monitor Tissue issues and fork if needed.
  • Containerize ClamAV scans (e.g., Docker) to isolate dependency updates.

Support

• Limited Community Support:
  • No stars/dependents → rely on Symfony documentation or reverse-engineer the bundle.
  • Laravel-specific questions may lack answers; consider opening issues in the Tissue repo.
• Debugging Challenges:
  • ClamAV scan failures may require server-level troubleshooting (e.g., permissions, ClamAV config).
  • Custom adapter errors could be opaque without clear logging (add structured logging early).
• Support Plan:
  • Document internal runbooks for common issues (e.g., "ClamAV scan timeouts").
  • Partner with DevOps to monitor ClamAV health (e.g., uptime, scan success rates).

Scaling

• Performance Bottlenecks:
  • ClamAV: Scanning large files or high volumes may slow responses. Mitigate with:
    • Async processing (Laravel queues).
    • Caching results (e.g., scan:file:{hash} in Redis).
  • Resource Usage: ClamAV scans consume CPU/memory. Benchmark with production-like loads.
• Horizontal Scaling:
  • Distribute scans across workers (e.g., Laravel Horizon for queues).
  • Offload to a microservice if scans are a critical path.
• Fallback Mechanisms:
  • Implement a circuit breaker for ClamAV (e.g., switch to