Please report security problems privately, not in a public issue: use the Report a vulnerability button on the repository's Security tab. Only the maintainer sees it.

This is a small project maintained in spare time. I will read and answer reports as soon as I can, but cannot promise a response time.

What counts: a way for a crafted system file or command-line argument to make the tools do something they should not (run code, write outside the requested output file, and similar). The tools read local files, make no network connections and use only the Python standard library, so the attack surface is small. The one exception is sfic-scan-charts, which needs optional packages and Tesseract: it makes no network connection and runs only on your computer, but it reads PDFs with a native library, so run it only on scans you made yourself.

If the checker misses a cross-operation, or the solver returns a key that conflicts, that is a correctness bug, not a vulnerability. Please open a regular issue with a made-up example that reproduces it. A bug report never needs your real keys, so do not include them.

Issues, pull requests, discussions and security reports can be public or can leak. Do not include real bittings, real system files, or anything that identifies a building, its residents or its keys. Anyone who sees them could learn how a real lock system is keyed. Use system.example.json or invented values. If a report seems to need real data, describe the situation in words instead and we will find a safe example together.

A real system file lists the bittings of a real key system. Treat it like a password file: keep it outside any repository (this one ignores .json, .csv and .txt files and refuses to commit them, as it does PDFs and images, but your other repositories will not), and restrict who can read it. Scans and photos of pinning charts are just as sensitive as the system file.

The project is pre-1.0: only the latest commit on main is supported.