Kernel Self Protection Project/Get Involved

From Linux Kernel Security Subsystem
(Difference between revisions)
Jump to: navigation, search
(Created page with "Want to get involved? [http://www.openwall.com/lists/#subscribe Join] the [http://www.openwall.com/lists/kernel-hardening/ kernel hardening mailing list]. = Introduce Yoursel...")
 
(Blanked the page)
Line 1: Line 1:
Want to get involved? [http://www.openwall.com/lists/#subscribe Join] the [http://www.openwall.com/lists/kernel-hardening/ kernel hardening mailing list].
 
  
= Introduce Yourself =
 
 
Send an email to introduce yourself! Then pick an area of work from below (or add a new one), coordinate on the mailing list, 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 [http://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 =
 
 
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 kernel-hardening mailing list 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.
 
 
As with any other Open Source project, it is particularly important that if you're working on upstreaming work from other Open Source 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 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.
 

Revision as of 23:24, 5 June 2017

Personal tools
Namespaces

Variants
Actions
Navigation
Tools