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:
- 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.
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. :-/
***
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.
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.
Thanks, and best regards, Peter Müller
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.
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
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. :-)
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
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.
-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
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
Hello development folks,
being responsible for upcoming Core Update 167, I would like to close this update roughly at the beginning of next week. This is because it contains several security-relevant updates (such as Apache, Bind [might need another one?], zlib [again], OpenSSH, and so on) which I think should be available to our userbase as soon as possible.
To have CVE-2022-1015 and CVE-2022-1016 covered, I will submit a patch for an updated kernel later this day, since we have enough space to ship one as the linux-firmware changes were reverted (see 8a4780de645a5b3ab42054eaf022c57d6849ae9a).
Looking at Patchwork, it would be great if we could clarify the status of these patches and patch series, and whether they should go into Core Update 167 or not: - https://patchwork.ipfire.org/project/ipfire/list/?series=2684 - https://patchwork.ipfire.org/project/ipfire/list/?series=2698 - https://patchwork.ipfire.org/project/ipfire/patch/66e4978d-6ba4-6c14-329c-6f...
If there are any patches sitting around in your local/private repositories you want to have in Core Update 167, kindly post them. As always, drop me a line in case of questions or comments.
Thanks, and best regards, Peter Müller
Hello Peter,
On 2 Apr 2022, at 08:42, Peter Müller peter.mueller@ipfire.org wrote:
Hello development folks,
being responsible for upcoming Core Update 167, I would like to close this update roughly at the beginning of next week. This is because it contains several security-relevant updates (such as Apache, Bind [might need another one?], zlib [again], OpenSSH, and so on) which I think should be available to our userbase as soon as possible.
I don’t have anything left. Please await the conference call on Monday for a final decision.
To have CVE-2022-1015 and CVE-2022-1016 covered, I will submit a patch for an updated kernel later this day, since we have enough space to ship one as the linux-firmware changes were reverted (see 8a4780de645a5b3ab42054eaf022c57d6849ae9a).
Please consult with Arne on this. There are lots of small details that need to be considered.
And I am sure he has a branch with an updated kernel somewhere already.
However, I really would like a new kernel in this release, even if that will take us a few days longer.
Looking at Patchwork, it would be great if we could clarify the status of these patches and patch series, and whether they should go into Core Update 167 or not:
I will leave this for Stefan.
I was awaiting some response from Anthony. I am not sure whether we can take silence as approval but since he has approved the previous version of the patchset which has just been extended, I am sure this is okay to merge.
This is something for Arne.
If there are any patches sitting around in your local/private repositories you want to have in Core Update 167, kindly post them. As always, drop me a line in case of questions or comments.
Thanks, and best regards, Peter Müller
-Michael
Hello Michael,
thanks for your reply.
Hello Peter,
On 2 Apr 2022, at 08:42, Peter Müller peter.mueller@ipfire.org wrote:
Hello development folks,
being responsible for upcoming Core Update 167, I would like to close this update roughly at the beginning of next week. This is because it contains several security-relevant updates (such as Apache, Bind [might need another one?], zlib [again], OpenSSH, and so on) which I think should be available to our userbase as soon as possible.
I don’t have anything left. Please await the conference call on Monday for a final decision.
Yes, I was planning to do so. Just thought a preliminary notice would be in order...
To have CVE-2022-1015 and CVE-2022-1016 covered, I will submit a patch for an updated kernel later this day, since we have enough space to ship one as the linux-firmware changes were reverted (see 8a4780de645a5b3ab42054eaf022c57d6849ae9a).
Please consult with Arne on this. There are lots of small details that need to be considered.
And I am sure he has a branch with an updated kernel somewhere already.
However, I really would like a new kernel in this release, even if that will take us a few days longer.
Oh, I overlooked your mail before submitting that Linux 5.15.32 patch. Sorry.
Arne working on a kernel was also my impression, but with a look at people/arne_f/kernel.git and people/arne_f/ipfire-2.x.git, I did not find anything I could pick up. So I thought I do a kernel update to once in a while, trying to reduce the bus factor on this end. :-)
Looking at Patchwork, it would be great if we could clarify the status of these patches and patch series, and whether they should go into Core Update 167 or not:
I will leave this for Stefan.
I was awaiting some response from Anthony. I am not sure whether we can take silence as approval but since he has approved the previous version of the patchset which has just been extended, I am sure this is okay to merge.
I will wait until Monday for his reply then, and merge it if no negative feedback arrives until then.
Thanks, and best regards, Peter Müller
This is something for Arne.
If there are any patches sitting around in your local/private repositories you want to have in Core Update 167, kindly post them. As always, drop me a line in case of questions or comments.
Thanks, and best regards, Peter Müller
-Michael
Hello,
On 2 Apr 2022, at 12:30, Peter Müller peter.mueller@ipfire.org wrote:
Hello Michael,
thanks for your reply.
Hello Peter,
On 2 Apr 2022, at 08:42, Peter Müller peter.mueller@ipfire.org wrote:
Hello development folks,
being responsible for upcoming Core Update 167, I would like to close this update roughly at the beginning of next week. This is because it contains several security-relevant updates (such as Apache, Bind [might need another one?], zlib [again], OpenSSH, and so on) which I think should be available to our userbase as soon as possible.
I don’t have anything left. Please await the conference call on Monday for a final decision.
Yes, I was planning to do so. Just thought a preliminary notice would be in order...
Good thinking :)
To have CVE-2022-1015 and CVE-2022-1016 covered, I will submit a patch for an updated kernel later this day, since we have enough space to ship one as the linux-firmware changes were reverted (see 8a4780de645a5b3ab42054eaf022c57d6849ae9a).
Please consult with Arne on this. There are lots of small details that need to be considered.
And I am sure he has a branch with an updated kernel somewhere already.
However, I really would like a new kernel in this release, even if that will take us a few days longer.
Oh, I overlooked your mail before submitting that Linux 5.15.32 patch. Sorry.
Arne working on a kernel was also my impression, but with a look at people/arne_f/kernel.git and people/arne_f/ipfire-2.x.git, I did not find anything I could pick up. So I thought I do a kernel update to once in a while, trying to reduce the bus factor on this end. :-)
Please consult with him no matter what. Arne is not always pushing all changes to his repositories and you know how much he replies on the list.
Looking at Patchwork, it would be great if we could clarify the status of these patches and patch series, and whether they should go into Core Update 167 or not:
I will leave this for Stefan.
I was awaiting some response from Anthony. I am not sure whether we can take silence as approval but since he has approved the previous version of the patchset which has just been extended, I am sure this is okay to merge.
I will wait until Monday for his reply then, and merge it if no negative feedback arrives until then.
Silence is not an ack. We should not have this culture here.
If this is urgent, please get in touch with him. I am sure you have his phone number :)
-Michael
Thanks, and best regards, Peter Müller
This is something for Arne.
If there are any patches sitting around in your local/private repositories you want to have in Core Update 167, kindly post them. As always, drop me a line in case of questions or comments.
Thanks, and best regards, Peter Müller
-Michael
Hi,
I think we should include the solution for bug #12838, if possible. It isn't an urgent repair, but reinstalls the graphical presentation of the hostile hits. This can be helpful for a first impression about these fw hits.
Just another idea. Seeing many CTINVALID messages, it would be nice to show them in the fwhits graph also.
Regards, Bernhard
Am 02.04.2022 um 13:00 schrieb Michael Tremer:
Hello Peter,
On 2 Apr 2022, at 08:42, Peter Müller peter.mueller@ipfire.org wrote:
Hello development folks,
being responsible for upcoming Core Update 167, I would like to close this update roughly at the beginning of next week. This is because it contains several security-relevant updates (such as Apache, Bind [might need another one?], zlib [again], OpenSSH, and so on) which I think should be available to our userbase as soon as possible.
I don’t have anything left. Please await the conference call on Monday for a final decision.
To have CVE-2022-1015 and CVE-2022-1016 covered, I will submit a patch for an updated kernel later this day, since we have enough space to ship one as the linux-firmware changes were reverted (see 8a4780de645a5b3ab42054eaf022c57d6849ae9a).
Please consult with Arne on this. There are lots of small details that need to be considered.
And I am sure he has a branch with an updated kernel somewhere already.
However, I really would like a new kernel in this release, even if that will take us a few days longer.
Looking at Patchwork, it would be great if we could clarify the status of these patches and patch series, and whether they should go into Core Update 167 or not:
I will leave this for Stefan.
I was awaiting some response from Anthony. I am not sure whether we can take silence as approval but since he has approved the previous version of the patchset which has just been extended, I am sure this is okay to merge.
This is something for Arne.
If there are any patches sitting around in your local/private repositories you want to have in Core Update 167, kindly post them. As always, drop me a line in case of questions or comments.
Thanks, and best regards, Peter Müller
-Michael
Hello Peter,
thanks for working and coordinating the next core update in this way.
Hello development folks,
being responsible for upcoming Core Update 167, I would like to close this update roughly at the beginning of next week. This is because it contains several security-relevant updates (such as Apache, Bind [might need another one?], zlib [again], OpenSSH, and so on) which I think should be available to our userbase as soon as possible.
To have CVE-2022-1015 and CVE-2022-1016 covered, I will submit a patch for an updated kernel later this day, since we have enough space to ship one as the linux-firmware changes were reverted (see 8a4780de645a5b3ab42054eaf022c57d6849ae9a).
Looking at Patchwork, it would be great if we could clarify the status of these patches and patch series, and whether they should go into Core Update 167 or not:
Please ignore that patch set.
I'm currently working on improving the IDS again and these patches are obsolete and safely can be dropped.
More about this project on Monday.
Best regards,
-Stefan
https://patchwork.ipfire.org/project/ipfire/patch/66e4978d-6ba4-6c14-329c-6f...
If there are any patches sitting around in your local/private repositories you want to have in Core Update 167, kindly post them. As always, drop me a line in case of questions or comments.
Thanks, and best regards, Peter Müller
Hello,
Hope I'm not too late with this. Since a week I have running the latest APU firmware ( v4.16.02 ) on my system. Found no problems until now, but an enhancement. The AMD PSP CCP is now found as entropy source. So the boot process is faster.
This may be useful for many IPFire users. Is it possible to include in CU 167?
Regards, Bernhard
Am 02.04.2022 um 09:42 schrieb Peter Müller:
Hello development folks,
being responsible for upcoming Core Update 167, I would like to close this update roughly at the beginning of next week. This is because it contains several security-relevant updates (such as Apache, Bind [might need another one?], zlib [again], OpenSSH, and so on) which I think should be available to our userbase as soon as possible.
To have CVE-2022-1015 and CVE-2022-1016 covered, I will submit a patch for an updated kernel later this day, since we have enough space to ship one as the linux-firmware changes were reverted (see 8a4780de645a5b3ab42054eaf022c57d6849ae9a).
Looking at Patchwork, it would be great if we could clarify the status of these patches and patch series, and whether they should go into Core Update 167 or not:
- https://patchwork.ipfire.org/project/ipfire/list/?series=2684
- https://patchwork.ipfire.org/project/ipfire/list/?series=2698
- https://patchwork.ipfire.org/project/ipfire/patch/66e4978d-6ba4-6c14-329c-6f...
If there are any patches sitting around in your local/private repositories you want to have in Core Update 167, kindly post them. As always, drop me a line in case of questions or comments.
Thanks, and best regards, Peter Müller
Hello,
I would recommend creating a patch for this.
And since we need to test this a little bit before we release it, I would schedule it for c168.
-Michael
On 11 Apr 2022, at 07:21, Bernhard Bitsch bbitsch@ipfire.org wrote:
Hello,
Hope I'm not too late with this. Since a week I have running the latest APU firmware ( v4.16.02 ) on my system. Found no problems until now, but an enhancement. The AMD PSP CCP is now found as entropy source. So the boot process is faster.
This may be useful for many IPFire users. Is it possible to include in CU 167?
Regards, Bernhard
Am 02.04.2022 um 09:42 schrieb Peter Müller:
Hello development folks, being responsible for upcoming Core Update 167, I would like to close this update roughly at the beginning of next week. This is because it contains several security-relevant updates (such as Apache, Bind [might need another one?], zlib [again], OpenSSH, and so on) which I think should be available to our userbase as soon as possible. To have CVE-2022-1015 and CVE-2022-1016 covered, I will submit a patch for an updated kernel later this day, since we have enough space to ship one as the linux-firmware changes were reverted (see 8a4780de645a5b3ab42054eaf022c57d6849ae9a). Looking at Patchwork, it would be great if we could clarify the status of these patches and patch series, and whether they should go into Core Update 167 or not:
- https://patchwork.ipfire.org/project/ipfire/list/?series=2684
- https://patchwork.ipfire.org/project/ipfire/list/?series=2698
- https://patchwork.ipfire.org/project/ipfire/patch/66e4978d-6ba4-6c14-329c-6f...
If there are any patches sitting around in your local/private repositories you want to have in Core Update 167, kindly post them. As always, drop me a line in case of questions or comments. Thanks, and best regards, Peter Müller
On Monday 11 April 2022 07:21 Bernhard Bitsch wrote:
Hello,
Hope I'm not too late with this. Since a week I have running the latest APU firmware ( v4.16.02 ) on my system. Found no problems until now, but an enhancement. The AMD PSP CCP is now found as entropy source. So the boot process is faster.
This may be useful for many IPFire users. Is it possible to include in CU 167?
Regards, Bernhard
Poor entropy on my APU2 E4 has been a serious problem so much so that I will do anything not to re-boot IPFire. I wasn't aware that this was a firmware problem so this is really good news.
I hope the new firmware will soon be available via pakfire.
Rob
-
Bernhard Bitsch -
Michael Tremer -
Peter Müller -
Rob Brewer -
Stefan Schantl