When you can't upgrade: open source examples of Endor Patches | Blog | Endor Labs

What it is

The endor-patches GitHub repository (github.com/endorlabs/endor-patches) with two complete worked examples of Endor Patches — security backports for woodstox-core and jgit — plus the exact procedure to audit and reproduce each one yourself. The summary names the artifacts; this page tells you how to verify them and what verification reveals about these two specific patches.

How it works

Every patch follows three stated principles: Minimal (only CVE-neutralizing changes, no refactoring), Compatible (drop-in JAR, same API, one-line pom.xml change), Verified (full upstream test suite passes before publish). Each commit in a patch is typed: COMMIT_TYPE_UPSTREAM (backported from the maintainer, verifiable by SHA on GitHub) or COMMIT_TYPE_MANUAL (written by Endor Labs, readable in full in patch_files). This typing is what makes the manual-vs-upstream trust distinction auditable.

What to do

To audit a patch independently:

• Open security_attestation.json and find entries with "fix_type": "FIX_TYPE_VULN" — those patch_files are the security diffs.
• For each COMMIT_TYPE_UPSTREAM commit, look up the SHA on GitHub and confirm the diff matches.
• For each COMMIT_TYPE_MANUAL commit, read the change and judge it yourself.

To reproduce the build: each patch directory ships a source tarball with a Bazel WORKSPACE pinning upstream source to a commit SHA, build patches, vuln patches, and Bazel config. Extract, follow the included README.md, build with Docker + Bazel, and compare the output against the SHA256 in SHA256SUM.txt. Builds are hermetic — same source, same artifact.

What this tells you about the two patches

The page states the audit outcome for each, which is the useful pre-digested finding:

• woodstox-core: all commits are pure upstream backports (nothing hand-written).
• jgit: the manual commits are build-system changes only — no security-sensitive code touched.

So an engineer weighing these two can skip straight to a shorter review than the general "read every manual diff" case implies.

Caveats

The page does not name the specific CVEs or versions for either example — you learn those only by opening the repo. It also references a separate Henrik Plate article, "How Endor Patches Are Built and Tested," for the engineering/testing workflow; this repo is positioned as the verifiability layer on top of that, not a full description of how patches are authored. These are described as "representative examples," not the full patch catalog.