Include latest versions of 1.7 and 1.8 and 1.9 without cve patches #8991
Conversation
|
/cherry-pick release-1.9 |
|
@jacob-delgado: once the present PR merges, I will cherry-pick it on top of release-1.9 in a new PR and assign it to you. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
| @@ -53,15 +53,16 @@ current `<minor>` release. A patch is usually a small change relative to the `<m | |||
| | master | No, development only | | | | | | |||
| | 1.9 | N/A | ~Feb 2021(Expected) | ~Aug 2021(Expected) | 1.17, 1.18, 1.19, 1.20 | 1.15, 1.16 | | |||
| | 1.8 | Yes | November 10, 2020 | ~May 2021(Expected) | 1.16, 1.17, 1.18, 1.19 | 1.15 | | |||
| | 1.7 | Yes | August 21, 2020 | ~Feb 2021(Expected) | 1.16, 1.17, 1.18 | 1.15 | | |||
| | 1.7 | Yes | August 21, 2020 | Feb 19, 2021 | 1.16, 1.17, 1.18 | 1.15 | | |||
| | 1.6 | No | May 21, 2020 | November 23, 2020 | 1.15, 1.16, 1.17, 1.18 | | | |||
| | 1.5 and earlier | No | | | | | | |||
|
|
|||
| ## Releases without known Common Vulnerabilities and Exposures (CVEs) | |||
|
|
|||
| | LTS Release | Patched versions with no known CVEs | | |||
There was a problem hiding this comment.
I recall some discussion recently about removing LTS from this and or other pages. We seem to have at least removed that from the vocabulary, but still seem to call a 1.x either a minor (on this page) or major (on https://preliminary.istio.io/latest/news/). We should probably decide on which it should be (maybe this was already decided, just not implemented?) and change everything to match.
There is also a mention of LTS at the end of an earlier paragraph.
There was a problem hiding this comment.
Removed reference to LTS. I know @therealmitchconnors is suggesting LTS in the future, but for now the Istio community doesn't have such a concept. Only a supported window. This was in a previous PR. I've changed such references to "minor" releases.
| This page lists the status, timeline and policy for currently supported releases. Supported releases of Istio include | ||
| releases that are in the active maintenance window and are patched for security and bug fixes. Subsequent patch releases | ||
| on a minor release do not contain backward incompatible changes. |
There was a problem hiding this comment.
Review comments from https://github.com/istio/istio.io/pull/8758/files#r558346770
| The various types of releases represent a different product quality level and level of assistance from the Istio community. | ||
| In this context, *support* means that the community will produce patch releases for critical issues and offer technical | ||
| assistance. Separately, 3rd parties and partners may offer longer-term support solutions. |
There was a problem hiding this comment.
| | 1.8 | Yes | November 10, 2020 | ~May 2021(Expected) | 1.16, 1.17, 1.18, 1.19 | 1.15 | | ||
| | 1.7 | Yes | August 21, 2020 | ~Feb 2021(Expected) | 1.16, 1.17, 1.18 | 1.15 | | ||
| | 1.7 | No | August 21, 2020 | Feb 19, 2021 | 1.16, 1.17, 1.18 | 1.15 | |
There was a problem hiding this comment.
Probably need to wait for the actual release, but appears there will be a 1.7.8 on 2/25 so need to update the EOL here and add 1.7.8 to the table below.
|
@istio/steering-committee Steering asked TOC to consider moving to N-2 supported releases. In the TOC meeting at 2019/10/25 we deferred this discussion based on assessments that the older releases in that window would be very expenseice to maintain, e.g. 1.5. Things have moved on a bit so it might be worthwhile assessing if we've paid down enough debt to make the change steering has asked for in this release or the next ? |
|
One more comment, could a release listed like 1.6.11+ (and soon 1.7), since it's out of support, end up with a CVE that wasn't fixed and we still have it in this chart? Or is part of the process to make sure this chart is updated as security releases happen. |
|
Vendors are starting to fill this gap. Solo's Gloo Mesh Enterprise promises N-3, and Tetrate's product-formerly-known-as-GetIstio "ensures that all Istio releases are supported for at least 14 months from release date." Could we save them some effort by bringing this into the community? |
|
Unfortunately, I'm not sure we have the resources in Istio right now to support 15 month, especially with our dependencies having lower support lifetimes. Hard enough challenge right now to get 1.10 release managers. |
|
I think people need to be very very careful about "CVE patch support" vs "bug fix support". While supporting CVEs is a lot of effort, it is essentially impossible* to support bug fixes for 15 months. The end result will be people running old versions, expecting them to work well, when in reality we cannot guarantee that at all - rather, we only ensure that known CVEs are patched (which, in reality, for many users this doesn't really matter that much, as most of our CVEs impact only a small number of users). In the end, the average user ends up with a worse version of Istio, they think "wow, Istio sucks" and stop using it. The "CVE and critical bug fix only" model works well for linux distros because they are doing this for something like * if we support bug fixes for this long, the only way to feasible patch bugs is to backport the entirety of the |
|
When we discussed this previously I thought the decision had been that interested commercial entities should be responsible for that work, i.e. the community would continue with their declared support and that the effort for supporting older versions would be handled by the companies involved albeit possibly in the community branches. |
I see this being best effort. Going forward the PSWG is trying to assess versions that may be affected by a vulnerability. For unsupported releases (like 1.6 and 1.7) we can keep this on the list until we know of a CVE. We can also remove unsupported versions. Thoughts? I'm fine with keeping it in, but it gives the impression that 1.6/1.7 will be patched, when they won't. |
|
I'm a bigger fan of removing unsupported versions from that list. I think that when a CVE comes out after a release comes out, it's better from the Istio support point of view to assume that the CVE is present in that release than to assume that it isn't. |
This is more or less what we did in Envoy. Mainline and N-1 (or maybe N-2 now?) are supported by Envoy maintainers, but older releases and backports are responsibility of the "Stable Releases" maintainers, a disjoint set of people from communities and vendors offering long-term support (Google, Tetrate, etc.). I think it works pretty well. See: https://github.com/envoyproxy/envoy/blob/main/RELEASES.md. |
|
In response to a cherrypick label: new pull request created: #9079 |
Updated supported releases page to show versions without CVEs and add Istio 1.9.0
Also update supported release date for 1.7 EOL
[ ] Configuration Infrastructure
[X] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure