[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. |
TheBlueMatt
left a comment
TheBlueMatt
left a comment
There was a problem hiding this comment.
In general, I think this is something best left to discloser<->implementation relationships. We should list links to disclosure policies of the various implementations here and note that any broad issues should involve discussion there.
| * 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?
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
|
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 |
This comment was marked as abuse.
This comment was marked as abuse.
|
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: |
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
7 participants
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.