Openwall Project   /home  Owl  JtR  Pro  crypt  pam_passwdqc  tcb  phpass  scanlogd  popa3d  msulogin  /  Linux  BIND  /  advisories  presentations  /  services  donations  /  wordlists  passwords  /  community  lists  wiki  CVSweb  mirrors  signatures
bringing security into open environments
 
This website is powered by Openwall GNU/*/Linux security-enhanced OS
[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]
Date: Tue, 19 Feb 2008 08:35:44 +0100
From: Sebastian Krahmer <krahmer@...e.de>
To: oss-security@...ts.openwall.com
Subject: Re: code review CVS

On Mon, Feb 18, 2008 at 09:00:24AM -0700, Vincent Danen wrote:

I am not sure if a cvs or something like a -AUDITED
branch would be the right way, since it might not be obvious
which older versions were reviewed too if new versions are commited.
Maybe a wiki with patch subdir and link to the reviewed
CVS version/branch will suffice. Need to play around :)
On the other hand if such a project grows you can have a complete distro
you can check out and you always see which parts of a distro or larger project
are reviewed such as apache w/o certain modules. problem is that
such partial reviews may stop to compile upon checkout.

Sebastian

> * [2008-02-18 10:28:36 +0100] Sebastian Krahmer wrote:
> 
> >>From my view it would be helpful to have some forum/CVS or whatever
> >where code reviewers can submit the code they already audited along
> >with remarks/exploits/patches etc.
> >So everyone can match this against the version of the OSS project.
> >In an ideal case their latest released version equals the
> >version in the review CVS. It saves also the time to review
> >files again which didnt change during versions.
> 
> This is an intriguing idea, but I wonder if a version control system is
> actually required, or if we could use the wiki itself for something like
> this.
> 
> A code checkin of audited source might be nice for "pristine" code
> purposes, but then we almost duplicate an author's scm system.
> 
> Would not a simple list of software be sufficient?  For instance,
> something that listed:
> 
> - software name
> - audited version
> - audit date
> - who did the audit
> - results of the audit (links to patches, whatever)
> 
> Most authors keep old packages kicking around, so I don't think we need
> an scm for this.  I mean, if you review foo-1.1 and it's ok, and someone
> indicates a vuln in foo-1.3, then one could easily download both foo-1.1
> and foo-1.3 and just do a diff to see what's changed, right?
> 
> Or do I miss something where a scm would be really valuable?
> 
> -- 
> Vincent Danen @ http://linsec.ca/



-- 
~
~ perl self.pl
~ $_='print"\$_=\47$_\47;eval"';eval
~ krahmer@...e.de - SuSE Security Team
~ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Hosted by DataForce ISP - Powered by Openwall GNU/*/Linux