docs(security): stop pointing vulnerability reports at upstream Prysm - #5
Open
draevik wants to merge 2 commits into
Open
docs(security): stop pointing vulnerability reports at upstream Prysm#5draevik wants to merge 2 commits into
draevik wants to merge 2 commits into
Conversation
SECURITY.md was untouched since the fork and still sends reporters to security@prysmaticlabs.com / Offchain Labs' PGP keys via .well-known/security.txt. A report about a LightChain-specific bug (e.g. the class of consensus bug behind the 2026-08-11 inactivity-ejection incident) currently has no correct destination. This patch rewrites the prose to describe this repo as a LightChain- maintained fork and explains what's still missing: real contact info, and a .well-known/security.txt re-signed with LightChain's own PGP key (the existing file is validly signed by Offchain Labs' key and can't just be hand-edited - a security.txt's signature has to match the key it names, so someone with the authority to speak for LightChain security needs to generate and sign the replacement). Left as explicit TODOs rather than invented values, since I don't have LightChain's real security contact or keys: - security@lightchain.example placeholder contact - .well-known/security.txt / security.pub regeneration This is one slice of tracked issue lightchain-protocol#1 (rebrand fork: README, CONTRIBUTING, CODEOWNERS, templates, and FUNDING still reference upstream Prysm) - splitting it out because the security-contact piece is the one with actual incident-response consequences; the rest is lower-urgency cosmetic cleanup that's easier to review as its own PR. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
team@lightchain.ai confirmed as the real contact - replacing the TODO placeholder from the original patch. PGP fingerprints and .well-known/security.txt remain placeholders pending LightChain regenerating that file with their own key.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this fixes
SECURITY.md was untouched since the fork and still sent reporters to security@prysmaticlabs.com / Offchain Labs' PGP key via .well-known/security.txt. A report about a LightChain-specific bug — including the exact class of bug behind the 2026-08-11 incident — had no correct destination.
What this adds
Rewritten SECURITY.md describing this repo as a LightChain-maintained fork, with a real contact address (team@lightchain.ai) confirmed and filled in.
Still a TODO:
.well-known/security.txtand its PGP key remain Offchain Labs' — that file is cryptographically signed and can't just be hand-edited. Someone with the authority to speak for LightChain security needs to generate and sign a replacement with LightChain's own key.Verification
Doc-only change, no build/test surface. Confirmed the file renders correctly and the contact address is accurate.
Before merging, please
The PGP/security.txt piece is genuinely unresolved — this PR fixes the "wrong org entirely" problem but not the "no working encrypted channel" problem. Worth tracking as a fast follow-up.