Gdpr Bundle Laravel Package

Technical Evaluation

Architecture fit — unchanged: poor as a library, useful as a reference model. The v3.0.1-alpha release touches type declarations, service definitions, and the EncryptBundle dependency. None of that alters the core finding: specshaper/gdpr-bundle is a Symfony bundle targeting the full-stack kernel, Bundle/Extension/DI conventions, and Doctrine metadata. Laravel has no bundle system, no services.yml compiler passes, and uses Eloquent. The changes are all within the Symfony idiom — stronger type declarations and revised service wiring make the package more idiomatic Symfony, not more portable. Dropping it into Laravel still means either embedding a Symfony container or extracting the domain model and rewriting it. The valuable artifact remains the declarative classification + persistence-boundary encryption + register-export concept; the code still does not transfer.

Integration feasibility — low direct, moderate conceptual; now with a wider dependency surface. The realistic paths are unchanged in ranking:

1. Reference implementation / spec source. Read the source, extract the metadata schema and encryption hook design, reimplement against Laravel's Encrypter, custom Eloquent casts, and queued jobs. Low risk, moderate effort, no runtime dependency. Note: read the 3.x branch, not older tags, since type declarations and service definitions have moved — but treat 3.x as unstable by definition (alpha).
2. Fork-and-port. Vendor, strip Symfony plumbing, replace Doctrine metadata with PHP 8 attributes and an Eloquent model-scanning command. The type-declaration work in this release may slightly reduce porting friction (stronger signatures, presumably newer PHP syntax), but you inherit the code, its gaps, and now a second upstream package.
3. Production use as intended. Still blocked. Symfony 3 is EOL (Nov 2021). A 3.x alpha does not constitute a supported release line, and an alpha on a dormant single-maintainer repo is not a foundation for a regulated-data path.

Technical risk — high, with a new supply-chain dimension. The compliance risk still dominates: "encrypt and report" gestures at Art. 32 and possibly Art. 30 while saying nothing about Arts. 15/17/20, consent capture, or processor agreements. Cryptography risk persists but has shifted: this release confirms the encryption layer is delegated to a separate EncryptBundle, so cipher choice, IV handling, and key rotation are now questions for a second package — one we have not vetted. That widens the transitive chain in the sensitive path and adds a second abandonment surface. Release-engineering signals are also poor: shipping 3.0.1-alpha with no stable 3.0.0 in evidence, no changelog depth beyond a one-line summary, and a major version bump on a repo dormant since 2022 suggests thin versioning discipline; provenance of the tag is worth confirming before any fork. Finally, the release answers none of the previously open questions — no cipher documentation, no key-source documentation, no test-suite signal, no declared PHP/Laravel-relevant constraints.

Key questions to resolve before committing engineering time (revised):

• What PHP version do the new type declarations require, and what does composer.json now constrain? Does this move the baseline to PHP 8.x, and does it break on 8.3?
• What exactly is the EncryptBundle dependency — maintainer, last release, cipher implementation, key source, rotation support? This is now the crypto-critical package, not gdpr-bundle itself.
• Is the encryption layer persistence-agnostic, or does it still require Doctrine metadata to find fields to encrypt?
• What changed in the service definition — is there a config-format break versus 2.x, and is there a documented migration path?
• Why is the release numbered 3.0.1-alpha rather than 3.0.0-alpha? Is there a missing tag, or was the version re-cut?
• Does the "reporting" surface produce an Art. 30 record-of-processing export, or only an internal inventory view?
• Is there any test suite, and does it cover failure paths (missing key, unclassified field, decrypt failure)?
• Who owns the fork, and what is the CVE response commitment if we vendor it — for both this package and EncryptBundle?

Integration Approach

Stack fit. Unchanged: fit the problem, not the package. A Laravel shop needs PII classification on models, encryption at rest for sensitive columns, retention/erasure jobs, and an auditable processing register. Laravel supplies the crypto primitive (Illuminate\Encryption\Encrypter, encrypted casts, Encrypted attributes) and the scheduling/queueing primitives. What it lacks — and what is worth borrowing — is the declarative classification metadata, plus the reporting concept. Nothing in the new release changes this mapping; if anything, the dependency delegation reinforces the recommendation to own the crypto layer locally rather than inherit someone else's.

Migration path (in practice, a porting path).

