There's a lot of really old software out there. Some of it has simply been abandoned; others have been replaced by new versions. But old software never really goes away, and we end up maintaining it.

This is especially tricky when old software depends on other old software, and we have to support the entire dependency tree.

There's always python2 and python 3. Some old software may never be fixed; some current software has consciously decided to stick to python 2. Distributions will be shipping python 2 for a long time yet.

Then there's PCRE and PCRE2. Some things have been updated; others haven't. Generally for this I'll keep updating, and eventually upstream might get around to migrating. But again I'll have to ship both for a while.

And then there's gtk2 and gtk3. (I find it ironic that the gimp itself is still using gtk2.) There's no end in sight of the need to ship both.

Some libraries have been deprecated entirely. the old libXp (the X printing library) is long gone. There were a couple of things built against it in Tribblix. I've just rebuilt chimera (a really old Xaw web browser if your memory doesn't go that far back) which was one consumer and now isn't; the other one was Motif (there's a convenient build flag --disable-printing to disable libXp support, which entertainingly breaks the build someplace else which I ended up having to fix).

Another example, libpng has gone through several different revisions. Each slightly incompatible, and you have to be sure to run with the same version you built against. At least you can ship all the different versions, as they have the version in the names. Mind you, linking against 2 different versions of libpng at the same time (for example, if a dependency pulls in a different version of libpng) is a bad thing, so I did have to rebuild a number of applications to avoid that. I ship the old libpng versions in a separate compat package, I think chimera was the only consumer, but I updated that to use a more current libpng.

A slightly different problem is the use of newer toolchains. Compilers are getting stricter over time, so old unmaintained software needs patches to even compile.

Don't even get me started on openssl.

I spent a little time yesterday updating MATE on Tribblix, to version 1.26.

This was supposed to be part of the "next" release, but we had to make an out of sequence release for an illumos security issue, so everything gets pushed back a bit.

Updating MATE is actually fairly easy, though. The components in MATE are largely decoupled, so can be updated independently of each other. (And there isn't really a MATE framework everything has to subscribe to, so the applications can be used outside MATE without any issues.)

There's a bit of tidying up and polish that helps. For example, I delete static archives and the harmful libtool archive files. Not only does this save space, it helps maintainability down the line.

Builds have a habit of picking up dependencies from the build system. Sometimes you can control this with judicious --enable-foo or --disable-foo flags, sometime you just have to make sure that the package you don't want pulled in isn't installed. The reverse is true - if you want a feature to be enabled, you have to make sure the dependencies are installed first and the feature will usually get enabled automatically.

That's not always true. For example, you have to explicitly tell it you have OSS for audio, it doesn't work this out on its own.

I took the opportunity to make everything 64-bit. Ultimately I want to get to 64-bit only. This involves a bit of working backwards - you have to make all consumers of a library 64-bit only first.

A couple of components are held downrev. The calculator now wants to pull in mpc and mpfr, which I don't package. (They're used by gcc, but I drop a copy of mpc and mpfr into the build for gcc to find rather than packaging them separately the way that most of the other illumos distributions do.) And pluma wants gtksourceview-4 which I don't have yet. This is related to the lack of tight coupling I mentioned earlier - there really isn't any problem having the different pieces that make up MATE at different revisions.)

You stumble across bugs along the way. For example, mate-control-center actually needs GLib 2.66 or later, which I don't have yet (there's another whole set of issues behind that), but it doesn't actually check for the right version. Fortunately the requirement is fairly localized and easy to patch out.

That done, on to another set of updates...

The illumos security team have today published a security advisory concerning CVE-2023-31284, a kernel stack overflow that can be performed by an unprivileged user, either in the global zone or in any non-global zone. A copy of their advisory is below.

ACTION: If you are using any of the supported OmniOS versions, or the recently retired r42, run pkg update to upgrade to a version that includes the fix. Note, that a reboot is required. If you have already upgraded to r46, then you are all set as it already includes the fix.

The following OmniOS versions include the fix:

• r151046
• r151044y
• r151042az
• r151038cz

If you are running an earlier version, upgrade to a supported version (in stages if necessary) following the upgrade guide.

illumos Security Team advisory

We are reaching out today to inform you about CVE-2023-31284. We have pushed a commit to address this, which you can find at https://github.com/illumos/illumos-gate/commit/676abcb77c26296424298b37b9. While we don’t currently know of anyone exploiting this in the wild, this is a kernel stack overflow that can be performed by an unprivileged user, either in the global zone, or any non-global zone.

The following details provide information about this particular issue:

IMPACT: An unprivileged user in any zone can cause a kernel stack buffer overflow. While stack canaries can capture this and lead to a denial of service, it is possible for a skilled attacker to leverage this for local privilege escalation or execution of arbitrary code (e.g. if combined with another bug such as an information leak).

ACTION: Please be on the look out for patches from your distribution and be ready to update.

MITIGATIONS: Running a kernel built with -fstack-protector (the illumos default) can help mitigate this and turn these issues into a denial of service, but that is not a guarantee. We believe that unprivileged processes which have called chroot(2) with a new root that does not contain the sdev (/dev) filesystem most likely cannot trigger the bug, but an exhaustive analysis is still required.

Please reach out to us if you have any questions, whether on the mailing list, IRC, or otherwise, and we’ll try to help as we can.

We’d like to thank Alex Wilson and the students at the University of Queensland for reporting this issue to us, and to Dan McDonald for his work in fixing it.

The illumos Security Team

---

Any problems or questions, please get in touch.

OmniOSce v11 r151046 is out!

On the 1st of May 2023, the OmniOSce Association has released a new stable version of OmniOS - The Open Source Enterprise Server OS. The release comes with many tool updates, brand-new features and additional hardware support. For details see the release notes.

Note, that r151042 is now end-of-life. You should upgrade to r151046 to stay on a supported track. r46 is an LTS release with support until May 2026.

For anyone who tracks LTS releases, the previous LTS - r151038 - now enters its last year. You should plan to upgrade to r151046 during the next twelve months for continued support.

OmniOS is fully Open Source and free. Nevertheless, it takes a lot of time and money to keep maintaining a full-blown operating system distribution. Our statistics show that there are almost 2’000 active installations of OmniOS while fewer than 20 people send regular contributions. If your organization uses OmniOS based servers, please consider becoming a regular patron or taking out a support contract.

---

Any problems or questions, please get in touch.

The final lesson my father taught me.