[WIP] Add a SECURITY.md #772
Conversation
|
We should probably follow the existing guidelines for responsible disclosures such as the ones outlined here: https://www.hackerone.com/blog/Vulnerability-Disclosure-Policy-Basics-5-Critical-Components In addition we'll need to have some guidelines on how to triage the issue since this is not a single software project but more of an umbrella project that may have issues itself, but more likely should defer to the impacted implementations and their disclosure policy. |
| * 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 ? |
There was a problem hiding this comment.
That's between the project you're disclosing to and the discloser, not something general across implementations, no?
There was a problem hiding this comment.
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.
|
I think it depends, there are two layers there. Potential vulnerability in the spec itself need some kind of disclosure that makes sure all major implementations are aware of the issue (and it probably shouldn't be the security researcher's job to manage contacting each implementation separately). For implementation-specific issues though, we should redirect to each project's SECURITY.md |
|
I do think there are multiple issues that this SECURITY.md may try to address:
|
|
For eclair, it's security@acinq.fr with the following GPG key: |
|
For |
|
For c-lightning, we can use security@blockstream.com |
|
Links to docs on Github's security policy/advisory feature (it's new-ish): |
|
For electrum, it's electrumdev@gmail.com with GPG key: |
|
I’m still very interested in Lightning security flaws, though this is not my responsibility if they’re not shared and fixed across the ecosystem. |
While this is the responsibility of each Lightning implementation to have a security incident response to fix implementation-specific flaws, I think this is still valuable to a security incident response at the spec-process, as experience has revealed you have common flaws shared between implementations due to lack of documentation of the spec (CVE-2019-12998, CVE-2019-12999 and CVE-2019-13000 on missing checks of confirmed funding UTXOs). Beyond, a reliable communication channel is very valuable in case of cross-layer security flaws, e.g in the future in case of issues with the nversion=3 policy signaling mechanism preventing the propagation of time-sensitive LN transactions across the transaction-relay network on the base-layer. In this hypothetical security incident, we’ll need coordination not only between Lightning implementation maintenance team though potentially with full-nodes maintenance team like Bitcoin Core or btcd. I’ll propose a documented communication channel for security incident response coordination across the Lightning ecosystem soon. |
|
See corresponding mail on the ml. |
|
will stay at least at least for doing transition with younger generation of devs for few more months. still aiming to focus back on base layer solving sec issues where they should be solved. see mail. |
|
closing it for good. t-bast or lisa have my trust to handle ln security coordination in the future. matt, laolu and rusty are medium standard on this regard from my 4 years of experience working with them. |
After disclosure of mempool-congestion attacks, some people have pointed out it would be better to have some guidelines in case of future cross-implementation vulnerabilities like a spec wrong-doing or a first-layer breakage.
This is WIP proposal trying to laid out this more. Next step is obviously to gather people opinions during a meeting.