emacs/fixrand.c: guard against NULL real_clock_gettime from dlsym failure - #278

…package)

Info-ZIP unzip 6.0 has been frozen since 2009 and carries unfixed
CVE-2014-8139/8140/8141 + CVE-2018-1000035 (4 HIGH) with no upstream to track —
it was both vuln-exposed AND update-dark (pkgmgr check: no-source). bsdunzip,
added to libarchive in 3.7.0, is its maintained successor.

- New `packages/libarchive` (3.8.7, GithubRepo libarchive/libarchive, BSD-2):
  builds bsdtar/bsdcpio/bsdcat/bsdunzip + libarchive.so against zlib/bzip2/lzma
  (heavy optional backends disabled to keep the dep set lean). Source staged to
  gs://minimal-staging-archives/.

- `packages/unzip` becomes a thin compat shim: a /usr/bin/unzip symlink to
  bsdunzip (libarchive runtime dep). Info-ZIP source + build dropped. bsdunzip
  is a drop-in for the flags our callers use — verified in bsdunzip.1 that
  -o/-q/-d/-p are all supported, so bun + chromium-bin +
  chromium-headless-shell-bin keep invoking `unzip` unchanged. Version-tracking
  now follows libarchive, so it's no longer update-dark.

Locally validated: both build.ncl parse + resolve; `pkgmgr check --package
unzip` now reports up_to_date (3.8.7) instead of a `no-source` skip.

DRAFT — needs the buildbot to verify: libarchive compiles with the chosen
configure flags, bsdunzip is produced, the symlink + OutputBin lint pass, the
roundtrip test extracts via bsdunzip, and the three consumers (bun, chromium-bin,
chromium-headless-shell-bin) still build against bsdunzip.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

The sandbox rejected the /usr/bin/unzip -> bsdunzip symlink: bsdunzip lives in
the libarchive package's output, so the symlink 'points outside output
directory'. Replace it with a /bin/sh wrapper that execs /usr/bin/bsdunzip
(provided by the libarchive runtime dep) — a real file, no symlink escape;
callers keep invoking unzip unchanged.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…zip plan)

Reverses the bsdunzip migration: bun's build invokes `unzip -o -DD -d` and `-DD`
(don't-restore-timestamps) is an Info-ZIP-only flag bsdunzip lacks, so swapping
unzip→bsdunzip broke bun's build. Info-ZIP is the only impl with `-DD`.

Instead, do what every distro does — keep frozen Info-ZIP 6.0 and apply the
backported security patches. We were shipping the pristine `unzip_6.0.orig`
tarball with NO patches, which is exactly why it scanned 4 HIGH. Now stage +
apply Debian's full 6.0-29 series (31 patches): fixes CVE-2014-8139/8140/8141/
9636/9913, CVE-2015-7696/7697, CVE-2016-9844, CVE-2018-1000035, CVE-2019-13232,
CVE-2022-0529/0530 + build fixes. Patch 30 drops the K&R gmtime()/localtime()
declarations, replacing the manual sed that lived in build.sh.

Drops the new libarchive package (no remaining consumer). unzip stays
update-dark, which is correct: 6.0 is EOL and the patches are its maintenance.

Follow-up: VEX the patched CVE IDs so the version-based scanner (which can't see
the backported fixes) clears them.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

… edits)

The previous commit's git-add aborted on the already-removed libarchive
pathspec, so the build.ncl patches Source + build.sh apply-loop never staged.
This adds them: the staged-tarball Source and the series-apply loop (and removes
the now-redundant gmtime sed, handled by patch 30).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

mkromfs/pack_ps read SOURCE_DATE_EPOCH but then do
`if (!buildtime) buildtime = time(NULL)`, treating the sandbox's
SOURCE_DATE_EPOCH=0 (epoch 0 is falsy) as unset and falling back to
wall-clock time. That stamped a non-deterministic gs_romfs_buildtime into
usr/bin/gs. Fall back to time() only when SOURCE_DATE_EPOCH is genuinely
unset (base/mkromfs.c:2614, base/pack_ps.c:344).

