search

tukaani-project / xz

XZ Utils
https://tukaani.org/xz/
Other
561 stars 104 forks source link

Update SECURITY.md #117

Closed JohnDoe1001 closed 5 months ago

JohnDoe1001 commented 5 months ago

Added the requirement to include security info, reproduction steps, estimated severity and encouraging people to report the issue publicly.

JohnDoe1001 commented 5 months ago

I think that every security exploits should be reported publicly and clearly, so that the community & developers could fix it ASAP.

What’s your opinion?

Larhzu commented 5 months ago

Fast full disclosure was the only sensible thing with the backdoor incident. With more typical security issues it seems sensible to try to prepare a fix first so that fewer bad actors will have time to use the information. So one has to use some common sense when one finds a security issue.

I assume that people are capable of providing the required information without detailed handholding in a form of a bullet point list. I asked Jia to simplify the file and also the issue and PR templates and I don't want to restore such cruft. If something is missing from a report, it's possible to ask for more information.

It seems that SECURITY.md still keeps attracting posts and this makes me wonder if the existence of that file really does more good than bad. People had no trouble reporting issues via email before the project was on GitHub. (Or maybe email should be the only method listed in SECURITY.md as it's simpler than the GH feature.)

For example, CVE-2022-1271 (ZDI-CAN-16587) was reported to me and then I reported it to GNU gzip maintainers since the bug was inherited to xzgrep from zgrep. It took several emails to polish the fix and coordinate the disclosure with xz, gzip, and downstream distros (distros via mailing list on openwall.com). I think the process worked really well.