Smartcode Bundle Laravel Package

Technical Evaluation

Architecture fit — poor (primary blocker). The package is a Symfony bundle, not a Laravel package. Bundles depend on symfony/http-kernel, symfony/dependency-injection, and the Bundle/Extension lifecycle (Bundle::build(), Extension::load(), compiler passes). Laravel has no equivalent container contract, so the package cannot be composer required into a Laravel app and expected to work. Practical reuse would require either (a) instantiating the underlying intracto/smartcode library directly and bypassing the bundle layer entirely, or (b) running a second Symfony kernel inside Laravel — a non-starter for most teams.

Integration feasibility — conditional. The value is concentrated in the underlying license-generation library (asymmetric signing of a payload, typically RSA/OpenSSL). If that core library is framework-agnostic and semver-stable, the bundle is only ~a few hundred lines of DI/config glue that a Laravel service provider can replace in under a day. We should confirm the actual split before dismissing the package: the bundle may be 10% of the code and 100% of the framework coupling.

Technical risk — high.

• Maintenance signal: 4 stars, 0 dependents, last release 2023-03-27. Effectively a single-vendor internal utility that was open-sourced. No observable downstream usage means no community pressure to fix defects or keep PHP/Symfony constraints current.
• Security-critical code with no audit: license signing/verification is a trust boundary. Cryptographic correctness, key handling, and constant-time comparison matter; there is no evidence of external review.
• Supply-chain exposure: small maintainer surface, no release cadence, no security policy. Adopting it makes us the de facto maintainer.
• Adoption risk is asymmetric: a bug here is not a broken page, it's either free licenses for everyone or legitimate customers locked out.

Key questions for the engineering spike.

1. Does the core signing library live in a separate, framework-agnostic package, and is it usable standalone?
2. Which primitive is used (RSA-PSS vs PKCS#1 v1.5, key size, hash), and is the private key ever loaded in the verification path?
3. Is verification offline-capable, and what is the payload/tamper model — is expiry, feature flags, and customer identity inside the signed blob?
4. Is there key rotation or revocation support, or is the public key baked into shipped clients?
5. What are the PHP and ext-openssl constraints, and does it run on our target PHP version?
6. Is the wire format versioned, so we can evolve payloads without invalidating issued licenses?

Integration Approach

Stack fit. Assume Laravel 10/11 with PHP 8.2+. Direct bundle installation: not viable. Two viable paths:

• Path A (preferred if core is standalone): require the underlying library only, implement a LicenseServiceProvider in Laravel binding a LicenseGenerator/LicenseValidator interface, and keep the bundle out of composer.json entirely. We own ~150 lines of glue. This is the lowest-friction, most testable option.
• Path B (if the bundle is monolithic): vendor/fork the signing logic into an internal acme/licensing package, strip Symfony coupling, and pin it. Accept that we now maintain ~a few hundred lines of cryptography-adjacent code.

Do not attempt to shim Symfony's DI into Laravel; the debugging cost outweighs the reuse benefit.

Migration path. There is no incumbent to migrate from if licensing is greenfield — which materially lowers risk. If we already issue licenses via another scheme, run the new format in parallel: dual-verify old and new tokens behind a feature flag for one release cycle, then retire the old verifier.

Compatibility. Verify composer.json constraints against our PHP matrix before the spike; a 2023 release may still cap at Symfony 5/6 and PHP 8.1. Because we are bypassing the bundle, Symfony constraints become irrelevant — but the core library's PHP constraint still binds us.

Sequencing.

1. Day 1–2: read the source, extract the crypto design, answer the six questions above.
2. Day 3–5: standalone PoC — generate and verify a license outside any framework, including a tamper test.
3. Decision gate: if the primitive is sound and the core is separable, adopt via Path A. If the crypto is homegrown or the code is monolithic, build in-house (RSA sign/verify plus a versioned JSON payload is ~2–3 days and gives us full control).
4. Week 2: Laravel package, key management, CI tests, and a documented revocation/rotation runbook.
5. Week 3: parallel-run and cutover.

Operational Impact

Maintenance. Budget for us being the maintainer. Even on Path A we inherit the core library's upgrade risk; on Path B we inherit the code. Assign a named owner and add a dependency-review checkpoint each PHP minor upgrade. Treat it as a vendored dependency, not a community one.

Support. GitHub issues only, no SLA, no security contact, no release cadence. Our incident response for license issues will be entirely internal — factor that into on-call expectations.

Scaling. Signing is CPU-bound (RSA private-key operations); verification is cheap and can be cached per-request. Volumes in licensing are typically low (issuance at purchase, verification at activation), so horizontal scaling is not a concern. The real scaling question is key distribution: public keys embedded in shipped clients cannot be rotated without a client release, so plan for a key-ID header in the token and support for multiple active public keys from day one.

Failure modes to design against.

• Private key compromise or loss — no recovery path. Requires HSM/KMS storage and a documented reissue process.
• Clock skew / offline clients — expiry checks break; define grace windows.
• Payload schema drift — without a version field, adding a feature flag invalidates every issued license.
• ext-openssl missing or FIPS-restricted in a target environment, silently altering verification behavior.
• Composer conflicts on abandonware in a future Laravel upgrade, forcing an emergency fork.

Ramp-up. Low: the domain is small and the code footprint is modest — an engineer is productive in under a week. The schedule cost is not learning the API, it is the security review and the key-management design, which we should not skip.

Recommendation. Score 0.05 and zero dependents accurately describe this as an unmaintained, framework-mismatched artifact. Do not adopt the bundle. Spend two days evaluating the underlying signing approach as a design reference, then either wrap the core library in a thin Laravel service provider or implement sign/verify in-house with a versioned payload format.