Planning for Security implications of using external libraries

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!
Posted by greggles on August 28, 2012 at 3:41pm
Last updated by scor on Tue, 2012-08-28 16:52

At Drupalcon Munich there was some discussion about introducing Symfony into Drupal and what that will mean for our security processes. Let's document our ideal scenarios for what we want an external library's maintainers to do before we incorporate it into Drupal. This should provide a framework for discussion with Symfony, but also potentially other libraries (e.g. Guzzle).

  • The project should have a simple, well documented way to report bugs
  • The project should follow Responsible Disclosure
  • The project should make security releases on a consistent schedule (e.g. every tuesday, every X day of the month)
  • The version of the libraries being incorporated into Drupal will be supported by their security process for as long as we reasonably expect Drupal Core to be supported (around 5 years)
  • The project should have active maintainers so that security vulnerabilities can be fixed in a reasonable amount of time (X weeks).
  • The project will ideally allow interested members of our security team to join their private mailing list/issue tracker so we can have some advance knowledge and coordination around releases.

What else should we be looking for?

Comments

That sounds like a good

Posted by catch on August 28, 2012 at 3:46pm
catch's picture

That sounds like a good list.

We should also ask whether they'll provide security-only releases - in fact for Drupal core to continue to provide those, we'll need to be able to ensure that for upstream security fixes too that we're pulling in (assuming it's worthy of a core SA) - whether it's done directly by them or we maintain a fork somewhere for that purpose.

In the case of Symfony, they

Posted by scor on August 28, 2012 at 4:22pm
scor's picture

In the case of Symfony, they currently only provide a patch and no security only fix release (see Security Release: Symfony 2.0.17). But I'm sure they'd be open to the idea of a release if it makes our life easier.

Don't

Posted by chx on September 5, 2012 at 10:43am
chx's picture

Let's keep our Symfony usage to the minimal necessary and make sure we avoid security-sensitive places (like session) because if there is a sechole in there then the SA necessary will require a tremendous coordinating effort with all the projects that rely on Symfony. As necessary, use the Symfony interfaces but do our own wherever possible and security sensitive. I hope we are so far good.