Am 18.12.2013 19:47, schrieb Ondrej Vasik:
On Wed, 2013-12-18 at 19:00 +0100, Reindl Harald wrote:
>>> seucrity by obscurity is dumb, did never work and will never work
>>
>> Btw. you can check how it worked for the project where both RH and
>> upstream were WILLING to work on the report and published it on wiki -
>> net-snmp example is at
>>
http://www.net-snmp.org/wiki/index.php/5.7.1_Coverity_scan - even after
>> 2 years, there are some groups unchecked (although the most critical
>> ones were analyzed and fixed/commented in ~1 year)
>
> well, does *not* sound like upstream is *really* willing
> otherwise it would have been fixed
>
> and yes i have worked with upstream-developers where the reaction
> after a coverity scan was this while *one day* after i pointed
> out that cobverity exists at all the first commit landed
>
>
http://git.dbmail.eu/paul/dbmail/log/?qt=grep&q=coverity
Ok, so we have some upstreams where noone will look for years, we have
some upstreams, who can fix the report within one day, we have some
upstreams where it will take several months or years.
If you check the net-snmp, there was ~160 issues fixed based on this
report - in your case, the difference is ~+200/-150 loc in ~1 month
timeframe - this is probably doable if it doesn't involve design changes
to fix some issues.
on the other hand if a piece of code has too much security relevant bugs
and obviously a horrible coding style nobody understands *this* would be
a good reason to replace the complete library / software
there where done way too much replacements in the last few years which did
not work as "drop-in" and often without good reasons for the unfinished
state it was done, in case of horrible insecure and unmaintainable code
i would not cry out that much as i did with F9/KDE4 and F15/systemd
I'm completely for sharing the output of the scans with upstreams
- and
many upstreams were contacted by Red Hat guys (many times with patches)-
however having such report concentrated on one place is not a good idea.
Btw. publishing security hole (as you suggested in one of your previous
emails) is one of the worst things you can do. Private emails to
upstream or some security distribution lists is much better idea in such
cases (imagine a hole e.g. httpd/bind - and the maintainer on PTO/sick
leave)
imagine there is a mitigation you could to as sysadmin if you only know
about the problem while the bad guys still may know, yes i fixed httpd
bugs within a few minutes after full-disclosure by disable not really
needed options not looked dangerous not so long ago, mod_security took
two days for a rule and httpd-upstream some days more for the fix and
even much longer for a official release
in case a security bug is found *be sure* some bad guys are knwing it
too or at least rapdily with or without full disclosure
the difference is how many users can help themself in the meantime and
how many eyes are looking at the problem - as you named httpd: the best
example - imagine how many knowledgeable people having their own servers
vulnerable are interested in help coding, debugging and testing to fix
the problem compared with "nobody knows but doors wide open"