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
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)?
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.
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!?
Best, Matthias
Hi,
On 19 Feb 2021, at 09:02, Matthias Fischer matthias.fischer@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.
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
On 19 Feb 2021, at 10:59, Michael Tremer michael.tremer@ipfire.org wrote:
Hi,
On 19 Feb 2021, at 09:02, Matthias Fischer matthias.fischer@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
-
Matthias Fischer -
Michael Tremer