Re: [PATCH v2] Documentation/security-bugs: overhaul

[Vegard Nossum <vegard.nossum@oracle.com>]

On 6/7/22 11:07, Will Deacon wrote:
> On Mon, Jun 06, 2022 at 09:48:50PM +0200, Vegard Nossum wrote:
>> +**Disclosure.** The security list strongly prefers to have patches posted
>> +for review and testing on public mailing lists and and merged into the
> 
> typo: "and and"

Fixed, thanks.

>> +appropriate public git repository as soon as they become available.
>> +However, in exceptional cases, you or an affected party may request that
>> +the patch be withheld for some days; as a rule, the maximum is 7 days.
>> +Only in truly exceptional cases will the security list consider deferring
>> +the publication of a fix beyond this, and the only valid reason for doing
>> +so would be to accommodate the logistics of QA and large scale rollouts
>> +that require release coordination.
> 
> I think there's a semantic change here, and I tend to feel that these sort
> of changes would be much easier to review if the semantic changes were done
> separately from the reformatting or the addition of entirely new sections.
> As it stands, the whole doc is effectively being replaced, but what we
> currently have has been tweaked over the years (often as a result of
> spirited debate) and I'm keen not to open up some of the issues we had
> previously if at all possible.

My goal with the rewrite was to clarify the policy for reporters,
include the updates to linux-distros policy, and turn the document into
more of a step-by-step guide for reporters that corresponds to both what
happens in reality and what the "ideal" flow for a security bug report
is. It's not my intention here to modify the policy itself.

My impression of the current document is that it's a little bit chaotic
and difficult to follow -- perhaps exactly because of tweaking over the
years rather than writing for the reader/reporter.

> Case in point: the new text above removes both the mention of "calendar
> days" which is a useful disambiguation as well as removing the "extension
> to 14 calendar days" which is a useful upper bound. Why are you removing
> these?

"calendar days" -- this got changed just to make it more readable. Maybe
it's just me and my personal experience, but this wording seemed
redundant. Why would "day" default to anything but a calendar day except
in a business setting (which this is not)?

That said, I agree if this has been contentious in the past there is
value in being explicit. My goal was maximum clarity, so if this could
be unclear to anybody then it's better to leave it in -- however, if I
leave it in, then I should also change all other occurrences of the word
"days" to also be "calendar days" so that the reader is not left
wondering why it's specified as calendar days in one place and
unspecified in another.

"extension to 14 calendar days" -- I changed this after comments from
Willy who said too many people took this to mean that 7 days was the
norm and that 14 days was still an acceptable proposal in most cases. I
_think_ (but I'm not sure) that 14 days is not even really the absolute
maximum, depending on the severity of the bug.

In my mind, this document is more for reporters of security issues and
less a formal standard for the security list members and so the "Only in
truly exceptional cases will the security list consider deferring the
publication of a fix beyond this" already covers what happens if
somebody wants or request that the patch be withheld for more than 7
days -- it's basically up to the list members to decide whether to
honour requests beyond the stated maximum.

Any new thoughts with all this in mind..?

> You have also removed use of the term "robust fix", which I think was
> useful. That is, security@ isn't going to post a broken patch to the public
> list just because it's been available for 7 days; that period should only
> begin (if it is even needed) once the fix is ready to go.

Okay, how about changing it like this:

-**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.
+**Disclosure.** When a robust patch or patchset has been developed, the
+security list strongly prefers to have these posted for review and testing
+on public mailing lists and merged into the appropriate public git
+repository as soon as possible.

It's always possible to go into more detail about what "robust" means
exactly or who makes this decision (and how), but I think brevity does a
lot to keep things readable.

Thanks for the comments.


Vegard