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"
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
