m2-integrity-db

Establishing what should be on disk

Before investigating a suspicious core file, I need to know what that exact package version originally contained. Composer can tell me which version is installed, but its archive checksum cannot tell me which individual files have changed. Magento supplies no per-file reference either. Without one, an investigation starts with another problem: finding something trustworthy to compare against.

I built m2-integrity-db to supply that reference. It records the SHA-256 of files as Magento packages actually shipped them, making it possible to distinguish an unchanged file from an addition, a removal or a modification. The useful result comes after accounting for the patches an installation is supposed to carry. An unexplained difference is where a hurried hand-edit, an incomplete deployment or an injected backdoor might be hiding. A mismatch gives me something to investigate; it does not establish the cause by itself.

Hashes are enough for the question

The public data contains paths, digests and byte sizes. Those are enough to compare a local file with its published counterpart without keeping or redistributing the counterpart itself. SHA-256 is one way: the database cannot be used to reconstruct Adobe's source code. During a build, archives are downloaded, streamed through the hasher and discarded.

The reference comes from the distribution archives Composer installs. That keeps the comparison anchored to the installed artefact, with paths relative to each package root. A consumer can walk the corresponding directory under vendor/ and compare it directly. CSV rows are sorted by path, so rebuilding the same data produces the same file and an upstream change leaves a readable diff.

There is no URL on every row. URLs can be derived from templates in the manifest, so repeating them across more than two million rows would add size without adding information. The format stays small enough to inspect and straightforward enough to consume without a specialised client.

Package versions are the reliable address

I keyed the database by package version because real installations can drift from their Magento metapackage. A project may pin or upgrade an individual package. Comparing that directory against the version implied by a release label would produce a confident answer to the wrong question.

Consumers can instead read exact versions from vendor/composer/installed.php and look them up directly. The same choice avoids storing a package repeatedly when several releases share it. Community and Enterprise use one tree, with each shared package version stored once.

The published dataset contains 5,132 package CSVs covering 2,074,555 files across 390 packages. Release maps cover 74 Community releases and 82 Enterprise releases from 2.4.0 to 2.4.9. Those maps are useful conveniences, but the per-package files remain the authoritative form. Flat release bundles are also available, with edition prefixes so Community and Enterprise assets cannot overwrite one another merely because their release numbers match.

Checking the reference before trusting it

A comparison is only as useful as its baseline. The build verifies archives against their published digests before opening them. Six packages without those digests are checked against the git tree at their exact distribution reference instead.

The published manifest contains the SHA-256 of every package CSV and is signed with Ed25519 in minisign format. A consumer can verify the manifest, then check the CSVs against it before using their contents.

Coverage has to remain visible too. This database covers magento/* packages in the 2.4.x series, with installed files outside vendor/magento/ out of scope. A version without reference data must be reported explicitly. Patch attribution needs similar care: a patch naming a changed path provides an explanation to examine, rather than proof that every change in that file is intended. Keeping those distinctions intact is what makes the database useful during an investigation.