added information about downstream projects included in our security issue resolving process

[fabpot]

Q	A
Doc fix?	no
New docs?	yes
Applies to	all
Fixed tickets	n/a

We've been working closely with some Open-Source projects using Symfony during the last few months to better collaborate on security issues. I think that this is a good idea to be transparent about this process as well, and this PR describes how it works today.

[scor]

Should we be more specific about days of the week where releases typically happen? Drupal security releases happen on Wednesdays? As far as I know Symfony is more lax, and release mid week (Tue, Wed or Thu).

I'm not talking about critical vulnerabilities exploited in the wild here, where any rule established above would be ignored and releases would potentially happen immediately, based on the level of the exploit.

[fabpot]

@weaverryan It's mergeable.

[weaverryan]

Thanks @fabpot! Patched into the 2.1 branch at sha: dbe24be

[greggles]

There are two questions/suggestions on this issue that have not been addressed (1 from Scor from 16 days ago and 1 from me from 13 days ago). It's pretty frustrating.

So far the Symfony team has been unnecessarily cavalier in releasing issues. If that pattern continues, what should the Drupal Security Team's response be? I think our only action can be to ask people to report issues directly to us and then horde those issues in our private queue long enough to understand how they will impact Drupal before we share them with the Symfony team. Surely that's not a policy you are trying to push us into but...what else do you suggest we do?

[fabpot]

@greggles cavalier? Do you have any examples in mind? During the last months, I've sent all security issues we have received to the Drupal security team (on the components you are using). We collaborated on a couple of them and I did not any feedback on the last one about Twig. The process described in this PR has been discussed with @scor for at least 6 months, so I'm not sure what you are referring to.

Anyway, I would be more than happy to collaborate more closely with the Drupal team. If you feel that we need to have an open discussion, let's plan an online meeting soon. And don't hesitate to contact me by email anytime.

[greggles]

The specific issue that troubled me was http://symfony.com/blog/security-release-symfony-2-0-19-and-2-1-4 released on a Thursday after only 2 days of discussion.

Two problems there:

1. Since Drupal releases on Wednesdays, a Thursday release means that users of Drupal either need to patch by themselves or be vulnerable for 6 days or that the security team needs to start releasing on Thursday/Friday if Symfony really decides to release on Thursday.
2. The issue was raised on Tuesday the 27th, so a release was made in 2 days. It's possible that in the private issue on the subject you got approval from Scor or others to release as maybe it didn't affect them, but it feels awfully quick to me for a base framework to make a change like that without waiting for feedback. People are busy or on vacation (especially that time of year) so a little extra time for reviewing patches seems prudent.

I think we've been discussing the ideas in this PR since you and I talked in person at Drupalcon Munich, but I don't see why that means that comments made in the last 16 days should go ignored?

[fabpot]

I do understand your problems for the issue you mention but at that time (and this is still the case), Drupal 8 was not released (and still in heavy development). So, the release schedule mentioned here did not apply at that time... or at least, that was my understanding.

But again, let's talk about how to improve the current situation as I'm willing to improve things wherever it is possible. What I do know is that having a release on the same day for everyone is impossible if each project depending on Symfony insists on a specific day for releases.

For the two comments, I thought that it was not needed to be more specific in our documentation but as it seems to be important for you, I've submitted another pull request addressing them (see #2696). Sorry if I did not came back about them earlier.