Lines Matching +full:right +full:- +full:most
11 ---------------------
16 Documentation/admin-guide/reporting-issues.rst if you are unclear about what
35 instructions, file-system image etc). Binary-only executables are not
57 not being the right one, because it helps understand the bug. When
59 immediately merged (see Documentation/process/submitting-patches.rst).
60 This will save some back-and-forth exchanges if it is accepted, and you
62 only a ``Signed-off-by:`` tag is needed, without ``Reported-by:`` when the
70 --------------------------------
72 It is important that most bugs are handled publicly so as to involve the widest
81 Documentation/process/threat-model.rst, and ought to have been sent through
82 the normal channels described in Documentation/admin-guide/reporting-issues.rst
106 --------------------
108 The most effective way to report a security bug is to send it directly to the
113 anyone, or use of AI-based tools).
122 One difficulty for most first-time reporters is to figure the right list of
131 most of the time return a short list of this specific file's maintainers::
133 $ ./scripts/get_maintainer.pl --no-l --no-r --pattern-depth 1 \
142 $ ./scripts/get_maintainer.pl --no-l --no-r drivers/example.c
148 Here, picking the first, most specific ones, is sufficient. When the list is
149 long, it is possible to produce a comma-delimited e-mail address list on a
152 $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
153 --no-git-fallback --no-substatus --no-rolestats --no-multiline \
154 --pattern-depth 1 drivers/example.c
159 $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
160 --no-git-fallback --no-substatus --no-rolestats --no-multiline \
164 If at this point you're still facing difficulties spotting the right
168 equally be forwarded as-is to the relevant maintainers.
171 ----------------------------------
181 * **Length**: AI-generated reports tend to be excessively long, containing
186 text. Configure your tools to produce concise, human-style reports.
188 * **Formatting**: Most AI-generated reports are littered with Markdown tags.
194 * **Impact Evaluation**: Many AI-generated reports lack an understanding
195 of the kernel's threat model (see Documentation/process/threat-model.rst)
202 * **Reproducer**: AI-based tools are often capable of generating reproducers.
214 Documentation/process/submitting-patches.rst and include a 'Fixes:' tag
222 likely that usage has declined and exposed users are virtually non-existent
229 ------------------
231 Reports are to be sent over e-mail exclusively. Please use a working e-mail
232 address, preferably the same that you want to appear in ``Reported-by`` tags
261 It is much harder to have a context-quoted discussion about a complex
263 :doc:`regular patch submission <../process/submitting-patches>`
270 text by default, please consult Documentation/process/email-clients.rst for
274 ------------------------------------
304 ------------------------------
309 handled by the "linux-distros" mailing list and disclosure by the
310 public "oss-security" mailing list, both of which are closely related
311 and presented in the linux-distros wiki:
312 <https://oss-security.openwall.org/wiki/mailing-lists/distros>
318 days) start from the availability of a fix, while for "linux-distros"
323 of a potential security issue you DO NOT contact the "linux-distros"
326 the requirements that contacting "linux-distros" will impose on you and
330 fix is accepted do not Cc: "linux-distros", and after it's merged do not
334 --------------
342 Non-disclosure agreements
343 -------------------------
346 to enter any non-disclosure agreements.