Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 01 Feb 2013 09:36:21 -0500
From: Corey Bryant <>
To: Peter Huewe <>
CC:, Kees Cook <>,
        Anthony Liguori <>, Frank Novak <>,
        George Wilson <>,
        Joel Schopp <>,
        Kevin Wolf <>,
        Warren Grunbok II <>
Subject: Re: Secure Open Source Project Guide

On 01/31/2013 06:18 PM, Peter Huewe wrote:
> Hi,
>> We should probably start by gathering a list of ideas to include in the
>> guide.  Some initial ideas that come to mind are:
>> * Secure programming practices (Secure "Programming for Linux
>>     and Unix HOWTO" is a good reference for Linux though probably
>>     out of date)
>> * Performing secure code reviews and detecting common
>>     vulnerabilities
>> * Ensuring code is reviewed by trusted parties and proper patch
>>     tagging is used
>> * Signing of releases, pull requests, patches, commits, etc by
>>     trusted parties
>> * Removing vulnerabilities with automated tooling (Static/Dynamic
>>     analysis, Fuzzing)
>> Any thoughts?
> I'd definitely add
> * creating semantic patches out of the secure coding reviews / common
> vulnerabilities with coccinelle/spatch.
> (Usually the same bugs happen over and over again - see e.g. the CWE list ;)
> I know this goes into the direction of your last point, but is not that
> trivial to use like e.g. spatch but on the other hand provides "automatic"
> fixing.
> Just my two cents.
> PeterH

Thanks for the input.  Automated patching with Coccinelle and the like, 
and pointers to get folks started with these tools would be a great 

Corey Bryant

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.