Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Adding security details to release notes #1354

Closed
cji opened this issue Jun 11, 2020 · 13 comments · Fixed by #1441
Closed

Adding security details to release notes #1354

cji opened this issue Jun 11, 2020 · 13 comments · Fixed by #1441
Assignees
@puerco
Labels
area/release-eng Issues or PRs related to the Release Engineering subproject kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. sig/release Categorizes an issue or PR as relevant to SIG Release.

Comments

@cji
Copy link
Member

cji commented Jun 11, 2020

What would you like to be added:

The Product Security Committee would like the ability to include details about security fixes in release notes just prior to release announcements going out.

Why is this needed:

There are situations where a vulnerability with a Medium or Low severity may be fixed semi-publicly (for example with a public PR but not mentioning the security implications). When the commit(s) are cherry-picked, they would not include any of the CVE/impact/other details in the release notes.

@justaugustus provided an example of how this could work:

  • from k-security org (or some other private method) PSC files some yaml, maybe:
cve: CVE-57687939425739480235
  description: Really bad SSRF in KCM
  impact: low|medium|high|critical
  mitre_link: https://blah
  kubernetes_tracking: https://github.com/kubernetes/issues/87945258935
  • that's reviewed and merged via some pipeline that PSC + Releng have visibility into
  • post-submit scrapes these and copies them to a private releng staging bucket
  • existing release notes tool is extended to look in that bucket during staging/release process

/cc @kubernetes/release-engineering
/cc @kubernetes/product-security-committee
@cji cji added area/release-eng Issues or PRs related to the Release Engineering subproject kind/feature Categorizes issue or PR as related to a new feature. sig/release Categorizes an issue or PR as relevant to SIG Release. labels Jun 11, 2020
@tallclair
Copy link
Member

tallclair commented Jun 11, 2020 •
edited
Loading

The described process sounds good, but it might be overkill. On release day, what time are releases usually cut? We typically aim to lift embargoes at 9am PT (negotiable), so I'm wondering whether we could simply merge a public PR right around that time, and start the release after?

EDIT: To clarify, I think we should have the release notes ready & approved before hand, so the public PR doesn't need to be reviewed.

@k8s-release-robot
Copy link

k8s-release-robot commented Jun 11, 2020 via email

@puerco
Copy link
Member

puerco commented Jun 12, 2020

Another approach, easier to implement IMHO, could be to have the PSC publish the vulnerability info on a known location in k/security and we would modify the release notes tool to scan for that data before cutting a new patch version. That file could tie together commits that have been cherry picked and have them treated separately in the doc and would enable us to get a unified security release note on all branches, with links to every related commit.

To make the release notes process independent from the embargo lift time, those files could be published at any time encrypted in kms with a key shared with one the releng groups (say k8s-infra-release-editors). That group would need to have the kms/decrypter role in the project, of course. This would keep the vulnerability hidden right until the release is cut and leave full control of the disclosure with the PSC, no PR reviews needed.

@saschagrunert
Copy link
Member

Alright, sounds like a plan. How about this design proposal:

  1. Find a flexible format for generally mapping release notes, for example:
- pull-requests:
    - 12345
    - 67890
  release-note: This release note has been modified
  cve:  # optional
    id: CVE-2019-1010260
    description: Really bad SSRF in KCM
    published: 2020-10-05
    score: 5.2
    issues:  # optional
      - 9876
      - 9875
  1. Update krel [release-notes,changelog] and release-notes to be able to consume these mappings during release notes generation (recursively scraping directories and files)
  2. Add a feature to be able to consume the mappings from a private remote resource (a git repo?)

@saschagrunert
Copy link
Member

I think we could solve multiple issues with the above mentioned proposal:

The first rough idea (without proposing a KEP) would be to add the minimal feature of being able to map notes from A to B. Then we could demo that at one of the next SIG Release meetings and discuss possible process changes around it.

@k8s-release-robot
Copy link

k8s-release-robot commented Jun 16, 2020 via email

@puerco puerco mentioned this issue Jun 22, 2020
Merged
@puerco puerco mentioned this issue Jul 27, 2020
Merged
@tpepper
Copy link
Member

tpepper commented Aug 4, 2020

/assign @puerco

@lauriapple2
Copy link

/assign @puerco

@puerco
Copy link
Member

puerco commented Aug 4, 2020

We already have the mechanism in place to add the CVE information to the release notes and changelog. The current proposal for the MD format is in PR#1441, a sample of the markdown output can be seen here.

Could the interested parties comment on the output so that we can move forward with it?

@lasomethingsomething
Copy link

/priority important-soon

@k8s-ci-robot k8s-ci-robot added priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. and removed needs-priority labels Aug 6, 2020
@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 4, 2020
@saschagrunert
Copy link
Member

/remove-lifecycle stale

@k8s-ci-robot k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 4, 2020
@saschagrunert saschagrunert mentioned this issue Jan 12, 2021
Closed
3 tasks
@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Feb 2, 2021
This was referenced Apr 13, 2021
Merged
Merged
@PushkarJ PushkarJ mentioned this issue Apr 17, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@puerco puerco

Labels
area/release-eng Issues or PRs related to the Release Engineering subproject kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. sig/release Categorizes an issue or PR as relevant to SIG Release.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add CVE Information to Release Notes puerco/release
10 participants
@cji @saschagrunert @lasomethingsomething @tpepper @puerco @k8s-ci-robot @tallclair @fejta-bot @k8s-release-robot @lauriapple2