Verified on aarch64: two from-scratch builds are byte-identical
(repro-check diff, 196/196 files).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

After the existing fixrand.so shim (getrandom/urandom), the dumped .pdmp
still differed in 11 bytes — two wall-clock timestamps read via
clock_gettime(CLOCK_REALTIME), which the shim didn't cover: the *scratch*
buffer's buffer-display-time (Fcurrent_time in make_initial_frame) and
Vgc_elapsed GC timing (src/alloc.c). Extend the shim to return
SOURCE_DATE_EPOCH for CLOCK_REALTIME (other clocks pass through).

Verified on aarch64: two from-scratch builds are byte-identical
(repro-check diff, 4282/4282 files).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

mono's AOT output had three independent non-determinism sources:

1. build_date: bare `date` in mono/mini/Makefile.am.in ignores
   SOURCE_DATE_EPOCH -> wall-clock in mono-sgen + AOT version strings.
   Pin it from the epoch before autogen.sh.
2. AOT id: aot-compiler.c generate_aotid() emits 16 random bytes into
   each AOT image. The net_4_x build doesn't thread the 'deterministic'
   aot option, so zero the aotid at the source (same emitted result).
3. AOT temp name: g_file_open_tmp("mono_aot_XXXXXX") leaks a random
   suffix into each *.dll.so as a local STT_FILE symbol. Strip the
   runtime-unneeded locals from the AOT images post-install.

Verified on aarch64: two from-scratch builds are byte-identical
(repro-check diff, 3131/3131 files).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…hanges)

Adopts the hardening idea from the Edge Delta bot's #274 (cleanly — no
whole-file reindentation, executable bit preserved): verify the
'if (!buildtime)' pattern exists in both files before sed-ing, so a future
ghostscript that renames it fails the build instead of silently shipping a
non-reproducible binary.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

CPython's configure resolves MODULE__CTYPES_LDFLAGS via PKG_CHECK_MODULES,
which non-deterministically picks '-L/usr/lib/../lib64' vs '-L/usr/lib/../lib'
-> leaks into _sysconfigdata*.py/.json and config-*/Makefile (6 files flip
across builds). Pin LIBFFI_CFLAGS/LIBFFI_LIBS on the configure line so it
uses them verbatim and skips pkg-config; result is '-lffi -ldl' every build.

Verified: with this pin, the _sysconfigdata libffi flip is gone from a
build-twice diff. (Full byte-reproducibility of python additionally needs a
pinned toolchain — .comment records the binutils version — and is gated on
the --enable-optimizations/PGO perf decision; both are out of scope here.)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

GHC's code output is already reproducible; the residual is metadata
ordering from hash-set iteration of package/UnitId collections:
1. link-arg/DT_NEEDED/.dynstr order — backport of upstream GHC #26838 /
   MR !15453 (sort preload1 in compiler/GHC/Unit/State.hs); Debian ships
   this exact patch for 9.10.3.
2. ghc-pkg package.cache — sort the .conf list before serialize in
   utils/ghc-pkg/Main.hs (no upstream fix; sort already imported).
Both guarded by grep so a future GHC source change fails the build loudly.
Fixing the compiler propagates to all downstream Haskell (stack, HLS).

DRAFT: Debian-proven + guarded, but not yet local build-twice-verified
(GHC is a multi-hour build_cost_multiple=6 build).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Per review on #277: patch (2) relies on 'sort' being in scope in
utils/ghc-pkg/Main.hs. 9.10.3 imports it (Main.hs:78), but add a grep
guard so a future GHC import reorg fails fast here rather than deep in
the multi-hour Hadrian build. Output-neutral; verified result unchanged.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…into unstable

…into unstable

…into unstable

…into unstable

…into unstable

…into unstable

…into unstable

…lure