nginx: update to 1.30.2

[orangepizza]

📦 Package Details

Maintainer: @Ansuel, @heil cc: @ptpt52
_{(You can find this by checking the history of the package Makefile.)}

Description:
Large version jump from 1.26.3 to 1.30.2 (upstream stable). changelogs at https://nginx.org/en/CHANGES-1.30 and 1.28, include many security cve fixs

---

🧪 Run Testing Details

• OpenWrt Version:
  snapshot
• OpenWrt Target/Subtarget:
  x86-64
• OpenWrt Device:
  kvm vm

---

✅ Formalities

• [ x] I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

If your PR contains a patch:

• It can be applied using git am
• It has been refreshed to avoid offsets, fuzzes, etc., using

  make package/<your-package>/refresh V=s

• It is structured in a way that it is potentially upstreamable
  _{(e.g., subject line, commit description, etc.)
  We must try to upstream patches to reduce maintenance burden.}

[laipeng668]

The patches 103-sys_nerr.patch and 300-fix-deprecated-openssl-3_0.patch seem to be no longer needed.
Additionally, the other patches need to be refreshed.

[orangepizza]

@laipeng668 both patches looks still merge cleanly: so I have no idea if it's really not needed anymore

[laipeng668]

I also upgraded Nginx to 1.31.1 myself.
Based on the modification suggestions from a GPT-5.5 review using OpenCode + Oh My OpenCode, I’ve deleted them for now, and everything is running well so far with no issues found.
Everyone is welcome to discuss.

[Neustradamus]

It will close:

• nginx: Vulnerable to CVE-2026-42945 #29480

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[orangepizza]

@hnyman could you merge this? it have security fixes and looks like it wasn't touched for a while

[hnyman]

@Ansuel
Any objections?

[BKPepe]

Uhh.. are we sure that this is something that it should be merged? 🤔

I don't mean to be rude, but we have tests here to verify that the application at least runs within CI/CD. Instead, we're just accepting a workaround where we won't test it at all because either upstream or downstream versioning is broken, and we're throwing away the entire run testing for luajit2. That's nonsense, right?

Here is the output from CI/CD:

luajit2: [skip] Version check (/usr/bin/luajit2)

This essentially tells me that we aren't going to test luajit2 and we can completely forget about any run testing. This is not right at all, especially considering luajit2 actually does report its version.

[orangepizza]

most test-version.sh overrides are in that structure(krb5/perl/etc...), so I assumed it's standard for version check override?

[BKPepe]

It's not a standard for version checks. We shouldn't blindly copy overrides without checking if they actually make sense for the package in question.

Packages like krb5 have overrides because they don't report their version. But if an application does report its version, there is no reason to skip the test. If perl5 is bypassing it, then that test is probably wrong too. We shouldn't just give up on testing when the binary provides the information we need.

For a good reference on how CI/CD runtime testing should actually be done, please take a look at the tests provided by @commodo.

[BKPepe]

This will be most likely addressed in #29669

[BKPepe]

This is the same case as above and shouldn't be merged yet. I don't think this is the right direction, and we shouldn't accept the contribution in this form. I want to emphasize this because it's an important detail to get right.

The whole point of having CI/CD tests is to verify that things actually work. Throwing a test away instead of taking a little time to fix it correctly defeats the purpose of the pipeline.

I looked into this, and it took me just a few minutes to find a working approach by using CI/CD.

I am using OpenWrt 24.10 (yeah, still):

root@turris:~# xsltproc -v -V
Using libxml 21405, libxslt 10142 and libexslt 823
xsltproc was compiled against libxml 21405, libxslt 10142 and libexslt 823
libxslt 10142 was compiled against libxml 21405
libexslt 823 was compiled against libxml 21405
root@turris:~# opkg list-installed | grep xsltproc
xsltproc - 1.1.42-r1

Gemini 3.5 Flash (High) says:

When running xsltproc -V, it reports:

libxml 21405
libxslt 10142
libexslt 823
These numbers are encoded versions using the internal representation format: $$\text{Version Integer} = \text{Major} \times 10000 + \text{Minor} \times 100 + \text{Patch}$$

Specifically:

libxml 21405 corresponds to version 2.14.5 ($2 \times 10000 + 14 \times 100 + 5 = 21405$).
libxslt 10142 corresponds to version 1.1.42 ($1 \times 10000 + 1 \times 100 + 42 = 10142$).
libexslt 823 corresponds to version 0.8.23 ($0 \times 10000 + 8 \times 100 + 23 = 823$).
This is the standard version encoding of the libxml2/libxslt libraries.

Instead of dropping the test, we can just parse the version properly. Here is a working implementation for test-version.sh that handles this encoding:

#!/bin/sh

# shellcheck shell=busybox

pkg="${1:-$PKG_NAME}"
ver="${2:-$PKG_VERSION}"

case "$pkg" in
libxslt|libexslt)
	exit 0
	;;

xsltproc)
	# libxslt / libxml encode version as major * 10000 + minor * 100 + patch.
	# For example, libxslt version 1.1.42 is represented as 10142.
	IFS=. read -r major minor patch <<EOF
$ver
EOF
	major=$(echo "${major:-0}" | tr -cd '0-9')
	minor=$(echo "${minor:-0}" | tr -cd '0-9')
	patch=$(echo "${patch:-0}" | tr -cd '0-9')
	ver_encoded=$((major * 10000 + minor * 100 + patch))

	xsltproc -V 2>&1 | grep -q "libxslt $ver_encoded"
	;;

*)
	echo "test-version.sh: unhandled sub-package '$pkg'" >&2
	exit 1
	;;
esac

Of course, it needs to be checked, if it is alright and if it works.