commit 9885e7a25ba2e89457a8628907bec05256dfb6d9
Author: lucascouts <lucascs@protonmail.com>
Date: Thu Aug 27 16:45:09 2026 -0300

add(dev-libs/libgcrypt-1.12.3, metadata/md5-cache/dev-libs/libgcrypt-1.12.3), mod(.autoupdate/packages.toml)

Upstream released 1.12.3 on 2026-08-26 and ::gentoo is still on 1.12.2 (their
git tree has no newer ebuild either), so the overlay carries it ahead of the
master. Phoronix framed the release as the Intel SM3 / SM4 / SHA512 extension
work, but the security content is the stronger argument: an OOB read in the
GOST28147 IMIT MAC verify, a NULL ptr deref on an unsupported ECC genkey flag,
assertion failures in OCB (buffered block 65536) and on small-order Ed25519
public keys, plus missing validation in Argon2, Balloon, the KEM input lengths
and the RSA-PSS verify message length.

The ebuild is a verbatim copy of ::gentoo's 1.12.2 except for one line. That
is not laziness -- it is what the source says is required:

* the AC_ARG_ENABLE set is byte-identical between 1.12.2 and 1.12.3, so no
USE flag is missing. The new Intel routines have no configure knob: they
are gated on inline-asm probes (HAVE_GCC_INLINE_ASM_) and
dispatched at runtime through HWF, and they do compile here --
sha512-intel-shaext.o, sm3-intel-avx2-amd64.o, sm4-intel-avx2-amd64.o and
sm4-intel-avx512-amd64.o are all in the build tree;
* NEED_GPG_ERROR_VERSION is unchanged at 1.56, so RDEPEND already fits;
* LT_CURRENT 28 - LT_AGE 8 is still 20, so SLOT="0/20" holds and no revdep
needs a rebuild. emerge -pv confirms: 1 package, nothing dragged along;
* both ::gentoo patches apply with `patch -p1 --dry-run -F0`, zero fuzz.

The one line is KEYWORDS, downgraded from ::gentoo's stable amd64 arm arm64
ppc ppc64 x86 to ~arch. A release that is one day old is not stable, and an
overlay ebuild that claims otherwise is the failure already recorded for the
vulkan family: a stable ebuild reaching for a ~arch dependency puts the solver
somewhere it cannot resolve. scripts/gentoo-parity.sh does not catch this
axis, which is exactly why it is called out here.

Verified locally (this host has no sudo, so nothing was merged -- the image
was never built and install was never run):

* prepare: both patches applied, eautoreconf clean;
* compile: full build with the profile's own USE ("asm getentropy") and
CPU_FLAGS_X86, single ABI;
* test: "All 39 tests passed (4 tests were not run)" -- the 4 are benchmark
and bench-slope, skipped by the ebuild's own GCRYPT_NO_BENCHMARKS=1, plus
the two hashtest-*g that need --enable-large-data-tests;
* tarball signature checked against gnupg.org/signature_key.asc: valid,
"Werner Koch (dist signing 2020)", 6DAA6E64A76D2840571B4902528897B826403ADA;
* pkgcheck --cache=-git: no result. Confirmed non-vacuous by scanning all
of dev-libs/ with the same fresh cache dir -- six other packages reported
findings, libgcrypt reported none.

The autoupdate record probes gnupg.org's FTP dir, the only place upstream
publishes. It uses select = "max" rather than the default first-match: the
listing is newest-first today, but it holds every release since 1.4 on one
flat page, and a change of sort order would silently pin an ancient version.
That is safe here only because the dir carries no prereleases at all -- every
.tar.bz2 in it is a plain X.Y.Z. `--check dev-libs/libgcrypt` was run against
the live endpoint and reports up to date.

Also closes the dev-python/tree-sitter record with the "# END" line it was
missing since 8071b9ca3. It was the last record in the file, so nothing
downstream shifted; `--lint` now reports "record model OK" instead of one
missing-end issue.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

commit c37938fb612bbdd71144a6059b7e57b91c10d467
Author: lucascouts <lucascs@protonmail.com>
Date: Sun Aug 25 22:03:21 2019 +0000

the master branch is the minimal overlay configuration.

commit 9b3cae6b02134d5444a0b9c6b7e5679683584f9d
Author: lucascouts <lucascs@protonmail.com>
Date: Fri Feb 8 23:29:53 2019 -0300

added dev-libs/libgcrypt-1.8.3-r1