[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Php why must your apps suck so?

Michael Stahnke wrote:
Again, blaming the lanaguage doesn't make a ton of sense.  If you're
worried about XSS, audit the code.  If you're worried about buffer
attacks, run SELinux.  The list goes on.

We could audit the code of everything that goes into infrastructure but our manpower would spend quite a bit of time on that (every new service and every update would have to be reviewed....) Can we do this? Could we setup a SIG which was interested enough in security to do this? (Such a sub-project would have a benefit to Fedora as a whole, not just infrastructure... but it isn't a trivial task.)

If not we have to play the stock market on this one. 1) What's past performance been like? 2) How's the current management doing at identifying and removing security problems?

For #1, compare the number of CVEs_ in mediawiki to moin and drupal to zope+plone:
               2007   2006   2005
  moin           5      0      0
  mediawiki      7      5     12

  drupal        36     37      8
  zope(plone)  1(+0)  2(+3)  1(+0)

Now we all know that numbers can be misleading but still this seems to highlight something for me: there are projects which care about security and there are projects which tack it on as an after thought. No matter how much work we put into security locally (SELinux, mod_security, code auditing), we don't want to be using a project which belongs to the latter camp. *Sending security patches upstream doesn't help if upstream will just introduce a new batch of security issues in their next release.*

PS: Purely on the basis of these numbers I'd be led to believe that replacing moin with mediawiki would be acceptable. Knowing the mismatch in priorities between us and upstream moin, this might be a benefit to us (especially if we have some expert help tuning an SELinux policy and setup mod_security for it). Drupal, though, just makes me feel like we'd be trying to keep water in a sieve by putting it in a trash bag.

PPS: we're currently creating SELinux policies for our machines that allow us to run in enforcing mode... Depending on the timeframe we're looking at for deploying that, we might need to create an app server that is specifically going to run SELinux from day one; implementing these new services there while we transition the old services over.

.. CVEs: CVEs were simply searched for by project name in http://nvd.nist.gov/nvd.cfm?advancedsearch and counted. No attempt was made to find duplicates, or invalid CVEs for any of the projects.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]