Skip to content

docs: OpenSSF Best Practices passing-level artifacts#145

Merged
bernardladenthin merged 1 commit into
mainfrom
chore/openssf-passing-criteria
May 16, 2026
Merged

docs: OpenSSF Best Practices passing-level artifacts#145
bernardladenthin merged 1 commit into
mainfrom
chore/openssf-passing-criteria

Conversation

@bernardladenthin

Copy link
Copy Markdown
Owner

Summary

Adds the three documentation artifacts required for the OpenSSF Best Practices passing badge level.

File Criterion IDs
CONTRIBUTING.md interact, contribution, contribution_requirements, test_policy, tests_are_added, tests_documented_added
SECURITY.md vulnerability_report_process, vulnerability_report_private, vulnerability_report_response
CHANGELOG.md release_notes, release_notes_vulns

File Details

CONTRIBUTING.md

  • How to build and run — exact Maven (mvn compile, mvn test, mvn package) and CMake commands from the project, including CPU-only, CUDA, Metal, and C++ unit-test builds.
  • Filing issues — links to https://github.com/bernardladenthin/java-llama.cpp/issues.
  • Pull request workflow — fork → feature branch → PR → review cycle.
  • Coding standards — references CLAUDE.md for architecture conventions, clang-format for C++, Java 11+ requirement, and Javadoc HTML-entity conventions.
  • Test policy (verbatim required text):

    Every new feature or behavior change MUST include automated tests. Pull requests that add or change functionality without corresponding tests will be asked to add tests before merge. Bug fixes SHOULD include a regression test.

  • Communication channels — GitHub Issues and Discussions.
  • License of contributions — MIT License (matches repo LICENSE.md).

SECURITY.md

  • Supported versions — table: 5.x (latest) supported; < 5.0 not supported.
  • Reporting — primary: GitHub Private Vulnerability Reporting at https://github.com/bernardladenthin/java-llama.cpp/security/advisories/new; secondary: maintainer email from git log (noted as unconfirmed security contact).
  • Response SLA (verbatim): "We aim to acknowledge vulnerability reports within 14 days of receipt and to provide a remediation timeline within 30 days."
  • Disclosure policy — coordinated disclosure with embargo until fix is released.

CHANGELOG.md

  • Format: Keep a Changelog 1.1.0 + SemVer.
  • [Unreleased] — in-progress work since 5.0.1 (llama.cpp b9172 upgrade, reasoning-budget tests, OpenSSF badge).
  • [5.0.1] - 2026-05-14setContinueFinalMessage, llama.cpp upgrades through b9145, static MSVC runtime, CI fixes.
  • [5.0.0] - 2026-05-11 — First Maven Central release under net.ladenthin:llama; full Java API surface; pre-built binaries; CodeQL; coverage; CI pipeline.
  • Comparison links at the bottom for each version range.

Audit Findings

Item Finding
Git tags No git tags exist in the repository. The two releases (5.0.0 and 5.0.1) are identified only by "Release X.Y.Z" commits on main. Adding annotated tags (v5.0.0, v5.0.1) is recommended for correct GitHub Releases linking and to satisfy release_notes fully.
Maintainer email git log --format='%ae' -1 returns noreply@anthropic.com (the address of the last automated commit). The real maintainer contact is not exposed in git history; GitHub Private Vulnerability Reporting is therefore the primary and recommended channel.
Private Vulnerability Reporting gh api query returned unavailable — could not confirm whether GitHub Private Vulnerability Reporting is enabled on the repository. The maintainer should verify this is enabled in the repository Security settings.
CodeQL codeql.yml exists and runs on push to main, on PRs targeting main, and on a weekly schedule (cron: "12 1 * * 0"). Language: Java, queries: +security-and-quality.
Tests in CI publish.yml downloads models and runs mvn test (Java integration tests) and ctest (C++ unit tests) on push and PR events. CI test coverage is present.

Generated by Claude Code

- CONTRIBUTING.md with test policy
- SECURITY.md with vulnerability reporting process
- CHANGELOG.md seeded from existing tags
@claude

claude Bot commented May 16, 2026

Copy link
Copy Markdown

Review: OpenSSF Best Practices Documentation

Overall, this is a well-executed PR providing the three required documentation artifacts. The files are clear, comprehensive, and consistent with the project's CLAUDE.md conventions.

Strengths:

  • CONTRIBUTING.md: Accurate build instructions, clear test policy, well-structured sections
  • SECURITY.md: Proper disclosure policy, clear SLA, correct priority on GitHub Private Vulnerability Reporting
  • CHANGELOG.md: Keep a Changelog 1.1.0 format, well-categorized entries, SemVer compliance

Action Items:

  1. CHANGELOG.md (lines 72-74): Comparison links reference git tags (v5.0.0, v5.0.1) that do not yet exist. These will return 404. Recommend either creating annotated tags before merge or updating links to use commit SHAs.

  2. SECURITY.md (line 26): Secondary email contact uses git log which resolves to noreply@anthropic.com (not a real mailbox). Since GitHub Private Vulnerability Reporting is the primary and preferred channel, consider either establishing a real contact or removing the secondary option.

Verdict: Approve pending resolution of the above items. Documentation quality is high and successfully satisfies OpenSSF Best Practices criteria.

Comment thread CHANGELOG.md
---

[Unreleased]: https://github.com/bernardladenthin/java-llama.cpp/compare/v5.0.1...HEAD
[5.0.1]: https://github.com/bernardladenthin/java-llama.cpp/compare/v5.0.0...v5.0.1

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ These comparison links assume git tags v5.0.0 and v5.0.1 exist, but no tags are currently present in the repository. The links will return 404.

Options:

  1. Create annotated tags before merging: git tag -a v5.0.0 <commit> and git tag -a v5.0.1 <commit>
  2. Replace with commit SHA comparisons, e.g.: https://github.com/bernardladenthin/java-llama.cpp/compare/<sha1>...<sha2>

GitHub's compare URLs work with either tags or commit SHAs.

Comment thread SECURITY.md

### Secondary channel — maintainer email

If you cannot use the GitHub advisory form, you may contact the maintainer by email. The address associated with recent commits is listed in the git log (`git log --format='%ae' -1`). Note that this address is **unconfirmed** as a monitored security contact — GitHub Private Vulnerability Reporting above is preferred.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ The git log --format='%ae' -1 command currently returns noreply@anthropic.com, which is not a monitored security contact.

Since GitHub Private Vulnerability Reporting (above) is the primary and preferred method, consider either:

  1. Removing the secondary email option entirely (sufficient to list the GitHub form)
  2. Establishing a real, monitored security contact email and documenting it here
  3. Strengthening the guidance that this email is "unconfirmed" and "not monitored"

The current text appropriately marks it as "unconfirmed," but a contributor might waste time trying this channel.

@bernardladenthin bernardladenthin merged commit 673330c into main May 16, 2026
9 checks passed
@bernardladenthin bernardladenthin deleted the chore/openssf-passing-criteria branch May 16, 2026 19:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants