The Upcoming Core Update(s)

The Upcoming Core Update(s)

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

Hello everyone,

Since this month’s video conference has been canceled, here is a couple of updates from my side:

* Core Update 181 has been branched yesterday. I have this running in my office for a little while and it seems to be a solid update. It also has a lot of security fixes, so please give it a good test that we can hopefully release this in two weeks.

* For the following update(s): what do we have in the pipeline? Just to coordinate that we don’t have too much in one update :)

Best,
-Michael

Re: The Upcoming Core Update(s)

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

Hello Michael,
hello *,

> Hello everyone,
> 
> Since this month’s video conference has been canceled, here is a couple of updates from my side:
> 
> * Core Update 181 has been branched yesterday. I have this running in my office for a little while and it seems to be a solid update. It also has a lot of security fixes, so please give it a good test that we can hopefully release this in two weeks.

indeed, Core Update 181 seems to work fine without any hiccups whatsoever. :-)

> * For the following update(s): what do we have in the pipeline? Just to coordinate that we don’t have too much in one update :)

Unless we have more pressing things on our agenda, I remember Adolf saying
that there are still a couple of packages, particularly libraries, which he
did not had the resources to work through. At some point, it might be sensible
to have something like a distributed mini-hackathon to ensure that everything
we include is at least roughly up to date, and if it's just by slicing the
package list and distribute the shares. :-)

At some point, I had the idea to keep an eye on various security advisories
published by other distributions to identify non-prolific packages with
important updates that might otherwise have flown under our radar, but this
approach never worked well...

Aside from updating, I recall Stefan working on porting firewall groups to
ipset a while ago. Perhaps this is something we can then focus on to push
out of the door next?

Just my two cents. I currently do not have anything major on my docket list
for IPFire 2.x. :-)

All the best,
Peter Müller

Re: The Upcoming Core Update(s)

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]

Hi Michael,

I am back from my holiday trip visiting my family and friends in the UK.

I will be working again on the OpenVPN package but that won't be ready for CU182.

I am currently working through about 20 package updates which should get submitted over the next couple of days.

I have some minor bug fixes that may get submitted in time for CU182.

Overall, for CU182, there is nothing critical that I am working on beyond normal package updates, so you can decide form the patches I submit what to use and what to leave for a following CU.


Regards,

Adolf.


On 07/11/2023 19:22, Peter Müller wrote:
> Hello Michael,
> hello *,
>
>> Hello everyone,
>>
>> Since this month’s video conference has been canceled, here is a couple of updates from my side:
>>
>> * Core Update 181 has been branched yesterday. I have this running in my office for a little while and it seems to be a solid update. It also has a lot of security fixes, so please give it a good test that we can hopefully release this in two weeks.
> indeed, Core Update 181 seems to work fine without any hiccups whatsoever. :-)
>
>> * For the following update(s): what do we have in the pipeline? Just to coordinate that we don’t have too much in one update :)
> Unless we have more pressing things on our agenda, I remember Adolf saying
> that there are still a couple of packages, particularly libraries, which he
> did not had the resources to work through. At some point, it might be sensible
> to have something like a distributed mini-hackathon to ensure that everything
> we include is at least roughly up to date, and if it's just by slicing the
> package list and distribute the shares. :-)
>
> At some point, I had the idea to keep an eye on various security advisories
> published by other distributions to identify non-prolific packages with
> important updates that might otherwise have flown under our radar, but this
> approach never worked well...
>
> Aside from updating, I recall Stefan working on porting firewall groups to
> ipset a while ago. Perhaps this is something we can then focus on to push
> out of the door next?
>
> Just my two cents. I currently do not have anything major on my docket list
> for IPFire 2.x. :-)
>
> All the best,
> Peter Müller

Re: The Upcoming Core Update(s)

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 3124 bytes --]

Hello *,

being in charge of mastering Core Update 182, I've just created the new update,
and added most of the pending patches from Patchwork. The latter is not quite
complete yet; I strive to be up to speed by the end of this week.

As far as package updates are concerned, I'd like to update the following ones,
unless someone else is already working on them:

- OpenSSH
- strongSwan
- Tor

In C182, we have a linux-firmware update, which already takes quite some breathing
room in terms of file size. Unless something urgent comes up, it might be sensible
to close this update sooner rather than later, so it can go into testing once
Core Update 181 is released.

Thoughts/comments?

Thanks, and best regards,
Peter Müller

