List security issues on the patch release blog template
Overview
We are working to combine the patch and security releases in &1073 (closed). A big portion of this is combining the blog posts into one automated system.
To start, we should fetch all issues linked to the security release tracking issue, and list them in the blog post, each one simply showing the issue title. The content details for each section will be added in a subsequent issue. In this issue, we can list the versions that the issue has been included in.
Proposal
-
Update BlogMergeRequest
.- Rename the
content:
param topatch_content:
. - Add a new param:
security_content:
that will takeSecurity::IssueCrawler.new.related_security_issues
.security_content:
should benil
by default. This will allow the existing code where the patch blog post is automatically created to continue to generate a blog post for a single version.
- Rename the
-
In the template, list each security issue in :security_content
as a### <title>
section. The title should besecurity_issue.cve_issue.title
and fallback tosecurity_issue.issue.title
ifcve_issue
isnil
. -
This new content in the template should all be behind a new feature flag. It may be easier to start a new template for the new blog post and switch templates based on the feature flag, but do whatever makes the most sense. We are trying to match the existing security blog post when there is security issue content.
Notes
-
In the rake task
release:patch_blog_post
, if a version is given as an arg, thesecurity_content:
supplied toBlogMergeRequest
should benil
. This will allow us to still create a blog post for a single version patch release as we currently do today. -
There is a benefit to keeping the
security_content
separate frompatch_content
at least for now. We can easily tell if the blog post contains security issues. This allows us to change the header, footer, title, and assignees by simply checkingsecurity_content.blank?
(example). I considered that once the backports are merge for a security release, we can just rely on the coordinator to give us everything, but then we need to write logic to tell us which changes are security issues and then find their associated security implementation issue. Since we know the blog data comes directly from the security implementation issue and it's CVE issue, it just seems like the boring solution is to just pass that easily fetched list of issues into the blog class. If we ever change the format of the blog post, we can rethink how we fetch/organize all of the changes.