PSA: If you are C/C++ developer, use cppcheck

[Reindl Harald]

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"


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20131218/ba9aadaf/attachment.sig>