Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 14:13:35 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #4734] [FEAT]: Improving release integrity strength #2991

New Issue
Closed
opened 2026-02-22 18:32:10 -05:00 by yindo · 2 comments
yindo commented 2026-02-22 18:32:10 -05:00
Owner
Copy Link
Copy Source

Originally created by @jodiecunningham on GitHub (Dec 7, 2025).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/4734

What would you like to see?

Hi AnythingLLM team, would you consider some changes for strengthening the integrity guarantees of your binary and source distributions?

Observations today:

  • Today, the binary installers, docker images and AppImages appear to be unsigned, and as far as I can tell are not mentioned/linked anywhere in GitHub, and the binaries are not versioned for release.
    ( I checked the AppImage for signatures with ./AnythingLLMDesktop.AppImage --appimage-signature and checked for a dmg signature by looking for the hex sequence of fade 0cc0 (or its reverse endianness 0c0c adfa), but did not see any codesign blocks. )
  • Additionally, the GitHub release zips/tars do not include checksums or signatures. This makes it difficult for users to verify authenticity.
  • Release tags were once created from signed commits as verified on GH, but no longer show as verified.
  • Docker images do not publish an SBOM.

Concrete improvements that would materially increase distribution security:

  1. Publish SHA-256 checksums for every artifact directly in each GitHub Release.
  2. Provide cryptographic signatures for all artifacts, binaries and images using either GPG or sigstore/cosign.
  3. In CI, generate an SBOM for docker images with something like syft anythingllm:{tag} -o json > sbom.json and perform in-toto attestation with cosign attest --predicate sbom.json for the docker images.
  4. Attach all binaries to GitHub Releases so the artifacts are versioned and immutable.
  5. Sign release tags and release commits so they appear as Verified on GitHub again
  6. Build and publish release artifacts through CI with reproducible workflows, optionally generating SLSA provenance.
  7. Use GitHub immutable release tags

I know code-signing certs are expensive - I'm willing to pitch in on that and I bet I could round up some others who will too.

Originally created by @jodiecunningham on GitHub (Dec 7, 2025). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/4734 ### What would you like to see? Hi AnythingLLM team, would you consider some changes for strengthening the integrity guarantees of your binary and source distributions? Observations today: - Today, the binary installers, docker images and AppImages appear to be unsigned, and as far as I can tell are not mentioned/linked anywhere in GitHub, and the binaries are not versioned for release. ( I checked the AppImage for signatures with `./AnythingLLMDesktop.AppImage --appimage-signature` and checked for a dmg signature by looking for the hex sequence of fade 0cc0 (or its reverse endianness 0c0c adfa), but did not see any codesign blocks. ) - Additionally, the GitHub release zips/tars do not include checksums or signatures. This makes it difficult for users to verify authenticity. - Release tags were once created from signed commits as verified on GH, but no longer show as verified. - Docker images do not publish an SBOM. Concrete improvements that would materially increase distribution security: 1. Publish SHA-256 checksums for every artifact directly in each GitHub Release. 2. Provide cryptographic signatures for all artifacts, binaries and images using either GPG or sigstore/cosign. 3. In CI, generate an SBOM for docker images with something like `syft anythingllm:{tag} -o json > sbom.json` and perform in-toto attestation with `cosign attest --predicate sbom.json` for the docker images. 4. Attach all binaries to GitHub Releases so the artifacts are versioned and immutable. 5. Sign release tags and release commits so they appear as Verified on GitHub again 6. Build and publish release artifacts through CI with reproducible workflows, optionally generating SLSA provenance. 7. Use GitHub immutable release tags I know code-signing certs are expensive - I'm willing to pitch in on that and I bet I could round up some others who will too.
yindo added the enhancementfeature request labels 2026-02-22 18:32:10 -05:00
yindo closed this issue 2026-02-22 18:32:10 -05:00
yindo commented 2026-02-22 18:32:10 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Dec 9, 2025):

For release checksums: https://github.com/Mintplex-Labs/anything-llm/issues/4743

Attach all binaries to GitHub Releases so the artifacts are versioned and immutable.

Docker images do not publish an SBOM.

https://github.com/Mintplex-Labs/anything-llm/blob/b96988aae991038a715813134d6da872d8e0b5eb/.github/workflows/build-and-push-image-semver.yaml#L75

We have the flag enabled, are SBOMs not being found? We even do attestations so the SBOM must be available?

@timothycarambat commented on GitHub (Dec 9, 2025): For release checksums: https://github.com/Mintplex-Labs/anything-llm/issues/4743 > Attach all binaries to GitHub Releases so the artifacts are versioned and immutable. > Docker images do not publish an SBOM. https://github.com/Mintplex-Labs/anything-llm/blob/b96988aae991038a715813134d6da872d8e0b5eb/.github/workflows/build-and-push-image-semver.yaml#L75 We have the flag enabled, are SBOMs not being found? We even do attestations so the SBOM must be available?
yindo changed title from [FEAT]: Improving release integrity strength to [GH-ISSUE #4734] [FEAT]: Improving release integrity strength 2026-06-05 14:49:42 -04:00
yindo commented 2026-06-05 14:49:42 -04:00
Author
Owner
Copy Link
Copy Source

@jodiecunningham commented on GitHub (Apr 4, 2026):

I was wrong on that, I was looking for a signed attestation. So there's an attestation, but they're just not signed attestations. The recommendation I provided did include steps for a signed attestation.

Someone was asking me about this so I was following up on it. Have any of these been implemented?

<!-- gh-comment-id:4187275831 --> @jodiecunningham commented on GitHub (Apr 4, 2026): I was wrong on that, I was looking for a signed attestation. So there's an attestation, but they're just not signed attestations. The recommendation I provided did include steps for a signed attestation. Someone was asking me about this so I was following up on it. Have any of these been implemented?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label enhancement feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#2991
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?