On 6/1/22 15:38, Jonathan Corbet wrote: > I submit that you are breaking your own rule by putting this stuff > at the top of the document. I'm not really convinced that you need > it at all - we don't normally include these sort of instructions - > but if it has to be here I would put it at the end. Agreed -- I've moved it to the bottom for now as I think there's value in expressing the higher-level design of something, but I'm open to editing/trimming it down and/or moving it to the changelog. I guess I had the HTML docs more in mind when editing this document as I think most people probably read this from kernel.org. But you're right that we shouldn't forget the plaintext readers. On 6/1/22 18:58, Jonathan Corbet wrote: > Vegard Nossum <vegard.nossum@xxxxxxxxxx> writes: >> +Note that the main interest of the kernel security list is in getting >> +bugs fixed; CVE assignment, disclosure to distributions, and public >> +disclosure happens on different lists with different people. > > Adding "as described below" or some such might be helpful for readers > who are mostly interested in those things. Done. >> +Here is a quick overview of the various lists: >> + >> +.. list-table:: [...] > Please don't use list-table, that's totally unreadable in the plain-text > format. How about something like: > > =============================== ===== ================= =============== > List address Open? Purpose Members > =============================== ===== ================= =============== > security@xxxxxxxxxx no Reporting Trusted kernel > developers > Patch development > linux-distros@xxxxxxxxxxxxxxx no Coordination Distribution > representatives > CVE assignment > Patch development > Testing > Backporting > oss-security@xxxxxxxxxxxxxxxxxx yes Disclosure General public > =============================== ===== ================= =============== > > (Note I haven't tried to format this, there's probably an error in there > somewhere). Great suggestion, I just fixed it up a tiny bit. >> +The following sections give a step-by-step guide to reporting and >> +disclosure. >> + >> +Contacting the security list >> +---------------------------- >> + >> +As it is with any bug, the more information provided the easier it will >> +be to diagnose and fix; please review the procedure outlined in >> +Documentation/admin-guide/reporting-issues.rst if you are unclear about >> +what information is helpful. Any exploit code is very helpful and will >> +not be released without consent from the reporter unless it has already >> +been made public. >> + >> +The security team does not assign CVEs, nor does it require them >> +for reports or fixes. CVEs may be requested when the issue is reported to >> +the linux-distros list. >> + >> +**Disclosure.** The security list prefers to merge fixes into the >> +appropriate public git repository as soon as they become available. > > More to the point, the idea is to get *review attention* onto the > patches, presumably before they are commited to some repo, right? > That's my understanding from the oss-security discussion, anyway. So > the first disclosure may not be when it shows up in a repo, as suggested > here. True. I've changed it to include reviews and testing: +**Disclosure.** The security list strongly prefers to have patches posted +for review and testing on public mailing lists and and merged into the +appropriate public git repository as soon as they become available. >> +Once a patch has been developed, you are encouraged to contact the >> +linux-distros list; see below. > > Nit: "see below" seems unnecessary when "below" is the next line down Removed. >> +Contacting the linux-distros list >> +--------------------------------- [...] >> +**List rules.** The main rules to be aware of when contacting the >> +linux-distros list are: > > So this seems certain to go out of date when the other list's rules > change. I wonder if it would be better just to tell readers they > need to be aware of that list's rules and give a pointer? I get your point, but I think this underestimates the value of having a single place for reporters to get an overview of the full process that we want them to follow in the ideal case. It's been a little bit of a problem that people post to the list without fully understanding how the list operates. Many reporters copy the list and are surprised to learn that they are supposed to disclose something to oss-security. I think the main pain points have been addressed in the rewrite by making it clear that everything sent to the list must also be made public within some interval from when it is posted to the list, and also that it is preferable to contact s@k.o first, separately, and ensure there's a patch before engaging distros. In my mind, having the full process and the most important points for the linux-distros list in the kernel documentation also ensures that reporters, Linux kernel developers, the security list people, and the linux-distros people are all on the same page with what is expected of each other -- and that everybody is in the loop when changes are made. In a sense, it's harder to have conflicting policies if they're all (at least the main points) expressed in a single document. (As we also wrote on the oss-sec thread, having linux-distros in the loop on security bugs is incredibly valuable for distros, which is why it's also in our interest to make sure the recommended process is to include linux-distros in the official reporting process -- but not at the expense of forcing premature disclosures or causing friction between the lists/groups.) That said, Solar was expressing a similar idea as you in <https://www.openwall.com/lists/oss-security/2022/05/24/2>, albeit for a different reason. So I don't know. I wouldn't go against a consensus either way, but I would hope that we could try this and see whether keeping it up to date turns out to be a bigger issue than reporters doing the wrong thing (from our point of view). Thoughts? (Solar?) Thanks for the feedback! Vegard