1. Discovery. Inventory tables and models; classify fields into identifiers, special-category, and operational data. Do this with the DPO, not from the code.
2. Schema design. Define a neutral metadata shape — field, category, purpose, lawful basis, retention, processor — as PHP attributes or a config map, kept framework-neutral.
3. Primitive reuse. Map the encryption behavior onto Laravel's Encrypter with a KEK/DEK envelope in a managed KMS. Do not port crypto code from either this package or EncryptBundle; port the hook point (cast or observer).
4. Reporting. Build a gdpr:register artisan command emitting an Art. 30-shaped export, plus gdpr:export/gdpr:erase for subject rights. The bundle's reporting concept still saves design time even though its implementation doesn't transfer.
5. Dual-read rollout. Add encrypted shadow column, backfill via queued job, dual-read, cut over, drop the plaintext column.

Compatibility. The new type declarations and service-definition changes point at a rewritten config surface and, likely, a PHP 8.x baseline — which is directionally helpful but still not Laravel-compatible without overrides, and constraint overrides on an unmaintained package remain how you get a broken autoloader in production. The added EncryptBundle dependency means compatibility is now a two-package evaluation. Treat 3.x as source material for the port, not a composer require.

Sequencing. Unchanged, with one insertion. Weeks 0–2: DPO discovery and register baseline — the taxonomy is the deliverable. Weeks 2–3: read-only spike in an isolated container against the 3.x branch; extract metadata schema, encryption hook design, and a written inventory of what EncryptBundle actually does. Produce a one-page port spec. Weeks 3–8: build the internal Laravel package (attributes, casts, KMS wiring, register export, DSAR commands) with tests. Weeks 8–12: backfill and cut over one high-value model, then iterate. Do not schedule the port before DPO sign-off on classification.

Operational Impact

Maintenance. You own 100% of it, and the surface just grew: two packages to track instead of one. The 3.x line is alpha, so even a fork has no stable baseline to fork from — expect to pin a specific commit rather than a version constraint. Budget for framework-version bumps, KMS provider changes, taxonomy updates from the legal team, and now periodic review of EncryptBundle's status. The port route still yields a smaller, better-understood maintenance surface written by people who can debug it at 2 a.m.

Support. No vendor, no SLA, no security advisory channel, now across two upstreams. Sixty-six stars and zero dependents means the support model is "read the source." A fresh alpha does not change that arithmetic — if anything it signals the maintainer's attention is on structural refactoring (types, service definitions, dependency extraction) rather than on hardening, documentation, or tests. Acceptable for a design reference; unacceptable in the path of regulated personal data.

Scaling. Unchanged. Write-path encryption costs per-row CPU and, if unbatched, per-row KMS round-trips — envelope encryption with a cached DEK is mandatory. Bulk re-encryption (backfill and key rotation) needs chunked, resumable, idempotent jobs with a checkpoint table; neither this release nor the dependency changes that, and the bundle still offers no evidence of one. Register generation over a metadata scan is cheap at hundreds of models.

Failure modes to design against explicitly.

• Key loss = permanent data loss. Backups and a documented recovery drill; test restoration quarterly.
• Silent plaintext. A misconfigured cast writes unencrypted data that looks fine. Add a periodic scanner asserting every classified column is ciphertext-shaped.
• Classification drift. New columns go untagged, unencrypted, and unregistered. Enforce with a CI check failing on unclassified string columns.
• False compliance signal. The most dangerous failure: a green dashboard reading "GDPR bundle installed" while DSAR turnaround, processor registers, and retention enforcement remain manual. The register export is a starting artifact, never an attestation.
• Decrypt-path fragility. Rotated or missing keys must surface as a distinct alertable error class, not a generic 500 during a subject access request.
• Transitive dependency abandonment. New this cycle: EncryptBundle sits in the crypto path and must be scanned and owner-assigned alongside the parent package, or the security gate will keep failing without a name attached to it.

Ramp-up. Unchanged in substance. Reading the code still requires Symfony 3 bundle conventions, Doctrine metadata drivers, and event-subscriber lifecycle — two to three days for a senior PHP developer, with no transferable payoff to the Laravel codebase. The stronger type declarations in 3.x may shave a few hours off comprehension but do nothing for the conceptual distance. The port is two to four sprints for one engineer, with DPO review time on the taxonomy as the long pole. For a team without existing Symfony/Doctrine depth, reference-and-reimplement remains materially cheaper than fork — and the new transitive dependency makes the fork route slightly more expensive than it looked last cycle, not less.