lex

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

The repository is not limited to final release snapshots. main is PR-only (ruleset “Protect main”), and work lands through pull requests with reviewable interim commits (for example PRs #17, #29, #30, #31). Feature work such as Douay-Rheims and --json was reviewed on branches before merge.

Repository on GitHub, which uses git. git is distributed.

Each user-facing release has a unique version identifier. The current release is 2.6.8, set in pyproject.toml and npm/lex-cli/package.json, tagged v2.6.8, and shown by lex --version. Earlier identifiers include v2.6.7 through v2.6.0 and v2.5.1.

Releases use Semantic Versioning (MAJOR.MINOR.PATCH), for example 2.6.8. Git tags are v followed by that number (v2.6.8).

Each release is identified in git with a tag of the form v<version>, for example v2.6.8. The “Release tags: owner only” ruleset locks creation, update, and deletion of refs/tags/v*.

Non-trivial release notes file in repository: https://github.com/elcafe7/lex/blob/main/CHANGELOG.md.

N/A: there are no publicly known run-time vulnerabilities in the project results (no GitHub security advisories, no CVE assignments) that were fixed in v2.6.8 or earlier published releases. The criterion allows N/A when there have been no such publicly known vulnerabilities. Dependency findings are handled separately by the OSV release gate and are not this criterion.

Non-trivial SECURITY[.md] file found file in repository: https://github.com/elcafe7/lex/blob/main/SECURITY.md. [osps_do_02_01]

The project uses the GitHub issue tracker for individual issues (currently three open, including #7, #12, and #18, plus a history of closed issues).

In the 2–12 month window before this audit (about 12 Nov 2025 through 12 Sep 2026), the only bug reports were #1 (setup script vs. the system flex lexer) and #2 (missing study-mode data), both opened 20 Apr 2026. Both were acknowledged by a fix in PR #15, merged 3 Nov 2026, and the issues were closed the same day. That is a majority (in fact all) of the bug reports in the window. Newer issues are outside the 2-month floor and are not counted here.

Enhancement requests in the 2–12 month window were answered. PR #4 (“Restore study mode verse context,” opened 28 Jun 2026) was merged 4 Sep 2026. PR #3 (installer) was later closed as superseded by npm and setup.sh. Later enhancements (#16, #18, #12, and the Douay-Rheims work) also received maintainer comments or merges, showing the project responds to enhancement requests.

GitHub Issues and Pull Requests are a public, searchable archive of reports and responses, each with a stable URL, for example https://github.com/elcafe7/lex/issues.

Private vulnerability reports are supported and the private channel is documented. SECURITY.md instructs reporters to use GitHub’s “Report a vulnerability” form at https://github.com/elcafe7/lex/security/advisories/new, and states that only the maintainer and the reporter can see the report. The repository API reports private vulnerability reporting as enabled.

N/A: no vulnerability reports were received in the last 6 months. The GitHub security advisories list for elcafe7/lex is empty. SECURITY.md still commits to an initial response within 7 days and an assessment within 14 days, which meets this criterion’s 14-day bound when a report does arrive.

Lex can be rebuilt from source with documented commands. ./setup.sh creates a Python 3.12+ venv, installs dependencies from pyproject.toml, and installs a lex wrapper. Release archives are built by .github/workflows/release.yml (and scripts/build_npm_release.sh) from a version tag. The npm package @n8te_/lex-cli is a launcher that downloads that release; it builds with ordinary npm tooling.

The project uses common tools: Python setuptools/pip (pyproject.toml), a POSIX shell setup script, GitHub Actions, and npm for the launcher. No proprietary build system is required.

The software is buildable with only FLOSS tools: Python 3, pip/setuptools, git, bash, and Node.js/npm. GitHub Actions is used for official releases but is not required to build or install from a checkout.

The project has a publicly released FLOSS automated test suite in the same repository: 17 Python modules under tests/ (unittest) covering JSON/plain output, option aliases, Bible packaging, path boundaries, security gates, and more, plus Node’s test runner under npm/lex-cli/test/. The suite is invocable as python3 -m unittest discover -s tests and, for the launcher, npm test.

The Python suite uses the standard library unittest runner: python3 -m unittest discover -s tests, documented in the Safe Change Checklist in docs/components/LEX_CLI.md. The npm launcher uses the standard npm test script (node --test), documented in npm/lex-cli/package.json and docs/NPM_PUBLISHING.md.

The project has an informal policy (allowed by this criterion, including “word of mouth”) that major new functionality should land with automated tests. That policy is visible in practice on recent major changes, as required to also meet tests_are_added. It is not yet written down in contribution instructions; documenting it in CONTRIBUTING.md would also satisfy tests_documented_added.

Recent major changes on main included new tests. PR #17 (--json / --plain, merged 10 Nov 2026) added tests/test_json_output.py and tests/test_option_aliases.py (and npm/lex-cli/test/launcher.test.js updates). PR #31 (Douay-Rheims 1899, merged 10 Nov 2026) added tests/test_bible_versions.py, tests/test_package_bible.py, and tests/fixtures/dra_sample.vpl. Security-gate work added tests/test_gitleaks_gate.py and tests/test_bandit_gate.py.

The sole primary developer (elcafe7) is familiar with the codebase, makes the releases, and receives private vulnerability reports. Work on main through 2026 applies the design principles this criterion lists: fail-safe defaults and fail-closed release gates (OSV, Bandit, Gitleaks, and the VirusTotal guard); complete mediation and allowlist input validation for untrusted paths (scripts/safe_paths.py, npm archive entry checks, font-path allowlists); least privilege (workflow default permissions contents: read); open design (SECURITY.md and docs/RELEASE_VERIFICATION.md are public); and a limited attack surface (local-first CLI, no network service). That is evidence the primary developer knows how to design secure software as this criterion requires.

The same primary developer has identified and mitigated common errors in this kind of software (a Python/JS local CLI that unpacks archives and reads untrusted paths): CodeQL py/path-injection was fixed in PRs #21 and #29 (0 open CodeQL alerts on main); a polynomial ReDoS finding in clean_strongs_definition was fixed; the npm launcher rejects absolute, .., symlink, and hard-link archive entries; secrets are scanned with Gitleaks 8.30.1 and GitHub secret scanning plus push protection. Those are concrete counters to path traversal, ReDoS, unsafe extraction, and credential leakage.

Where Lex uses cryptography, it uses only publicly published, expert-reviewed algorithms: SHA-256 for manifest and release-archive integrity (Python hashlib, Node crypto.createHash("sha256"), sha256sum) and TLS via standard HTTPS clients when downloading releases or talking to the npm registry. It does not invent or default to unpublished algorithms.

Lex is not a cryptography product. Integrity checks call existing libraries (Python hashlib, Node’s crypto module) and HTTPS/TLS is provided by the platform (curl, Node HTTPS, pip/npm). The project does not implement its own hash, TLS, or cipher code.

The cryptographic functionality the software depends on (SHA-256 via hashlib and Node crypto, TLS via ordinary HTTPS clients) is implementable with FLOSS libraries. No proprietary crypto is required.

N/A: Lex does not generate or negotiate cryptographic keys. It only hashes files with SHA-256 and relies on platform TLS for transport. There is no application-level key length to configure.

Default integrity and transport mechanisms do not depend on broken algorithms (MD4, MD5, single DES, RC4, or similar). File integrity uses SHA-256. Downloads use HTTPS. Checksums are not accepted over unauthenticated HTTP.

Defaults do not depend on algorithms or modes with known serious weaknesses (for example SHA-1 or encryption without integrity). Integrity checking is SHA-256; transport is standard TLS via HTTPS.

N/A: Lex does not implement key-agreement protocols. Session keys and PFS, when they apply, are properties of the HTTPS servers and TLS libraries used to fetch releases (GitHub, npm), not of Lex itself.

N/A: Lex does not store passwords for authentication of external users. It is a local-first CLI with no user-account system.

N/A: Lex does not generate cryptographic keys or nonces. The only crypto it performs on the client is SHA-256 hashing of files for integrity checks.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Release checksums (lex-v*.tar.gz.sha256 and SHA256SUMS) are published and retrieved only over HTTPS from GitHub, not over http. The npm launcher compares the archive to that SHA-256 hash before use. Releases also have Sigstore/GitHub attestations, so the hash is not the only integrity check.

There are no unpatched publicly known medium or higher severity vulnerabilities more than 60 days old. GitHub security advisories: none. Open Dependabot alerts: none. Open CodeQL alerts on main: none (33 fixed, 15 dismissed historically). The release workflow fails closed on OSV findings at CVSS 7.0 or higher, and also holds the release for lower-rated and unscored advisories, so a published v2.6.8 report records 0 known vulnerabilities.

There are currently no known critical vulnerabilities in Lex. SECURITY.md says confirmed high or critical issues are aimed at a patch release within 30 days. The release OSV gate blocks publication if a CVSS 7.0+ (high or critical) advisory is present.

Public repositories are scanned so that valid private credentials are not leaked. GitHub secret scanning and push protection are enabled (0 open secret-scanning alerts). Gitleaks CLI 8.30.1 (checksum-verified, always --redact) runs on pull requests, pushes to main, weekly, and as a blocking release gate; the introduction full-history scan (150 commits) found 0 leaks. .gitleaks.toml only allowlists proven historical false positives, each with a reason.

Static analysis (beyond compiler warnings) is applied before production releases. GitHub CodeQL default setup is configured for Python and GitHub Actions (default query suite, weekly plus analysis of main and pull requests). Bandit (Python SAST) runs on every pull request, every push to main, weekly, and as a blocking job in release.yml: any medium or high finding, at any confidence, fails the release. Evidence: .github/workflows/bandit.yml, .github/workflows/release.yml, and CodeQL analyses on main at 0559f49.

Both tools used for static_analysis look for common vulnerability classes. CodeQL’s default suite includes path injection, ReDoS, and similar queries (historically raised and fixed on this repo). Bandit is a security-focused Python analyzer whose rules cover injection, unsafe subprocess use, and related issues.

Medium and higher severity exploitable findings from static analysis are fixed or otherwise closed before they remain on main. CodeQL on main currently has 0 open alerts (33 fixed, 15 dismissed with recorded dispositions). Bandit medium and high findings block the release job, so a published release cannot carry them. Recent examples: PR #21 (path-injection reachable from untrusted input), PR #29 (alert #58 in the LXX lemma import), and the DRA packager confinement for alert #65 in PR #31.

Static analysis runs more often than just at release. Bandit and Gitleaks run on every pull request and every push to main, plus weekly. CodeQL default setup analyzes main and pull requests and is scheduled weekly.

N/A: the software produced by the project is written in Python, JavaScript, and Shell, not in a memory-unsafe language such as C or C++. GitHub language stats are Python (~627k), JavaScript (~46k), and Shell (~51k).

N/A: the project is not yet running dynamic analysis in the sense of the dynamic_analysis criterion (no fuzzer, and no published 80%+ branch-coverage suite), so no medium or higher severity exploitable vulnerabilities have been discovered that way.