Suricata

Rust 2018 (version 1.31.0) will be available 12/6

Danny Browning wrote:

One of the most significant changes for 2018 is changes to how crates, modules, and macros are found. Although much easier to use, this will produce a bit of churn in the Suricata rust code. Commit representing the churn involved: https://github.com/dbcfd/suricata/commit/33694e63dbbfc221ffda2882727b4fe431d9375e

I wonder if any of these changes can be made while also support Rust 1.24.1, the oldest we currently should still support?

I'm hoping that minimum version will go higher with the release of 2018 edition. But after making the 2018 edition changes, I will attempt with older compiler versions (up to 1.24.1) and see at what version it breaks.

Rust 1.30.0 is the first rust version that supports the edition keyword.

Rust 1.31.0 is the first rust version that edition is stable in.

When using `cargo fix --edition` the first rustc that will work is 1.30.0. If we want to enable edition features, users needs 1.31.0.

PR indiating required changes: https://github.com/OISF/suricata/pull/3604

With Debian 10s release Rust 2018 is available on all major distros. We do need to decide how long Debian 9 remains important. We know that no 5.0 will be made available for it through its own channels, so the question is if/when we think its reasonable to either push ppl to 10 or to tell them to install Rust from other channels like rustup.

Victor Julien wrote:

With Debian 10s release Rust 2018 is available on all major distros. We do need to decide how long Debian 9 remains important. We know that no 5.0 will be made available for it through its own channels, so the question is if/when we think its reasonable to either push ppl to 10 or to tell them to install Rust from other channels like rustup.

If it will never be made available through proper Debian channels, I'm of the opinion we don't have to worry about it.

The current rust version looks to be a blocker for https://github.com/OISF/suricata/pull/3971 since the toml crate uses the edition keyword.

Danny Browning wrote:

The current rust version looks to be a blocker for https://github.com/OISF/suricata/pull/3971 since the toml crate uses the edition keyword.

It might be OK to require newer versions to build from git, where cbindgen is required, and make a dist. But then could 1.24 still build it assuming the generated headers were included already?

Keeping a note: Got to remove the "ellipsis_inclusive_range_pattern" mentioned in https://redmine.openinfosecfoundation.org/issues/3072 when we switch to the 2018 edition.
Done.

It looks like all the major OS' we care about either updated Rust to a 2018 capable version, or released a new OS version that contains a 2018 capable version. Other than CentOS6 which doesn't support Rust at all through their packaging, only OpenBSD 6.4 and Debian 9 would have to switch from their own packaged Rust to rustup. Both have a newer version out that is new enough (Debian 10 and OpenBSD 6.5 respectively).

So I guess for Suricata 5.0 it is time to bump the minimal Rust version. Probably to 1.33 as that is the current version on FreeBSD 12 it seems.

Update: FreeBSD 12 is on 1.35, so we could go for 1.34 as the minimum.

OpenBSD 6.5 has 1.33, so I think we should consider taking 1.33 as the minimum.

As a side note, I have had trouble generally building 2018 code with rustc 1.31.1, including some of the dependencies in PR 4131 https://github.com/OISF/suricata/pull/4131. rustc 1.33 was mentioned as a candidate minimum, which is comfortably above that.