On Tue, Jun 01, 2004 at 11:47:04AM +0200, Javier Fern?ndez-Sanguino Pe?a wrote:
Content-Description: ebian-audit_at_shellcode.org
> - The pages are difficult to find if starting from the index (in order to
> get to the tools page I had to go Index->FAQ->Auditing Overview->Tools
I've added a link to the tools page upon the index now, which should
make that simpler.
One thing that is still missing is a guide to using each of the tools
on a piece of sample code. That was almost ready but I've held of
committing it now that there is a new release of flawfinder.
I agree that in general the pages are a little mazy, that's partly
due to their relative newness and partly because I'm not sure how to
create a good menubar - I don't want the pages to look too different
from the rest of the Debian pages.
> - The pages are too spread out with only tidbits of information in each
> page instead of having a single page with a lot of information and
> appropiate headers to make it easy to jump to one place or another
That should hopefully change as each of the pages gets larger.
> - I disgress regarding the recommendation to _not_ use the BTS. IT might
> make sense to use the BTS when reporting bugs related to versions that are
> not present on unstable and don't require a DSA themselves. For example
> consider #249613.
> [Note: I'm not really an example on how to do this since I should have
> reported #249616 to the Security Team first]
I was specifically asked not to report security bugs via the BTS by
mdz, and since then I have not done so. However there is a section in
the manual which specifically allows some security bugs to be reported
in this way, from memory it says they may reported either if the bug is
already public knowlege, or if it involves something "simple" like a
symlink attack.
> - I miss a link to the open security bugs, prospective auditors could be
> forwarded also to http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=security
> and ask them to _help_ fix bugs or take a look at open bugs.
That is a good suggestion.
> - A list of common bugs found and pointers on how to fix them?
> For example: race conditions, buffer overflows...
This is already present in my pages in the enhanced tools page,
basically I show a piece of code and then run that through each of the
source code scanners walking through the output.
There are also links to the Secure Programming HOWTO for more
information on closing things securely.
> - References to other (active) audit teams (like OpenBSD's, I believe that
> Sardonix is almost dead, but not completely)
That's a good idea, and I'll add links.
> Just my 2c
Much appreciated, thanks.
Steve
--Received on Wed Jun 02 2004 - 16:22:28 BST