jitsi/jitsi-meet: technical due diligence, read from its repository

1 model weight files are stored in git itself, not in LFS, DVC or a model hub. Every clone carries them, the history keeps every version for good, and nothing records which run or data produced them.

217 test files against 2,423 source files (9.0%). This does not measure whether the tests are good, only whether enough of them exist for the codebase to be changed safely by someone who did not write it — which is exactly the situation after an acquisition.

package.json declares 117 direct dependencies. Each one is a maintenance obligation, a supply-chain surface and a potential licence question that transfers with the asset. The count says nothing about whether any given dependency was a good choice; it says how many such choices a buyer inherits.

Of 843 fixes in the last 24 months, 168 touched a test. A fix without the test that would have caught the bug can quietly come back, and the suite never learns from what went wrong.

Strings shaped like credentials appear only where fakes are usual: test fixtures, examples, documentation, placeholders and local stacks. They are almost always fakes. Ask someone to confirm that none of them works anywhere, because a real key in a development file is still a real key.

38 of 1,161 locked dependencies match 91 published advisories in OSV, 32 of them rated high or critical. A lockfile says which version is installed, not whether the flawed code is reachable from this product, so each needs a look. Most are fixed by an upgrade, and the advisory names the version. This lockfile pins development tools alongside what ships and does not say which is which, so some of these may never reach a user.

Nothing references a structured logging library. Logs that are written to be read by a person are not searchable by a machine, which means incident response here is proportional to how well someone remembers the codebase rather than to what the tooling can find.