Re: Pending patches for upcoming Core Update(s)

[Michael Tremer <michael.tremer@ipfire.org>]

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



> On 19 Feb 2021, at 10:59, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
> 
> Hi,
> 
>> On 19 Feb 2021, at 09:02, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>> 
>> Hi,
>> 
>> FYI and to avoid redundancies, I got one of the 64bit-'Devels' working on:
>> 
>> tar => 1.34
>> bind => 9.11.28
>> nettle => 3.7.1
>> libgcrypt => 1.9.2
>> krb5 => 1.19.1
> 
> These all sound fine :)
> 
> It looks like Bind had another security issue, and Python might have one that affects us, too.
> 
>> And, because it "just came my way":
>> rust => 1.50 (under x86-64, this is huge - about ~1.2GB sources)
>> 
>> Opinions for this update(s)?
> 
> Good question. I am currently working on a riscv64 port for IPFire 2, and Rust isn’t available at all for this architecture.
> 
> Rust is indeed becoming such a pain to package and I do not expect any solutions to that in the near future. I assume that 1.2GB is the extracted size because the download is about 140 MB. 

Stupid me. I looked at the source tarball, but rust cannot be built from scratch that easily.

>> I'm just not so sure with the latter - do we want this?
>> As I see it, 'suricata' must then also be at least shipped or even updated.
> 
> Yes, and since this is security relevant, I would say we should update rustc regardless of the size of the source tarball.
> 
>> Besides, 'suricata 6.0.1' is still running here with the 'usleep
>> (5000)'-patch. So far, without - seen! - problems. Any news on this? If
>> wanted, I could provide a patchset so "someone" else could test this!?
> 
> I don’t doubt that it will run. The question is how does it behave under high load or other more challenging constraints? I must say that I am very disappointed that the suricata devs do not really care much about a problem many people ran into.
> 
>> Best,
>> Matthias
> 
> -Michael