Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Add a SECURITY.md #772

Closed
wants to merge 1 commit into from
Closed

[WIP] Add a SECURITY.md #772

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions SECURITY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
If you find any bugs, vulnerabilites or undefined behavior while reviewing a Lightning
implementation we invite you to conform to the following guidelines:

* First, with a best-effort, identify and try to reproduce the behavior in a faithful way,
with commit and configuration
* If the faultive behavior is implementation-specific, please contact maintainers of the project
following their security policy (Eclair, LND, C-lightning, Rust-Lightning, Electrum, ptarmigan) XXX link them
* We invite to keep in mind that faultive behavior may be due to a dependency. In this case you
may have other non-LN bitcoin projects using it, their maintainers should be informed
* If the faultive behavior is due to the spec or first-layer, please contact at least maintainers of each project and express your concerns
* Leading to patching one implementation may raise awareness on critical part of other implementation, themselves at risk, therefore to prevent such outcome,
ensure the party disclosed to coordinate with the rest of ecosystem if necessary
* You should try to scope the difficulty of exploitation and class of LN nodes affected (routing vs non-routing).
* A vulnerability may lead to the non-exhaustive non-disjunction cases: fund loss, fund freeze, third-party channel closure, netsplit, privacy leak, channel DoS, feerate inflation, ...
* Be patient, people invovled are likely spread on a timezone different than yours or travelling without full access to their security PGP keys. However if you don't get any response after a week, please try to contact them via a different communication channel asking them to check their security mailbox.
* Keep in mind you're dealing with people money, and mistakes can lead to funds loss. Act with caution.

* XXX: (timeline and deployment, type of disclosure ?
Copy link
Collaborator

Choose a reason for hiding this comment

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

That's between the project you're disclosing to and the discloser, not something general across implementations, no?

Copy link
Author

Choose a reason for hiding this comment

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

My concern is if we have a vulnerability common to all implementations due to a spec wrongdoing or anything else like this, we do want a clear disclosure path to avoid some implementation doing a partial disclosure and urgent upgrade and therefore attracting awareness on other ones.

Also, LN security model being a bit different that's worthy to have maybe longer timeline and some implementation may have different vendor policies. So for implementation A it would take 3 months to upgrade 90% of nodes when for implementation B it would take 6 months to reach same percentage.


Above all, we deeply thanks you to take part to the review and security process of the Lightnig Network and dedicating time to build a more trustworthy off-chain layer.