> Michael,
> 
> I am back from my holiday trip visiting my family and friends in the UK.
> 
> I will be working again on the OpenVPN package but that won't be ready for CU182.
> 
> I am currently working through about 20 package updates which should get submitted over the next couple of days.
> 
> I have some minor bug fixes that may get submitted in time for CU182.
> 
> Overall, for CU182, there is nothing critical that I am working on beyond normal package updates, so you can decide form the patches I submit what to use and what to leave for a following CU.
> 
> 
> Regards,
> 
> Adolf.
> 
> 
> On 07/11/2023 19:22, Peter Müller wrote:
>> Hello Michael,
>> hello *,
>>
>>> Hello everyone,
>>>
>>> Since this month’s video conference has been canceled, here is a couple of updates from my side:
>>>
>>> * Core Update 181 has been branched yesterday. I have this running in my office for a little while and it seems to be a solid update. It also has a lot of security fixes, so please give it a good test that we can hopefully release this in two weeks.
>> indeed, Core Update 181 seems to work fine without any hiccups whatsoever. :-)
>>
>>> * For the following update(s): what do we have in the pipeline? Just to coordinate that we don’t have too much in one update :)
>> Unless we have more pressing things on our agenda, I remember Adolf saying
>> that there are still a couple of packages, particularly libraries, which he
>> did not had the resources to work through. At some point, it might be sensible
>> to have something like a distributed mini-hackathon to ensure that everything
>> we include is at least roughly up to date, and if it's just by slicing the
>> package list and distribute the shares. :-)
>>
>> At some point, I had the idea to keep an eye on various security advisories
>> published by other distributions to identify non-prolific packages with
>> important updates that might otherwise have flown under our radar, but this
>> approach never worked well...
>>
>> Aside from updating, I recall Stefan working on porting firewall groups to
>> ipset a while ago. Perhaps this is something we can then focus on to push
>> out of the door next?
>>
>> Just my two cents. I currently do not have anything major on my docket list
>> for IPFire 2.x. :-)
>>
>> All the best,
>> Peter Müller

Re: The Upcoming Core Update(s)

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 3415 bytes --]

Hi Peter,

On 21/11/2023 21:39, Peter Müller wrote:
> Hello *,
>
> being in charge of mastering Core Update 182, I've just created the new update,
> and added most of the pending patches from Patchwork. The latter is not quite
> complete yet; I strive to be up to speed by the end of this week.
>
> As far as package updates are concerned, I'd like to update the following ones,
> unless someone else is already working on them:
>
> - OpenSSH
> - strongSwan
I have already built the updated version of strongswan and will submit 
the patch later this evening.

Regards,

Adolf
> - Tor
>
> In C182, we have a linux-firmware update, which already takes quite some breathing
> room in terms of file size. Unless something urgent comes up, it might be sensible
> to close this update sooner rather than later, so it can go into testing once
> Core Update 181 is released.
>
> Thoughts/comments?
>
> Thanks, and best regards,
> Peter Müller
>
>> Michael,
>>
>> I am back from my holiday trip visiting my family and friends in the UK.
>>
>> I will be working again on the OpenVPN package but that won't be ready for CU182.
>>
>> I am currently working through about 20 package updates which should get submitted over the next couple of days.
>>
>> I have some minor bug fixes that may get submitted in time for CU182.
>>
>> Overall, for CU182, there is nothing critical that I am working on beyond normal package updates, so you can decide form the patches I submit what to use and what to leave for a following CU.
>>
>>
>> Regards,
>>
>> Adolf.
>>
>>
>> On 07/11/2023 19:22, Peter Müller wrote:
>>> Hello Michael,
>>> hello *,
>>>
>>>> Hello everyone,
>>>>
>>>> Since this month’s video conference has been canceled, here is a couple of updates from my side:
>>>>
>>>> * Core Update 181 has been branched yesterday. I have this running in my office for a little while and it seems to be a solid update. It also has a lot of security fixes, so please give it a good test that we can hopefully release this in two weeks.
>>> indeed, Core Update 181 seems to work fine without any hiccups whatsoever. :-)
>>>
>>>> * For the following update(s): what do we have in the pipeline? Just to coordinate that we don’t have too much in one update :)
>>> Unless we have more pressing things on our agenda, I remember Adolf saying
>>> that there are still a couple of packages, particularly libraries, which he
>>> did not had the resources to work through. At some point, it might be sensible
>>> to have something like a distributed mini-hackathon to ensure that everything
>>> we include is at least roughly up to date, and if it's just by slicing the
>>> package list and distribute the shares. :-)
>>>
>>> At some point, I had the idea to keep an eye on various security advisories
>>> published by other distributions to identify non-prolific packages with
>>> important updates that might otherwise have flown under our radar, but this
>>> approach never worked well...
>>>
>>> Aside from updating, I recall Stefan working on porting firewall groups to
>>> ipset a while ago. Perhaps this is something we can then focus on to push
>>> out of the door next?
>>>
>>> Just my two cents. I currently do not have anything major on my docket list
>>> for IPFire 2.x. :-)
>>>
>>> All the best,
>>> Peter Müller

