[SRU] libreoffice 6.4.7.2.M3 for Focal
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| libreoffice (Ubuntu) |
Invalid
|
Undecided
|
Rico Tzschichholz | ||
| Focal |
Incomplete
|
High
|
Rico Tzschichholz | ||
Bug Description
[Impact]
* LibreOffice 6.4.7.2.M3 is a bug-fix release of the 6.4 line:
It receives important bug-fixes on top of the 6.4 branch which is EOL since November 30, 2020. Currently maintained by Andras Timar for France's MIMO (https:/
* Version 6.4.7 is currently released in focal.
https:/
(that's a total of ?? bugs)
* Given the nature of the project, the complexity of the codebase and the high level of quality assurance upstream, it is preferable to SRU a minor release rather than cherry-pick selected bug fixes.
[Testing]
* Launchpad testing. The libreoffice packages include autopkgtests that were run and verified as passing.
https:/
* [amd64] https:/
* [arm64] https:/
* [armhf] https:/
* [ppc64el] https:/
* [s390x] https:/
* General smoke testing of all the applications in the office suite were carried out by going through the manual testplan as documented by: https:/
[Regression Potential]
* A minor release with a total of ?? bug fixes always carries the potential for introducing regressions, even though it is a bug-fix-only release, meaning that no new features were added, and no existing features were removed.
* A combination of autopkgtests and careful smoke testing as described above should provide reasonable confidence that no regressions sneaked in.
CVE References
| Changed in libreoffice (Ubuntu): | |
| assignee: | nobody → Rico Tzschichholz (ricotz) |
| Changed in libreoffice (Ubuntu Focal): | |
| assignee: | nobody → Rico Tzschichholz (ricotz) |
| summary: |
- [SRU] libreoffice 6.4.7.2.M1 for Focal + [SRU] libreoffice 6.4.7.2.M3 for Focal |
| description: | updated |
| description: | updated |
| Changed in libreoffice (Ubuntu Focal): | |
| status: | New → Triaged |
| importance: | Undecided → High |
| Changed in libreoffice (Ubuntu): | |
| status: | New → Invalid |
| Łukasz Zemczak (sil2100) wrote | #1 |
| Changed in libreoffice (Ubuntu Focal): | |
| status: | Triaged → Incomplete |
| Robie Basak (racb) wrote | #2 |
This is a bit of a tricky situation I think. Let me elaborate.
We allow new upstream releases for certain projects because of a certain trust shift - for upstream projects that have a sufficient quality assurance story and clear bugfix policy, we allow updating the whole version instead of requiring testing of every single change separately. Basically this is this section of the policy, even though it's a bit vague:
https:/
In this case, when the upstream branch of libreoffice is EOL and us switching to an unofficial branch with fixes, I think we no longer fit this policy. We can put certain level of trust to upstream developers preparing upstream releases, by shifting trust to upstream we can skip certain parts of our SRU review and verification, simply assuming that - for instance - the bugfixes listed in the changes are accurate with what's actually in the tarball. I don't think we can say the same thing about a version that is officially EOL in the mind of upstream. We certainly can't blindly trust what's in that codebase, and therefore just running the usual 'autopkgtests' + usual test-case won't work from the SRU perspective, sadly.
In this case, I think I only see two options:
a) Switching users of focal to a non-EOL version of libreoffice. This would of course require much more testing (maybe even a call for testing from other users), but as you already mentioned on IRC: there is risk that user extensions would be broken by this. And I think regressing existing users might be a breach of policy as well... so I'm not sure we can pull this off.
b) Cherry-picking *single fixes* from the aforementioned MIMO branch, each fix having a separate test-case i.e. following the regular per-bugfix SRU policy.
I know this situation is not ideal, but I don't think we can realistically do much more. We can pull in more SRU members for comment though, maybe someone would have a better idea.