Difference between revisions of "Kernel Self Protection Project/Get Involved"
(update mailing list) |
(update list descriptions, tweak capitalization, and split up contribution guildeline better) |
||
| Line 1: | Line 1: | ||
Want to get involved in the [[Kernel Self Protection Project]]? [http://vger.kernel.org/vger-lists.html#linux-hardening | Want to get involved in the [[Kernel Self Protection Project]]? Here's how: | ||
- Join the [http://vger.kernel.org/vger-lists.html#linux-hardening upstream Linux kernel hardening mailing list] where development, maintenance, and administrivia happen. (And visit the [https://lore.kernel.org/linux-hardening/ list archive].) | |||
- Join the [https://www.openwall.com/lists/kernel-hardening/ general Linux kernel hardening mailing list], where new hardening topics are discussed. (And visit the [https://lore.kernel.org/kernel-hardening/ list archive].) | |||
- (Optional) Join the <code>##linux-hardened</code> IRC channel on [https://freenode.net/ freenode]. | |||
= Introduce Yourself = | = Introduce Yourself = | ||
Send an email to introduce yourself! Then pick an area of work from | Send an email to introduce yourself! Then pick an area of work from the [https://github.com/KSPP/issues issue tracker] or add a new one), coordinate on the mailing lists, and get started. If your employer is brave enough to understand how critical this work is, they'll pay you to work on it. If not, the [https://www.linuxfoundation.org/ Linux Foundation]'s [https://www.coreinfrastructure.org/faq Core Infrastructure Initiative] is in a great position to fund specific work proposals. We need kernel developers, compiler developers, testers, backporters, a documentation writers. | ||
= Patch Contribution Guidelines = | = Patch Contribution Guidelines = | ||
When contributing patches for the Linux kernel, be sure to follow the Linux kernel [https://www.kernel.org/doc/html/latest/process/coding-style.html Coding Style Guide] and read about [https://www.kernel.org/doc/html/latest/process/submitting-patches.html Submitting Patches]. Even if you're only sending your patches to the | Please send new topics and patch series to both [http://vger.kernel.org/vger-lists.html#linux-hardening linux-hardening@vger.kernel.org] and [https://www.openwall.com/lists/kernel-hardening kernel-hardening@lists.openwall.com] for the widest audience possible. | ||
When contributing patches for the Linux kernel, be sure to follow the Linux kernel [https://www.kernel.org/doc/html/latest/process/coding-style.html Coding Style Guide] and read about [https://www.kernel.org/doc/html/latest/process/submitting-patches.html Submitting Patches]. Even if you're only sending your patches to the mailing lists for some early review, it's best to get as much of the coding style and submission semantics correct to avoid reviewers needing to recommend changes in those areas. | |||
== grsecurity and other non-upstream patch sources == | |||
As with any other | As with any other Free Software project, it is particularly important that if you're working on upstreaming work from other projects, be sure your patches are giving credit to the original authors, that licenses are compatible, and that copyright notices are retained, etc. | ||
In the case of new files, or other places where a copyright notice would be expected to be added, be sure to retain all copyright notices from the other project. This may require some examination of commit history. For example, [https://github.com/linux-scraping/linux-grsecurity/blob/grsec-test/grsecurity/Makefile#L3 | In the case of new files, or other places where a copyright notice would be expected to be added, be sure to retain all copyright notices from the other project. This may require some examination of commit history. For example, [https://github.com/linux-scraping/linux-grsecurity/blob/grsec-test/grsecurity/Makefile#L3 grsecurity's copyright notice from their most recent public patch] does not include PaX Team's copyright notice, which is only listed in the patch for GCC plugins. For grsecurity copyright, when more specific details are not easy to find, the following could be used: | ||
Copyright (C) 2001-2017 PaX Team, Bradley Spengler, Open Source Security Inc. | Copyright (C) 2001-2017 PaX Team, Bradley Spengler, Open Source Security Inc. | ||
Additionally, | Additionally, grsecurity has asked that contributors include this in commit messages for non-trivial code ported from grsecurity: | ||
$CODE is {verbatim,modified} from Brad Spengler/PaX Team's code in the last | $CODE is {verbatim,modified} from Brad Spengler/PaX Team's code in the last | ||
Revision as of 22:08, 5 October 2020
Want to get involved in the Kernel Self Protection Project? Here's how:
- Join the upstream Linux kernel hardening mailing list where development, maintenance, and administrivia happen. (And visit the list archive.)
- Join the general Linux kernel hardening mailing list, where new hardening topics are discussed. (And visit the list archive.)
- (Optional) Join the ##linux-hardened IRC channel on freenode.
Introduce Yourself
Send an email to introduce yourself! Then pick an area of work from the issue tracker or add a new one), coordinate on the mailing lists, and get started. If your employer is brave enough to understand how critical this work is, they'll pay you to work on it. If not, the Linux Foundation's Core Infrastructure Initiative is in a great position to fund specific work proposals. We need kernel developers, compiler developers, testers, backporters, a documentation writers.
Patch Contribution Guidelines
Please send new topics and patch series to both linux-hardening@vger.kernel.org and kernel-hardening@lists.openwall.com for the widest audience possible.
When contributing patches for the Linux kernel, be sure to follow the Linux kernel Coding Style Guide and read about Submitting Patches. Even if you're only sending your patches to the mailing lists for some early review, it's best to get as much of the coding style and submission semantics correct to avoid reviewers needing to recommend changes in those areas.
grsecurity and other non-upstream patch sources
As with any other Free Software project, it is particularly important that if you're working on upstreaming work from other projects, be sure your patches are giving credit to the original authors, that licenses are compatible, and that copyright notices are retained, etc.
In the case of new files, or other places where a copyright notice would be expected to be added, be sure to retain all copyright notices from the other project. This may require some examination of commit history. For example, grsecurity's copyright notice from their most recent public patch does not include PaX Team's copyright notice, which is only listed in the patch for GCC plugins. For grsecurity copyright, when more specific details are not easy to find, the following could be used:
Copyright (C) 2001-2017 PaX Team, Bradley Spengler, Open Source Security Inc.
Additionally, grsecurity has asked that contributors include this in commit messages for non-trivial code ported from grsecurity:
$CODE is {verbatim,modified} from Brad Spengler/PaX Team's code in the last
public patch of grsecurity/PaX based on my understanding of the code. Changes
or omissions from the original code are mine and don't reflect the original
grsecurity/PaX code.