Hi Paul, Thanks for your answer. I was kind of expecting an answer like this one, so I'm not surprised. Let me answer to your points one by one. I've tried to be precise, hopefully, this isn't a too long answer...
On 4/22/21 11:27 AM, Paul Gevers wrote: > Control: tags -1 moreinfo > > Hi Thomas, > > On 21-04-2021 22:33, Thomas Goirand wrote: >> I've uploaded version 14.2.20-2 of Ceph. This is the last point release >> from usptream, including the fixes for CVE-2021-20288 and CVE-2020-27839. >> >> With such large software such as Ceph, the debdiff can be quite big. >> This unfortunately is no exception. I understand that the rule is that >> the release team insist reviewing all changes. That's clearly not >> possible considering the debdiff size. However, I don't think it is >> reasonable to not include point release fixes from upstream, just like >> we do with other large software in Debian. I intend to keep Ceph 14.2.x >> updated during the lifetime of Bullseye, following upstream updates, >> hopefully you will agree that this is the sensitive thing to do. > > As I have no clue what Ceph is tl;dr: It's the state of the art in distributed storage. :) Longer version: FYI, Ceph is a highly distributed storage system. It provides block storage, object storage, and file system shares over network. It stores everything in blocks of (by default) 4MB, which are then distributed in all the physical block devices of the cluster. The bigger the cluster is, the faster it goes. Typically, a Ceph cluster would be setup with at least 10 servers of 8 SSD each (plus 3 ceph monitor servers). It is the preferred way to provide block storage for OpenStack instances (and that is why I co-maintain it). If you didn't know, the company behind Ceph (called Intank) was acquired by Red Hat a few years ago, and Ceph is clearly one of their leading product. > and how their releases work, to make this > acceptable you'll have to elaborate on why a new upstream release > complies with our freeze policy. Please look at the questions in our FAQ > [1], section "I want to add a new upstream release, is that possible?" Sure, I understand. Let me go through each points, and let me know your thoughts. Hopefully, that is what you're expecting (let me know if I'm doing wrongly here...). 1/ Is this a targeted bug fix release, and how does that show? Yes. Ceph 14.2.x (aka: Nautilus) has been in maintenance mode for a long time already (it was first released in 2019). It only receive a few bugfixes regularly. Unfortunately, we can't upload 16.2.x in Bullseye (or even 15.2.x) because it wouldn't allow upgrading from Buster. 2/ What are the risks of the changes for the quality of the Debian release? Well, I don't see why version 14.2.16 (currently in Testing) would be of less risks than version 14.2.20. It received the same amount of test from me, and also received a lot of tests from upstream (including integration tests). They both work. Just 14.2.16 has open CVEs, and more bugs, as per the release notes (see below). 3/ Is there a policy that describes what upstream considers acceptable for this upstream release? Yes. It's described here: https://docs.ceph.com/en/latest/releases/general/ >From that page: For each stable release: > Integration and upgrade tests are run on a regular basis and their > results analyzed by Ceph developers. > > Issues fixed in the development branch (master) are scheduled to be > backported. > > When an issue found in the stable release is reported, it is > triaged by Ceph developers. > > The stable releases and backport team publishes point releases > including fixes that have been backported to the stable release. This feels very reasonable to me. 4/ Does that policy align with our bug severity important or higher? I believe so. There's "(occasionally) feature backports" described on the above policy, though I don't think this happens much these days in the 14.2.x branch which is getting kind of old. 5/ Does upstream test thoroughly? Yes. They have unit and functional tests, as described in the above link. 6/ Has this package seen new upstream version uploads to stable in the past to facilitate security support? Yes. Without troubles. 7/ Look at the diff. If it's long (TODO should we put a number here?), you probably need a targeted fix. I very much prefer to trust what upstream does, than trying to backport very complicated CVE patches when they come. I'm a package maintainer, not a boost and C++ expert. Even though I have some skills, I cannot pretend that I know better than upstream. 8/ Look at the diff. If there's a number of changes not relevant for Debian, you probably need a targeted fix. I don't pretend I can understand what's in there, it's just too large as well, and neither does anyone not involved in upstream Ceph development. Though I can read through the list of bugfixes, and understand that I want them in Bullseye. 9/ Look at the diff. If there something in there that is difficult to explain, but not directly related to the (RC or important) bugs you are fixing, you probably need a targeted fix. Ditto. > We don't *just* accept new upstreams for "other large software", we > still need to judge somehow (even more so if we can't reasonably do that > by manual inspection of the diff) that that's appropriate. I know the rules, and I understand them. Though looking in what happened with Ceph, I just believe it's easier and better for everyone if we can follow the stable point releases of upstream through the lifetime of Debian Stable. I do intend to ask updates in bullseye proposed-updates later on, because in the past, upstream has shown they do maintain this carefully. If you want to have a look at the release notes, it's here: https://docs.ceph.com/en/latest/releases/nautilus/ The bulk of the changes are in version 14.2.17 (that's from where the bulk of the changes are comming), then version 14.2.18, 14.2.19 and 14.2.20 were corrections to that. Note that version 14.2.19 was due to *MY* patch, where I needed to have the daemon binding on an IP on the lo interface. I discovered it when trying 14.2.20, and seeing that it was kind of reverted, which is why I uploaded version 14.2.20-2 in Debian, with a new patch. I'm now expecting a new patch from upstream, having a smarter way to exclude 127.0.0.0/8 from binding, while still allowing a bgp-to-the-host setup that we're doing with OpenStack. We've since upgraded our (pre-production) cluster (which runs Bullseye) to 14.2.20-2 without any issue. >> I've uploaded the debdiff here: >> http://shade.infomaniak.ch/ceph_14.2.20-2.debdiff > > That URL gives a 404. Please attach it to this bug for future reference > (yes, it may not make it to the list, but then the bts has it). > > Paul Oh, I'm stupid. I simply deleted the debdiff when doing some clean-ups on that server. It's there now again, if you want to look. I'm sorry, but my MTA is configured to not accept anything that is bigger than 8MB, so I can't send such a large file by mail. Cheers, Thomas Goirand (zigo)
