On Mon, Oct 10, 2016 at 11:32:43AM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 10 October 2016 at 11:07, Florian Weimer wrote: > > On 10/07/2016 06:43 PM, Dominik 'Rathann' Mierzejewski wrote: > > > > > I was made aware that EOL software with known security bugs that will > > > not be fixed upstream (due to EOL status) was reviewed and accepted into > > > Fedora recently. > > > > Fedora relies on EOLed components pretty much across the system (including > > critical security functionality), so one more such package really isn't the > > end of the world. I think new packages should not be held to tremendously > > higher standards than existing packages. > > I think times have changed enough to warrant this at least for new > packages. I don't think it's acceptable to simply allow adding > known-to-be-vulnerable software to our package repositories without > additional review anymore. History has shown that it is safe to assume that every single non-trivial application contains multiple security vulnerabilities, at all times. We may not have found them yet, but you can certainly bet there are some there. If you have 2 packages proposed for Fedora, one with known security bugs, and one without, this does not imply that the former is less secure / more dangerous for Fedora. It almost certainly just means that no one has looked for security bugs in the other piece of "bug free" software. In some ways the piece of software with known security bugs may be considered better, because it is a sign that it has actually had some attention from security researchers, and users of it have information to evaluate whether their usage scenario is actually at risk or not. So IMHO a rule that forbids addition of software with known security bugs is far too crude a hammer and would just give us a false sense of security. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
