This does compile-time type and argument checking using a clang-plugin.
It was run as part of buildbot.

This covers unitd, src/test and the php, perl, python, ruby, wasm, java
and nodejs language modules/support.

It doesn't cover Go as that doesn't build anything with clang (uses
cgo) or wasm-wasi-component as that uses rustc.

Link: <https://github.com/nginx/clang-ast/tree/unit>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

Under Ubuntu 24.04 the pytest for
test/test_php_isolation.py::test_php_isolation_rootfs fails due to Unit
aborting (SIGABRT) in the PHP language module due to FORIFY_SOURCE
hardening detecting a buffer overflow

  2024/10/16 16:46:54 [info] 11661#11661 "phpinfo" application started
  *** buffer overflow detected ***: terminated
  2024/10/16 16:46:54 [alert] 11660#11660 app process 11661 exited on signal 6

After spending an extraordinary amount of time faffing around with
Ubuntu and pytests (they don't make for a pleasant combination) I was
able to reproduce it.

The crash was occurring here

  #4  0x00007ebe818288ff in __GI_abort () at ./stdlib/abort.c:79
  #5  0x00007ebe818297b6 in __libc_message_impl (
      fmt=fmt@entry=0x7ebe819ce765 "*** %s ***: terminated\n")
      at ../sysdeps/posix/libc_fatal.c:132
  #6  0x00007ebe81936c19 in __GI___fortify_fail (
      msg=msg@entry=0x7ebe819ce74c "buffer overflow detected")
      at ./debug/fortify_fail.c:24
  #7  0x00007ebe819365d4 in __GI___chk_fail () at ./debug/chk_fail.c:28
  #8  0x00007ebe8134a055 in mempcpy (__len=10, __src=0x7ebe8160ade8,
      __dest=0x571ba9bd0930)
      at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:45
  #9  fake_data_segment (info=0x0, sysdb=0x571ba9bcf080)
      at /usr/src/php8.1-8.1.30-1+ubuntu24.04.1+deb.sury.org+1/ext/date/lib/parse_tz.c:921
  #10 timelib_builtin_db ()
      at /usr/src/php8.1-8.1.30-1+ubuntu24.04.1+deb.sury.org+1/ext/date/lib/parse_tz.c:1084
  #11 0x00007ebe812e0885 in zm_info_date (zend_module=0x571ba9a14420)

[Well as best as I can tell, as this is from the php 8.1 packages from
<https://github.com/oerdnj/deb.sury.org>, I don't know where the
packages (I'm assuming it's packages) shivammathur/setup-php@v2
installs come from.]

So we get killed in fake_data_segment(), the thing is, that function (as
well as timelib_builtin_db()) doesn't exist in upstream PHP.

It turns out these come from a patch that is applied by distributions to
make PHP use the system installed timezone database rather than the one
built into PHP.

I was unable to reproduce this with vanilla PHP 8.1.

It can be triggered on affected builds with the following config

  {
      "listeners": {
          "[::1]:8080": {
              "pass": "applications/php"
          }
      },

      "applications": {
          "php": {
              "type": "php",
              "root": "/app/php",

      	      "isolation": {
  	          "rootfs": "/tmp/unit-root",

                  "namespaces": {
  	              "mount": true,
  		      "credential": true,
  		      "pid": true
                  }
  	      }
          }
      }
  }

The crux of the issue seems to come down to in this case PHP can't open
the tz database as it's not contained in the new mount namespace.

  190437 openat(AT_FDCWD, "/usr/share/zoneinfo/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
  190437 openat(AT_FDCWD, "/usr/share/zoneinfo/zone.tab", O_RDONLY) = -1 ENOENT (No such file or directory)
  190437 writev(2, [{iov_base="*** ", iov_len=4}, {iov_base="buffer overflow detected", iov_len=24}, {iov_base=" ***: terminated\n", iov_len=17}], 3) = 45
  ...
  190437 --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=2, si_uid=65534} ---
  190437 +++ killed by SIGABRT +++

