Hello Michael,
Hello,
On 31 Mar 2022, at 08:54, Peter Müller peter.mueller@ipfire.org wrote:
Hello Michael,
thanks for your reply.
Hello Peter,
Welcome back.
On 31 Mar 2022, at 07:45, Peter Müller peter.mueller@ipfire.org wrote:
Hello Michael, hello *,
back at my desk, I saw your commits to the IPFire 2.x repository, and would like to confer the procedure of Core Updates 166 and 167 with you.
Given the current circumstances, I think it would make sense to treat Core Update 166 as a more pressing, security-relevant update, having the following issues covered:
No, Core Update 166 will be a single-issue update only. That being said, I already cherry-picked the fix for the zlib issue since it has already been in next.
I see. However, that zlib patch of mine is not sufficient anymore, since another memory corruption vulnerability showed up in zlib as well. I understand the urgency of Core Update 166, but still think shipping zlib 1.2.12 makes more sense to have all the nasty things covered. :-)
Great.
We can either ship zlib, or don’t ship it. But I am not prepared to extend the list of things because this is causing delays. In fact, the zlib update was already a mistake because it is now causing extra delays.
We won’t be able to ship a release that fixes *all* the bugs at the same time. That would be great, but we have to be realistic and reliably ship fixes for problems that we know can be fixed and have been fixed.
I see, then leave things as they are to get Core Update 166 released fast.
Thanks, and best regards, Peter Müller
-Michael
I continue working on Core Update 167 then.
Thanks, and best regards, Peter Müller
The other things are either not pressing, not relevant to us, or simply not feasible to be built and tested within 24 hours.
All changes regarding to those issues should be merged into next and be released with c167.
- zlib: memory corruption (CVE-2018-25032 et al.)
[I am working on a patch, as the current one is not sufficient anymore.]
- Linux kernel: CVE-2022-1015, CVE-2022-1016
[I volounteer to work on this.]
apache: See https://patchwork.ipfire.org/project/ipfire/patch/20220316160912.1569-1-matt...
bind: See https://patchwork.ipfire.org/project/ipfire/patch/20220322173203.1633-1-matt...
Aside from that, I would like to ship as many bugfixes that are currently staged in Core Update 167 with Core 166, to avoid unnecessary delays for the users.
Yes, those delays will be there, but since we are running on limited capacity at the moment, this is as good as it gets.
There is otherwise a chance that we are going to ship any regressions (like the backup one) which will cause even more work and further delays.
Also, I will hand in a patch fixing #12807, which fell through the cracks due to high workload on my end. It is currently a show-stopper for IPFire Tor users. :-/
See?
Does this sound fine to you? If so, since I cannot commit into the master branch, how should we coordinate this so you won't have the entire load of cherry-picking on your shoulders?
Regarding Core Update 167, I would see what's left in there after Core 166 is near- finished. Thanks for the linux-firmware patchset, but I am afraid this still leaves us with an update of an estimated size of 150 MBytes, which is too much.
It either has to be that, or we don’t ship this at all.
At the moment, the only possibility I see is not to ship linux-firmware, but rather compress the files on the installations during the update.
This is going to be complicated and I would rather say, that we leave things as-is.
-Michael
Thanks, and best regards, Peter Müller