Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 1 Feb 2013 00:18:52 +0100
From: Peter Huewe <>
Cc: Corey Bryant <>,
 Kees Cook <>,
 Anthony Liguori <>,
 Frank Novak <>,
 George Wilson <>,
 Joel Schopp <>,
 Kevin Wolf <>,
 Warren Grunbok II <>
Subject: Re: Secure Open Source Project Guide

> 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" 

Just my two cents.


Powered by blists - more mailing lists

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