Specifically the issue is with the following code in the patch
(certainly an earlier version of the patch, this is from a Debian patch
<https://sources.debian.org/src/php8.2/8.2.20-1~deb12u1/debian/patches/0007-Add-support-for-use-of-the-system-timezone-database.patch/>)

  +        data = malloc(3 * sysdb->index_size + 7);
  +
  +        p = mempcpy(data, FAKE_HEADER, sizeof(FAKE_HEADER) - 1);

If the zone file hasn't been found then sysdb->index_size is 0. So we
malloc(3) a total of 7 bytes.

However, sizeof(FAKE_HEADER) - 1 is 10. (Hence the __len=10 in the
mempcpy(3) in the above backtrace).

Of course 10 doesn't fit into 7 and the FORTIFY_SOURCE hardening kicks
in and SIGABRTs the process.

Now, it's worth noting that this issue doesn't occur with PHP 8.2 and
8.3.

As can been seen from the Fedora patch for this
<https://src.fedoraproject.org/rpms/php/blob/rawhide/f/php-8.4.0-systzdata-v24.patch>

They actually have a fix incorporated

  r23: fix possible buffer overflow

So the above patch now does

  +        data = malloc(3 * sysdb->index_size + sizeof(FAKE_HEADER) - 1);
  +
  +        p = mempcpy(data, FAKE_HEADER, sizeof(FAKE_HEADER) - 1);

So you will always get at least the required 10 bytes allocated.

I assume the PHP 8.2 & 8.3 packages either no longer use this patch or
have the fixed version. I don't know... I haven't found the sources...

Anyway the above was more about satisfying myself that the problem
wasn't with Unit.

PHP 8.1 is now in security maintenance mode and people are actively
encouraged to upgrade to 8.2/8.3

So lets just remove 8.1 from our testing...

[It's also worth noting that after all this, the ubuntu-latest runners
seemed to have switched back from 24.04 to 22.04. However lets stick
with this and the other ci fixes as who knows when it'll go back to
24.04 (or some other version) again...]

Link: <https://www.php.net/supported-versions.php>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

With Ubuntu 24.04 installing it via pip gave this error

  error: externally-managed-environment

  × This environment is externally managed
  ╰─> To install Python packages system-wide, try apt install
      python3-xyz, where xyz is the package you are trying to
      install.

      If you wish to install a non-Debian-packaged Python package,
      create a virtual environment using python3 -m venv path/to/venv.
      Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
      sure you have python3-full installed.

      If you wish to install a non-Debian packaged Python application,
      it may be easiest to use pipx install xyz, which will manage a
      virtual environment for you. Make sure you have pipx installed.

      See /usr/share/doc/python3.12/README.venv for more information.

Installing it via the package manager is the better option anyway...

Under Ubuntu 22.04 it only installs a /usr/bin/pytest-3 binary, rather
than installing a /usr/bin/pytest binary and symlink for pytest-3, so
use pytest-3 as the command.

Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

With Ubuntu 24.04 this service is no longer enabled/installed and so
this bit would fail.

This commit makes it handle both cases (installed/not-installed).

Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

This will catch changes to the likes of wasmtime and njs.

Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

With commit 9998918db ("Packages: bump wasmtime to 24.0.0 and
wasi-sysroot to 24.0.") the paths to the wasmtime C API include and lib
directories changed which broke the wasm ci tests.

Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

- Adds `unitctl/` prefix to tags generated by manual workflow runs.
  Previously, only release titles (but not tags) were prefixed.

- Omits superfluous `name` field; falls back to `tag` when absent.

- Removes unnecessary conditional from `prelease` field.

This results in the following tagging / releasing behavior:

1. Running manually creates a pre-release and tags it `unitctl/VERSION`
2. Pushing a tag formatted like `x.y.z` creates a normal release

Refines: 3501a50ffb93756e145295021ff9313ac77f1ba9

We now have tests for this module via commit cad6aed52 ("Tests: initial
"wasm-wasi-component" test").

We need to install cargo-component for this test target.

Also the only way I found I could get this test to run was by running as
non-root. The issue I was seeing was that despite cargo being installed
into /home/runner/.cargo/bin *and* that being in the path, it kept
claiming it couldn't find cargo. E.g.

  $ sudo -E echo $PATH

Showed /home/runner/.cargo/bin in there.

  $ sudo -E /home/runner/.cargo/bin/cargo -V

Worked.

  $ sudo -E cargo -V

cargo command not found.

(Also other oddities, despite claiming to be using bash, it couldn't
find shell builtins like 'hash' and 'export', perhaps some Ubuntu
weirdness...)

However, no problem, there is *no* need for it run as root anyway so
result!

Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

unitctl makes use of 'docs/unit-openapi.yaml' so be sure to run these
checks if that file changes.

Fixes: 6d0880c99 ("Add unitctl build and release CI")
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

Bumps <https://github.com/github/codeql-action> from 2 to 3.

Link: Release notes <https://github.com/github/codeql-action/releases>
Link: Changelog <https://github.com/github/codeql-action/blob/main/CHANGELOG.md>
Link: Commits <https://github.com/github/codeql-action/compare/v2...v3>
Signed-off-by: dependabot[bot] <support@github.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>