Update ossfuzz base image to newer Ubuntu (22.04 or 24.04) ?

[rouault]

The GDAL project builds against the latest Poppler git version, but they have just increased their baseline dependencies (for boost, libtiff, freetype) to the ones provided by Ubuntu 22.04. So this requires also the GDAL ossfuzz build recipee to build those components (at least freetype which is the only one strictly required) from source, which complicates things. It could be worth considering updating to ossfuzz base image to a newer Ubuntu

[maflcko]

Related: #11420 (comment)

[maflcko]

If it is only freetype, then you can run as a final step after all other installations are done:

sed --in-place 's/focal/noble/g' /etc/apt/sources.list && apt update && apt install libfreetype-dev --reinstall --yes

However, that didn't work with boost, last time I checked.

[oliverchang]

Yes, this is something we've been wanting to do, but as OSS-Fuzz has grown to the size it has over the years, it's also become a lot harder to do in the way we typically do this (I.e. upgrade every single project ourselves).

One thing we're considering is to just pin all existing project images to the current Ubuntu 20.04, provide images based on newer Ubuntu, and let projects that do want to upgrade do the upgrade themselves.

[maxammann]

I know that this issue is kind of re-occurring since the release of Ubuntu 22. I was discussing this with a colleague and while the situation for the OSS-fuzz project is quite challenging (need to upgrade most/all projects to the new base images), it seems way more approachable for ClusterFuzzLite.

Especially for ClusterFuzzLite you typically fuzz projects that don't have a stable release cycle like e.g. OpenSSL. So it is quite a challenge to expect ClusterFuzzLite users to support Ubuntu 20. Most of the users are projects that don't quality for OSS-fuzz. And there is really no reason why CFL users shouldn't use a base image based off any Ubuntu version.

So our idea was to design a "channel" feature. As a CFL user you can define which channel/release of Ubuntu you want to target. Fundamentally this could also work with oss-fuzz in general but I don't have the full picture there.

EDIT: In case of Rust this seems like a problem which could become a real blocker. I found out that the upgrade from LLVM 17 to 18 in Rust is breaking the coverage generation.
So the current CFL rust container image is stuck to one specific Rust nightly version. And if more and more crates become incompatible with it, more and more workarounds need to be created (https://github.com/dalek-cryptography/curve25519-dalek currently is).

[maflcko]

EDIT: In case of Rust this seems like a problem which could become a real blocker. I found out that the upgrade from LLVM 17 to 18 in Rust is breaking the coverage generation.

This is unrelated to the Ubuntu version, as the compilers are self-compiled by oss-fuzz. Moving to a current rust nightly (or similarly, moving to a recent llvm in the coverage container that can understand the raw coverage profile generated from a current rust nightly) can be done as soon as most projects are un-pinned again. (If you want to help, they can be found via git grep '@sha256:' ./projects/)

[maxammann]

This is unrelated to the Ubuntu version, as the compilers are self-compiled by oss-fuzz. Moving to a current rust nightly can be done as soon as most projects are un-pinned again. (If you want to help, they can be found via git grep '@sha256:' ./projects/)

Sadly not exactly. From Rust 1.77 top 1.78 (as far as I remember) they switched from LLVM 17 to 18 which makes coverage generated incompatible with the LLVM version used in the coverage container image.

So you get an error like raw profile version mismatch: Profile uses raw profile format version = 9; expected version = 8 if you use the latest Rust nightly. Maybe I missed something, though

I agree though this is more related to the LLVM version and not the Ubuntu version.