Debian audits (qa, security, rough, performance...)
Well seeing as how me and Steve Kemp <skx@tardis.ed.ac.uk> have both
started related projects I feel that now is a good time to announce and
ask for help for our projects.
Steve Kemp is working on a project at http://www.steve.org.uk/Debian/
which seems to be mainly a security audit and seems to be done by hand
which is a superior method.
>From Steve Kemp's web site:
You can help in one of two ways, by nominating packages to be added to
the list of packages to test, or by taking some time to examine a
package yourself.
I would like to call for there to be an audit team and I would like most
popular packages to be audited first. Avery Pennarun <apenwarr@debian.org>
's "Debian Popularity Contest Results" at
http://www.debian.org/~apenwarr/popcon/ may be a good place to look for
figuring out package popularity. Debian-security and Debian-qa may be able
to help with creating an audit team.
I am starting a similar related project at
https://sourceforge.net/projects/debraudit/ which is a more general audit,
but only a rough automated audit which may make developers and code
auditor's jobs easier. My project is considerably less well developed but
I feel will assist audits of Debian code. I would also like to target
performance and any kind of bugs in my audit project.
I too am looking for help, however I am looking for security audit tools,
users of the tools, and would like help automating rough testing. I know
some people think rough audits give a false sense of security, however I
feel that a rough audit is far better than no audit and the more audits
the better (multiple manual audits by trained/experienced people is the
best).
Misc points:
sftp has a good audit policy that works by date since last change of
section and lists more confidence for sections that have been audited by
more people.
Debian's security team's recommendations should be followed when security
issues are found.
I have yet to collect Debian's security policies into a list and I may not
have read them all.
splint, rats and other tools are useful.
lintian and other Debian specific tools are useful and may already have a
rough audit report list (lintian's is at http://lintian.debian.org iirc)
Audit code such as ADL is very useful. ADL is inline audit code for C++.
Documentation on upstream audits may be very useful.
Drew Daniels
I'm looking for a job/career. My resume is at:
http://home.cc.umanitoba.ca/~umdanie8/resume.html
Reply to: