Re: scan debian packages for security vulnerabilitys big time
* Colin Mattson (firstname.lastname@example.org) [001105 23:49]:
> > 1) try to raise the security awareness of the debian developers and get them
> > to audit the code of their packages and perhaps even help their upstream
> > authors and
> This is all well and good, but not every package maintainer is well-versed in
> the language the packages may be written in. For example, I might know as much
> as Larry Wall about Perl, but not even enough for the ubiquitous "Hello World"
> in C.
Yes that is in fact a problem. But that is there to some degree, anyway. The
overvelming majority might not be good at secure c programming and still speak
c to some extend. Some people might not be aware that there is a problem with
some constructs in c. So we need to tell them. A fraction of the people might
become interested. But we all would benefit if alt least we would know that
all the security warnings in this suid deamon where there and we could do
something about it, even if the maintainer did not care.
> Debian takes a much more active response to critical bugs than some other
> distributions do. Generally, as soon as a bug is discovered, fixed packages
> are released ASAP.
That is the point. We can search for bugs (=potential security holes) BEFORE
the bug is discovered. Look at Bugtaq: most problems reported today as
security problems were fixed in OpenBSD 2 years ago as a bug. They did not
get a chance to become a security vulnerability. in the old game the bugs hunt
us. It would be better the other way around.
> Prevention's still the best prescription (if you're
> adminning a system, you'd darn well better be performing your own audits
> anyway, not relying on the author and distribution to do it for you),
> but in certain situations may not always be possible or easily done.
The tiny OpenBSD base system is under a three year non-stop audit. I want to
see the admin who does such a audit before he installs a system. No single
human beeing can do this efficintly nowerdays.
> Depending on the software, it might be nonsensical to use such a tool, and
> depending on the package maintainer's system, it might slow packaging to a
> near halt. (Heck, my other (backup) box is slow enough as it is... Adding
> something like this into the build process would kill it.)
its4 is faster then the c preprocessor. I would like to make it fatter, though
and only scan preprocessed code so no debug output etc is generating false
> > For now, I packaged his non-free software (called 'Its The Software, stupid',
> > short: its4.) and would like to try to integrate it into the debian
> > development process.
> Non-DFSG-free software in the build process would be a big no-no.
debian would not depend on this tool. not more than it depended on pgp (when
gpg was not available yet).