sing-box: bump to 1.13.15 without Naive outbound support

[Ser9ei]

This patch updates sing-box from 1.12.22 to 1.13.15.

Upstream release information:
https://github.com/SagerNet/sing-box/releases/tag/v1.13.0
https://github.com/SagerNet/sing-box/releases/tag/v1.13.15

Scope note:

The upstream Naive outbound feature is intentionally not enabled in this update.
Naive outbound requires additional build system integration because it depends on
Chromium Network Stack (Cronet). Depending on target and build mode, it requires
either the Cronet runtime library or a Chromium-based toolchain.
Upstream documentation:
https://sing-box.sagernet.org/configuration/outbound/naive/#structure

Changes:

1. Add upstream linker flags and compatibility build tags

Add linker flags required by the sing-box upstream release build:

• -checklinkname=0

Documentation:
https://sing-box.sagernet.org/installation/build-from-source/#linker-flags

-checklinkname=0 is required by the sing-box 1.13.x build configuration due to its use of
low-level go:linkname functionality and the stricter linkname validation in newer Go toolchains.

Add upstream compatibility build tags required by sing-box 1.13.x:

• badlinkname
• tfogo_checklinkname0

These tags are part of the upstream sing-box release build configuration:
https://sing-box.sagernet.org/installation/build-from-source/#build-tags

2. Add optional CCM and OCM build options

Add new optional OpenWrt configuration options:

• CONFIG_SINGBOX_WITH_CCM
  Build with Claude Code Multiplexer service support
• CONFIG_SINGBOX_WITH_OCM
  Build with OpenAI Codex Multiplexer service support

Both options are disabled by default and are only enabled when explicitly
selected by the user.

The corresponding upstream build tags are:

• with_ccm
• with_ocm

Documentation: https://sing-box.sagernet.org/installation/build-from-source/#build-tags

📦 Package Details

Maintainer: @brvphoenix

🧪 Run Testing Details

• OpenWrt Version: 25.12.5
• OpenWrt Target/Subtarget: mediatek/filogic
• OpenWrt Device: Xiaomi Mi Router AX3000T

[openwrt-ai]

One functional issue in the new linker flags, flagged inline; the rest of the bump looks sound.

Verified against upstream: the with_ccm / with_ocm build tags exist and match the wording used in the new Kconfig prompts (include/ccm.go, release/DEFAULT_BUILD_TAGS, docs/installation/build-from-source.md), release/config/config.json is still present so the install recipe stays valid, and sing-box 1.13 needs Go >= 1.24 while the feed's GO_DEFAULT_VERSION is 1.26. PKG_RELEASE:=1 is correct for a version bump. All 10 package build jobs plus the formality checks are green on 95f3cce.

The only thing I would call blocking is the -X target name: as written the flag resolves to nothing, so the MPTCP default the commit message promises is not actually applied.

---

Generated by Claude Code

[openwrt-ai]

internal/godebug.defaultGODEBUG is not a real symbol, so this -X is silently dropped by the linker and MPTCP stays enabled — the stated goal of the flag is not achieved. The linker ignores -X for names it cannot resolve, which is why the build still passes CI.

The variable the Go toolchain actually reads for compile-time GODEBUG defaults is runtime.godebugDefault (var godebugDefault string in src/runtime/runtime.go, consumed by parsegodebug(godebugDefault, ...) in src/runtime/runtime1.go); there is no defaultGODEBUG anywhere under src/internal/godebug. Upstream's own release/LDFLAGS uses that name too:

-X runtime.godebugDefault=multipathtcp=0,tlssha1=1,tlsunsafeekm=1 -checklinkname=0

The suggestion below fixes the symbol name (and drops the stray second blank line). Note that upstream also carries tlssha1=1,tlsunsafeekm=1 in the same string — worth deciding whether OpenWrt wants to mirror the full upstream default or only multipathtcp=0 as the commit message describes.

Suggested change

	GO_PKG_LDFLAGS:=-checklinkname=0
	GO_PKG_LDFLAGS_X:= \
	$(GO_PKG)/constant.Version=$(PKG_VERSION) \
	internal/godebug.defaultGODEBUG=multipathtcp=0
	GO_PKG_LDFLAGS:=-checklinkname=0
	GO_PKG_LDFLAGS_X:= \
	$(GO_PKG)/constant.Version=$(PKG_VERSION) \
	runtime.godebugDefault=multipathtcp=0

---

Generated by Claude Code

[openwrt-ai]

nit (optional): the three option lists in this file are kept in strict alphabetical order by option name, and appending CCM/OCM at the end breaks that. SINGBOX_WITH_CCM belongs between SINGBOX_WITH_ACME and SINGBOX_WITH_CLASH_API, and SINGBOX_WITH_OCM between SINGBOX_WITH_GVISOR and SINGBOX_WITH_QUIC.

Same applies to the two other lists: CONFIG_SINGBOX_WITH_CCM / CONFIG_SINGBOX_WITH_OCM at lines 126-127 in PKG_CONFIG_DEPENDS, and the with_ccm / with_ocm entries at lines 147-148 in the full-variant GO_PKG_TAGS block. No suggestion block here since the fix moves lines across hunks.

---

Generated by Claude Code

[Ser9ei]

Commit has been updated based on the AI review comments.
@brvphoenix could you please review? Thanks!

upd: up to 1.13.15

[openwrt-ai]

Re-reviewed the changes since 95f3cce (1.13.14 → 1.13.15, -X symbol fix, alphabetical re-ordering of the three option lists).

Both findings from the previous round are addressed: the option lists are now in the same alphabetical order as the rest of the file, and the GODEBUG -X target is the real symbol — I confirmed empirically with go1.24.7 that internal/godebug.defaultGODEBUG is a no-op and runtime.godebugDefault takes effect. with_ccm / with_ocm still exist at v1.13.15 (include/ccm.go, include/ocm.go, release/DEFAULT_BUILD_TAGS) and the Kconfig prompts match the upstream doc wording; the tag v1.13.15 exists; PKG_RELEASE:=1 is right for a version bump; the commit message matches the diff.

One open question left, inline: the new godebug string is taken from the testing branch rather than from the v1.13.15 tag, which means this build enables tlssha1=1 / tlsunsafeekm=1 that upstream's own 1.13.15 binaries do not. Nothing here looks merge-blocking to me — it is a scope/intent call for the maintainer.

---

Generated by Claude Code

[openwrt-ai]

The symbol fix is confirmed working: built a test binary with go1.24.7 and panicnil=1, and only the -X runtime.godebugDefault= form changes behaviour — -X internal/godebug.defaultGODEBUG= is silently dropped, as that symbol does not exist (var godebugDefault string at src/runtime/runtime.go:136). So this line now does what the commit message promises.

Two things worth a decision before merge, neither of which blocks by itself:

1. The value comes from testing, not from the tag being packaged. release/LDFLAGS at the packaged tag is still -X internal/godebug.defaultGODEBUG=multipathtcp=0 -checklinkname=0 (v1.13.15); the three-setting string only appears on testing, which is post-1.13. Because upstream's 1.13.15 flag resolves to nothing, upstream's own 1.13.15 binaries apply no godebug default, while this build will apply three — including tlssha1=1 (re-enables SHA-1 signature algorithms in TLS handshakes) and tlsunsafeekm=1 (re-enables ExportKeyingMaterial on connections without EMS). Both are relaxations of the Go defaults. Is pulling the post-1.13 values into a 1.13.15 build intentional, or should this stay at multipathtcp=0 until the release that ships them?

2. This replaces the toolchain's GODEBUG default rather than adding to it. cmd/go already emits its own -X=runtime.godebugDefault=+root.Package.DefaultGODEBUG (gc.go:636) before the package's own ldflags, and the last -X for a symbol wins (verified locally). sing-box's go.mod declares go 1.24.7 while the feed builds with GO_DEFAULT_VERSION:=1.26, so the go1.24 compatibility defaults the 1.26 toolchain would otherwise bake in get dropped here. Upstream's testing build has the same property, so this is likely acceptable — flagging it only so it is a conscious choice, since the effect is wider than MPTCP.

---

Generated by Claude Code

[openwrt-ai]

nit (optional): leftover double blank line — every other separation in this file is a single blank line.

Suggested change

---

Generated by Claude Code

[Ser9ei]

Just an update after the latest review.
At the moment, the 1.13.x branch/release still contains the old internal/godebug.defaultGODEBUG form, while the testing branch has been switched to runtime.godebugDefault.
I've opened a small upstream issue asking whether this change (and the associated tlssha1=1,tlsunsafeekm=1 defaults) is planned to be backported to the 1.13.x release branch. That should help clarify which linker flags downstream packages should follow.
SagerNet/sing-box#4365

[Ser9ei]

@BKPepe, Could you please help to push commit?

[openwrt-ai]

Reviewed 1 new commit; no new issues found.

The only change since 46ab276 is the removal of runtime.godebugDefault=multipathtcp=0,tlssha1=1,tlsunsafeekm=1 from GO_PKG_LDFLAGS_X, which resolves the open question from the previous round: the string came from the testing branch, not from the v1.13.15 tag, so dropping it keeps this build's runtime defaults aligned with upstream's own 1.13.15 binaries rather than diverging from them. The commit message was updated in the same step — the -X runtime.godebugDefault=... bullet and the release/LDFLAGS reference are gone, so message and diff still agree. Thanks for filing SagerNet/sing-box#4365 to settle it upstream.

Everything else is unchanged from the previously reviewed revision: -checklinkname=0 in GO_PKG_LDFLAGS, the badlinkname / tfogo_checklinkname0 tags on both variants, the new SINGBOX_WITH_CCM / SINGBOX_WITH_OCM options in all three lists in alphabetical order, and PKG_RELEASE:=1 for the version bump. CI on 646dbd2 shows no failures (formality checks green, build matrix green or still running).

---

Generated by Claude Code

[Ser9ei]

@BKPepe