Reason: The GStreamer 1.29 development line is missing 29 security advisories and there is no release to move to. 1.29.2 was tagged 2026-06-29; the fixes for the 1.28.5 batch (2026-07-08) and the 1.28.6 batch (2026-08-05) merged to main afterwards, all carrying milestone 1.29.3 -- a tag upstream has never cut. Verified per fix rather than inferred: for each of the 29 merge commits the GitLab containing-tag list is empty. Reading the advisories literally hides this. They declare ranges like "gst-plugins-bad < 1.28.6", and 1.29.2 < 1.28.6 is false under version ordering, so the development branch looks covered. It is not: the range describes the stable line, and the development line has its own milestone. A development snapshot is only ahead of stable until the moment it is cut. Fourteen distinct CVEs, several reachable from untrusted media: heap out-of-bounds writes in the DVD subpicture decoder (SA-2026-0071), the RFB/VNC source (0063, CVE-2026-59691), the closed-caption converter (0060) and the IMA ADPCM decoder (0077, CVE-2026-19387); a stack overflow in DTLS certificate verification (0062, CVE-2026-59692); and an authentication bypass in WebRTC SDP fingerprint validation (0061, CVE-2026-14935). 1.28.6 is unaffected by all 76 advisories issued in 2026 -- the highest upper bound in the entire series is "< 1.28.6" -- and every package masked below ships a 1.28.6 ebuild in this overlay. The older line is the safer one here. KEYWORDS ~arch was the protection this line was published under, and it is not enough. ~arch bounds who can reach the ebuild; it does not stop a system that accepts ~arch from selecting it. Measured on the maintainer's machine: 17 of these packages were installed at 1.29.2 with no 1.28.6 present. That is what promoted this from a note to a mask. The atom is "=<pkg>-1.29*", not "=<pkg>-1.29.2", and the wildcard is the point: it also catches 1.29.3 on the day it appears. That is deliberate. A milestone label is not a release, and the tag must be checked against the 29 fixes before anything from this line is unmasked. .autoupdate/packages.toml carries the matching "hold = true" on all 85 <pkg>@unstable records so the applier cannot bump past this entry on its own; release the hold and delete this block together, never one without the other. The atoms are deliberately unqualified -- the opposite of the net-libs/nodejs:0::gentoo entry below. Portage rewrites every repo-level mask atom as "<atom>::bentoo", which is exactly where these ebuilds live; ::gentoo ships no 1.29.x at all, so there is nothing there to mask. Ask the source before lifting this, never the version number: curl -s 'https://gitlab.freedesktop.org/api/v4/projects/1357/repository/tags?search=1.29' | jq -r '.[].name' A 1.29.3 in that list is the start of the check, not the end of it.
Masked by Lucas C.S. on 2026-09-04