-- 
Sent from my laptop

Re: The Upcoming Core Update(s)

[Arne Fitzenreiter]

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

Am 2023-11-05 14:15, schrieb Michael Tremer:
> Hello everyone,
> 
> Since this month’s video conference has been canceled, here is a couple 
> of updates from my side:
> 
> * Core Update 181 has been branched yesterday. I have this running in 
> my office for a little while and it seems to be a solid update. It also 
> has a lot of security fixes, so please give it a good test that we can 
> hopefully release this in two weeks.
> 
> * For the following update(s): what do we have in the pipeline? Just to 
> coordinate that we don’t have too much in one update :)
> 
> Best,
> -Michael

I have grub-2.12-rc1 and i build a kernel update to 6.6.x which looks 
good. I plan for core183...
We should consider to change the IPFire version number because if you 
update from older versions it load 1.5GB at once before install it.

Arne

Re: The Upcoming Core Update(s)

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

Hello Arne,

> On 23 Nov 2023, at 08:22, Arne Fitzenreiter <arne_f(a)ipfire.org> wrote:
> 
> Am 2023-11-05 14:15, schrieb Michael Tremer:
>> Hello everyone,
>> Since this month’s video conference has been canceled, here is a couple of updates from my side:
>> * Core Update 181 has been branched yesterday. I have this running in my office for a little while and it seems to be a solid update. It also has a lot of security fixes, so please give it a good test that we can hopefully release this in two weeks.
>> * For the following update(s): what do we have in the pipeline? Just to coordinate that we don’t have too much in one update :)
>> Best,
>> -Michael
> 
> I have grub-2.12-rc1 and i build a kernel update to 6.6.x which looks good. I plan for core183...
> We should consider to change the IPFire version number because if you update from older versions it load 1.5GB at once before install it.

Yes, I am happy to do this. It is kind of overdue and in this step we should consider taking all legacy versions from the server.

> Arne

Re: The Upcoming Core Update(s)

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 3010 bytes --]

Hello Arne, hello Michael,

> Hello Arne,
> 
>> On 23 Nov 2023, at 08:22, Arne Fitzenreiter <arne_f(a)ipfire.org> wrote:
>>
>> Am 2023-11-05 14:15, schrieb Michael Tremer:
>>> Hello everyone,
>>> Since this month’s video conference has been canceled, here is a couple of updates from my side:
>>> * Core Update 181 has been branched yesterday. I have this running in my office for a little while and it seems to be a solid update. It also has a lot of security fixes, so please give it a good test that we can hopefully release this in two weeks.
>>> * For the following update(s): what do we have in the pipeline? Just to coordinate that we don’t have too much in one update :)
>>> Best,
>>> -Michael
>>
>> I have grub-2.12-rc1 and i build a kernel update to 6.6.x which looks good. I plan for core183...
>> We should consider to change the IPFire version number because if you update from older versions it load 1.5GB at once before install it.
> 
> Yes, I am happy to do this. It is kind of overdue and in this step we should consider taking all legacy versions from the server.

I agree. Is there anything beyond the ipfire-2.x Git repository that
needs to be done for this? If so, information on that would be appreciated,
so I can take care of this for Core Update 183.

@Arne, on the note of a kernel update: kconfig-hardened flags a couple of
architecture-/hardware-dependend kernel configure knobs in the 64-bit ARM
configuration that could be set to more secure values. Could you have a
look at the following ones, and decide if we can enable them?

