diff options
author | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
commit | 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (patch) | |
tree | 0bba044c4ce775e45a88a51686b5d9f90697ea9d /Documentation/SecurityBugs |
Linux-2.6.12-rc2v2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Diffstat (limited to 'Documentation/SecurityBugs')
-rw-r--r-- | Documentation/SecurityBugs | 38 |
1 files changed, 38 insertions, 0 deletions
diff --git a/Documentation/SecurityBugs b/Documentation/SecurityBugs new file mode 100644 index 000000000000..26c3b3635d9f --- /dev/null +++ b/Documentation/SecurityBugs | |||
@@ -0,0 +1,38 @@ | |||
1 | Linux kernel developers take security very seriously. As such, we'd | ||
2 | like to know when a security bug is found so that it can be fixed and | ||
3 | disclosed as quickly as possible. Please report security bugs to the | ||
4 | Linux kernel security team. | ||
5 | |||
6 | 1) Contact | ||
7 | |||
8 | The Linux kernel security team can be contacted by email at | ||
9 | <security@kernel.org>. This is a private list of security officers | ||
10 | who will help verify the bug report and develop and release a fix. | ||
11 | It is possible that the security team will bring in extra help from | ||
12 | area maintainers to understand and fix the security vulnerability. | ||
13 | |||
14 | As it is with any bug, the more information provided the easier it | ||
15 | will be to diagnose and fix. Please review the procedure outlined in | ||
16 | REPORTING-BUGS if you are unclear about what information is helpful. | ||
17 | Any exploit code is very helpful and will not be released without | ||
18 | consent from the reporter unless it has already been made public. | ||
19 | |||
20 | 2) Disclosure | ||
21 | |||
22 | The goal of the Linux kernel security team is to work with the | ||
23 | bug submitter to bug resolution as well as disclosure. We prefer | ||
24 | to fully disclose the bug as soon as possible. It is reasonable to | ||
25 | delay disclosure when the bug or the fix is not yet fully understood, | ||
26 | the solution is not well-tested or for vendor coordination. However, we | ||
27 | expect these delays to be short, measurable in days, not weeks or months. | ||
28 | A disclosure date is negotiated by the security team working with the | ||
29 | bug submitter as well as vendors. However, the kernel security team | ||
30 | holds the final say when setting a disclosure date. The timeframe for | ||
31 | disclosure is from immediate (esp. if it's already publically known) | ||
32 | to a few weeks. As a basic default policy, we expect report date to | ||
33 | disclosure date to be on the order of 7 days. | ||
34 | |||
35 | 3) Non-disclosure agreements | ||
36 | |||
37 | The Linux kernel security team is not a formal body and therefore unable | ||
38 | to enter any non-disclosure agreements. | ||