-
-
Notifications
You must be signed in to change notification settings - Fork 5.3k
added information about downstream projects included in our security issue resolving process #2639
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -48,6 +48,46 @@ confirmed, the core-team works on a solution following these steps: | |
|
||
While we are working on a patch, please do not reveal the issue publicly. | ||
|
||
.. note:: | ||
|
||
The resolution takes anywhere between a couple of days to a month to solve | ||
an issue depending on its complexity and the coordination with the | ||
downstream projects (see next paragraph). | ||
|
||
Collaborating with Downstream Open-Source Projects | ||
-------------------------------------------------- | ||
|
||
As Symfony is used by many large Open-Source projects, we standardized the way | ||
the Symfony security team collaborate on security issues with downstream | ||
projects. The process works as follows: | ||
|
||
1. After the Symfony security team has acknowledged a security issue, it | ||
immediately send an email to the downstream project security teams to inform | ||
them of the issue; | ||
|
||
2. The Symfony security team creates a private Git repository to ease the | ||
collaboration on the issue and access to this repository is given to the | ||
Symfony security team, to the Symfony contributors that are impacted by the | ||
issue, and to one representative of each downstream projects; | ||
|
||
3. All people with access to the private repository work on a solution to | ||
solve the issue via pull requests, code reviews, and comments; | ||
|
||
4. Once the fix is found, all involved projects collaborate to find the best | ||
date for a joint release (there is no guarantee that all releases will be at | ||
the same time but we will try hard to make them at about the same time). | ||
|
||
The list of downstream projects participating in this process is kept as small | ||
as possible in order to better manage the flow of confidential information | ||
prior to disclosure. As such, projects are included at the sole discretion of | ||
the Symfony security team. | ||
|
||
As of today, the following projects have validated this process and are part | ||
of the downstream projects included in this process: | ||
|
||
* Drupal | ||
* eZPublish | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. |
||
Security Advisories | ||
------------------- | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be good to give a minimum amount of time to wait for issues that are not known to be exploited in the wild. Based on some discussion of coordination in upstream/downstream situations with Kees Cook I think 2 weeks would be a reasonable amount of time.