> $ ./kernel-hardening-checker -c ipfire-2.x/config/kernel/kernel.config.aarch64-ipfire -m show_fail
> [+] Special report mode: show_fail
> [+] Kconfig file to check: ipfire-2.x/config/kernel/kernel.config.aarch64-ipfire
> [+] Detected microarchitecture: ARM64
> [+] Detected kernel version: 6.1
> [+] Detected compiler: GCC 130200
> =========================================================================================================================
>               option name               | type  |desired val | decision |      reason      | check result
> =========================================================================================================================
> <snip>
> CONFIG_ARM64_BTI_KERNEL                 |kconfig|     y      |defconfig | self_protection  | FAIL: is not found
> <snip>
> CONFIG_SHADOW_CALL_STACK                |kconfig|     y      |   kspp   | self_protection  | FAIL: "is not set"
> CONFIG_KASAN_HW_TAGS                    |kconfig|     y      |   kspp   | self_protection  | FAIL: is not found

To the best of my understanding, CONFIG_ARM64_BTI_KERNEL would enable
indirect branch tracking for the kernel space (enabled by default on
x86_64), and CONFIG_SHADOW_CALL_STACK and CONFIG_KASAN_HW_TAGS make
use of some hardware feature that is only available on 64-bit ARM.

Thank you in advance for having a look, and best regards,
Peter Müller

Re: The Upcoming Core Update(s)

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3550 bytes --]

Hello Peter,

> On 24 Nov 2023, at 13:31, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello Arne, hello Michael,
> 
>> Hello Arne,
>> 
>>> On 23 Nov 2023, at 08:22, Arne Fitzenreiter <arne_f(a)ipfire.org> wrote:
>>> 
>>> Am 2023-11-05 14:15, schrieb Michael Tremer:
>>>> Hello everyone,
>>>> Since this month’s video conference has been canceled, here is a couple of updates from my side:
>>>> * Core Update 181 has been branched yesterday. I have this running in my office for a little while and it seems to be a solid update. It also has a lot of security fixes, so please give it a good test that we can hopefully release this in two weeks.
>>>> * For the following update(s): what do we have in the pipeline? Just to coordinate that we don’t have too much in one update :)
>>>> Best,
>>>> -Michael
>>> 
>>> I have grub-2.12-rc1 and i build a kernel update to 6.6.x which looks good. I plan for core183...
>>> We should consider to change the IPFire version number because if you update from older versions it load 1.5GB at once before install it.
>> 
>> Yes, I am happy to do this. It is kind of overdue and in this step we should consider taking all legacy versions from the server.
> 
> I agree. Is there anything beyond the ipfire-2.x Git repository that
> needs to be done for this? If so, information on that would be appreciated,
> so I can take care of this for Core Update 183.
> 
> @Arne, on the note of a kernel update: kconfig-hardened flags a couple of
> architecture-/hardware-dependend kernel configure knobs in the 64-bit ARM
> configuration that could be set to more secure values. Could you have a
> look at the following ones, and decide if we can enable them?
> 
>> $ ./kernel-hardening-checker -c ipfire-2.x/config/kernel/kernel.config.aarch64-ipfire -m show_fail
>> [+] Special report mode: show_fail
>> [+] Kconfig file to check: ipfire-2.x/config/kernel/kernel.config.aarch64-ipfire
>> [+] Detected microarchitecture: ARM64
>> [+] Detected kernel version: 6.1
>> [+] Detected compiler: GCC 130200
>> =========================================================================================================================
>>              option name               | type  |desired val | decision |      reason      | check result
>> =========================================================================================================================
>> <snip>
>> CONFIG_ARM64_BTI_KERNEL                 |kconfig|     y      |defconfig | self_protection  | FAIL: is not found
>> <snip>
>> CONFIG_SHADOW_CALL_STACK                |kconfig|     y      |   kspp   | self_protection  | FAIL: "is not set"
>> CONFIG_KASAN_HW_TAGS                    |kconfig|     y      |   kspp   | self_protection  | FAIL: is not found
> 
> To the best of my understanding, CONFIG_ARM64_BTI_KERNEL would enable
> indirect branch tracking for the kernel space (enabled by default on
> x86_64), and CONFIG_SHADOW_CALL_STACK and CONFIG_KASAN_HW_TAGS make
> use of some hardware feature that is only available on 64-bit ARM.

I would like to highlight that shadow call stacks only work when they are actually compiled into the binaries as well. That means, that we will have to re-ship the entire distribution to make this feature actually work. It is not enough to just enable this in the kernel.

The same goes for branch protection.

Are you going to have a look at that?

-Michael

> Thank you in advance for having a look, and best regards,
> Peter Müller