Re: faster tracker data processing
Michael S Gilbert wrote:
> On Wed, 30 Sep 2009 23:49:54 -0500 Raphael Geissert wrote:
>
>> Hi,
>>
>> I haven't had much time lately to actively audit and fix vulnerabilities,
>> but I usually take a look at the commits and there are times I see that a
>> new CVE id was assigned to some app shipped on Debian.
>>
>> What is the general opinion of for example when finding such entries add
>> a simple '- package <unfixed>' entry and leave the 'TODO: check' around?
>
> this is a good start, but since your time is limited, it would be wise
> to pass the buck to the maintainer (who should have time to work issues
> in their packages) via a bug report. you can then add a 'TODO:
> follow-up with maintainer (asked to check whether <package> affected)'
> or something like that. of course 99% of the time, the maintainer will
> do nothing, and one of the other security team members will have to
> come back to it, but at least the current state is pretty clear when
> they get to it.
We could actually try to write some sort of automated system to contact the
maintainer(s) when a new issue is published regarding their package. But I
guess we would need a blacklisting system to avoid spamming some people or
teams who are usually aware of those issues in advance (kernel sec team
maybe? people working on the tracker, etc)
>
>> If that's not desirable, maybe a concept of "HINT"s could be introduced,
>> where the script that updates the CVE/list file from the CVE db
>> automatically adds HINTs of possibly affected packages based on the
>> embedded-code-copies files, the technique used by the check-new-issues
>> (apt-cache search), and a simple file that could be used to associate
>> full project names with a package name (say "Alvaro's Messenger" with
>> "amsn"). The tracker would of course display the CVE as affecting the
>> HINTed packages until the hints are removed from CVE/list.
>
> this seems like a good idea, but i would be cautious. taking people out
> of the loop may be dangerous if not done correctly. i would suggest that
> the final product of such a script would be at most a 'TODO:
> check <package1>, <package2>, ... (not comprehensive)' so someone will
> have a good starting point, but will be aware that the bot's output
> isn't a complete list of potentially vulnerable packages.
I actually meant something more like:
CVE-2009-1234 (heap overflow in Alvaro's Messenger could...)
TODO: check
HINT: amsn
CVE-2009-2345 (incorrect handling of null-terminated strings in foo...)
TODO: check
HINT: foo (if such a package existed)
>
> inject-embedded-code-copies is an existing script that automatically
> inserts TODOs for embedded code copies. it could be set up to run on
> every commit, but i need to finish triaging the existing issues to
> prevent a deluge of TODOs to begin with.
>
Yeah, but the script is not ready to be automatically used. At least mapping
names to the name of the Debian package would be more accurate and avoid a
zillion of possible false positives.
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Reply to: