Script 'mail_helper' called by obssrc Hello community, here is the log from the commit of package openai-codex for openSUSE:Factory checked in at 2026-09-01 15:51:47 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/openai-codex (Old) and /work/SRC/openSUSE:Factory/.openai-codex.new.1265 (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "openai-codex" Tue Sep 1 15:51:47 2026 rev:6 rq:1375084 version:0.152.0 Changes: -------- --- /work/SRC/openSUSE:Factory/openai-codex/openai-codex.changes 2026-08-30 19:08:17.662209123 +0200 +++ /work/SRC/openSUSE:Factory/.openai-codex.new.1265/openai-codex.changes 2026-09-01 15:52:19.634067889 +0200 @@ -1,0 +2,34 @@ +Tue Sep 1 06:01:34 UTC 2026 - Martin Pluskal <[email protected]> + +- Update to version 0.152.0: + * Vim mode gains "/" and "?" search within drafts, with match + highlighting and n/N repeat navigation + * Rate-limit banners offer actions for checking usage, managing + credits, resetting limits and managing plans + * TUI and "codex exec" show credential-refresh progress, + including Amazon Bedrock reauthentication + * MCP server names may contain ":", "@", "/" and "." + * Individual MCP tools honour an output_token_limit setting + * App-server clients can configure thread/shellCommand timeouts + longer than one hour + * Cloud task requests reject untrusted backend URLs and refuse + redirects, protecting saved credentials + * The planning tool is now disabled by default; re-enable with + tools.update_plan.enabled = true + * Vim-enabled composers start fresh drafts in Insert mode again +- cargo-audit reports five advisories on the vendored lockfile, all + pre-existing and unchanged since 0.151.0; audit a bare Cargo.lock + because upstream's codex-rs/.cargo/audit.toml hides four of them: + * CVE-2026-25800 (RUSTSEC-2026-0185, quinn-proto 0.11.14): not + affected, reqwest gates dep:quinn behind its "http3" feature, + which the workspace leaves off, so it is never linked + * RUSTSEC-2026-0194 and -0195 (quick-xml 0.39.4) and + RUSTSEC-2026-0118 and -0119 (hickory-proto 0.25.2), DoS with no + CVE assigned: linked, but each fix is a semver-incompatible + bump of an intermediate crate, or not released at all +- Legal-Review-Notice: linked-crate count 874/876 -> 875/877 on + aarch64/x86_64, from one new first-party workspace crate + (codex-guardian-context). The vendored dependency set, the + bundled() versions and the License tag are unchanged from 0.151.0 + +------------------------------------------------------------------- Old: ---- codex-rust-v0.151.0.tar.gz New: ---- codex-rust-v0.152.0.tar.gz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ openai-codex.spec ++++++ --- /var/tmp/diff_new_pack.ZkN3vT/_old 2026-09-01 15:52:29.646417196 +0200 +++ /var/tmp/diff_new_pack.ZkN3vT/_new 2026-09-01 15:52:29.652417405 +0200 @@ -17,16 +17,20 @@ Name: openai-codex -Version: 0.151.0 +Version: 0.152.0 Release: 0 Summary: OpenAI Codex coding agent for the terminal # Legal-Review-Notice: upstream codex is Apache-2.0. Everything after that -# covers the third-party Rust crates statically linked into the shipped +# covers the Rust crates statically linked into the shipped # %%{_bindir}/codex binary, enumerated with # cargo tree --offline -p codex-cli -e normal,no-proc-macro -# against the vendored tree (874 crates on aarch64, 876 on x86_64; every one -# of them declares a licence, none is missing). Electing Apache-2.0 where it -# is offered and MIT otherwise, the tally is Apache-2.0 647, MIT 174, +# against the vendored tree (875 crates on aarch64, 877 on x86_64: 748 +# third-party vendored deps on aarch64 and 750 on x86_64, plus 127 +# first-party codex workspace members, which are Apache-2.0 like upstream. +# Every one declares a licence, none is missing; only the third-party count +# is a licence signal, the workspace one moves whenever upstream adds a +# crate). Electing Apache-2.0 where it is offered and MIT otherwise, the +# aarch64 tally is Apache-2.0 648, MIT 174, # Unicode-3.0 20, MPL-2.0 12, ISC 7, BSD-3-Clause 6, Zlib 5, BSD-2-Clause 1, # CC0-1.0 1, CDLA-Permissive-2.0 1. # - self_cell 1.2.2 is "Apache-2.0 OR GPL-2.0-only" and is the ONLY crate ++++++ _service ++++++ --- /var/tmp/diff_new_pack.ZkN3vT/_old 2026-09-01 15:52:29.785422046 +0200 +++ /var/tmp/diff_new_pack.ZkN3vT/_new 2026-09-01 15:52:29.804422708 +0200 @@ -8,27 +8,46 @@ the v8-poc/code-mode-runtime/code-mode-host workspace members (~213 MB of sources that are never compiled) stay out of the bundle. To regenerate: - tar xf codex-rust-v0.151.0.tar.gz - patch -p1 -d codex-rust-v0.151.0 < codex-drop-v8-code-mode.patch - rm -rf codex-rust-v0.151.0/codex-rs/vendor - osc service manualrun - rm -rf codex-rust-v0.151.0 + tar xf codex-rust-v0.152.0.tar.gz + patch -p1 -d codex-rust-v0.152.0 < codex-drop-v8-code-mode.patch + rm -rf codex-rust-v0.152.0/codex-rs/vendor + osc service manualrun cargo_vendor + rm -rf codex-rust-v0.152.0 The codex-rs/vendor removal drops the bundled bubblewrap 0.11.2 C sources, which %prep removes as well - codex uses the system bubblewrap instead. --> <!-- update=false is deliberate, not an oversight. source_validator suggests - update=true "to apply security updates", but cargo_vendor's own cargo-audit - pass reports the upstream lockfile clean - there is no advisory to fix - and - "cargo update" moves 383 of the ~1190 locked crates, including 0.x -> 1.0 - jumps (anstream, anstyle-parse) and an aws-lc-sys 0.39 -> 0.44 bump, i.e. a - wholesale untested re-resolution of an 850-crate link graph rather than a - security update. When an advisory does land, re-vendor the affected crate - with the cargo_vendor "update-crate" parameter instead. + update=true "to apply security updates", but "cargo update" moves 383 of + the ~1190 locked crates, including 0.x -> 1.0 jumps (anstream, + anstyle-parse) and an aws-lc-sys 0.39 -> 0.44 bump, i.e. a wholesale + untested re-resolution of an 850-crate link graph rather than a security + update. When an advisory lands on a crate that is actually linked, + re-vendor just that crate with the cargo_vendor "update-crate" parameter. + + cargo-audit is NOT clean, and running it inside codex-rs hides most of it: + upstream's codex-rs/.cargo/audit.toml ignores 11 advisories, which drops + the count from 5 to 1. Audit a bare copy of Cargo.lock instead. As of + 0.152.0, and unchanged since 0.151.0: + RUSTSEC-2026-0185 / CVE-2026-25800 (quinn-proto 0.11.14, fixed + 0.11.15) - NOT linked. reqwest gates dep:quinn behind its "http3" + feature, which the workspace leaves off, so it never reaches + "cargo tree -p codex-cli -e normal,no-proc-macro". + RUSTSEC-2026-0194, RUSTSEC-2026-0195 (quick-xml 0.39.4, DoS) - linked + via codex-tui -> syntect -> plist. Fixed in 0.41.0, which is + semver-incompatible for plist, so update-crate cannot reach it. + RUSTSEC-2026-0118, RUSTSEC-2026-0119 (hickory-proto 0.25.2, DoS) - + linked via codex-network-proxy -> rama-tcp -> rama-dns -> + hickory-resolver. 0118 has no fixed release at all; 0119 needs + 0.26.1, semver-incompatible for hickory-resolver. + Only 0185 carries a CVE id; the other four are GHSA/RUSTSEC-only, so + there is no security-tracker exposure. Re-run the bare-lockfile audit on + each bump - the fix for the linked four is an upstream dependency bump, + not anything this package can vendor around. --> <service name="cargo_vendor" mode="manual"> - <param name="srcdir">codex-rust-v0.151.0/codex-rs</param> + <param name="srcdir">codex-rust-v0.152.0/codex-rs</param> <param name="compression">zst</param> <param name="update">false</param> </service> ++++++ codex-rust-v0.151.0.tar.gz -> codex-rust-v0.152.0.tar.gz ++++++ /work/SRC/openSUSE:Factory/openai-codex/codex-rust-v0.151.0.tar.gz /work/SRC/openSUSE:Factory/.openai-codex.new.1265/codex-rust-v0.152.0.tar.gz differ: char 16, line 1 ++++++ vendor.tar.zst ++++++ /work/SRC/openSUSE:Factory/openai-codex/vendor.tar.zst /work/SRC/openSUSE:Factory/.openai-codex.new.1265/vendor.tar.zst differ: char 7, line 1
