Upstream sync has failed on every run since flea v0.3.0 was published, with
"Release v0.3.0 does not contain every required upstream security fix". Eight
of the nine required fixes are present. The ninth is too: the check is wrong.
The check pinned the literal call `regfile::open_if_regular(src, O_NOFOLLOW)`.
v0.3.0 introduced directory-relative opens and the first argument became
`src.at`. O_NOFOLLOW is still passed to the same function, on the same line,
under the same comment, and the release hardened symlink handling further --
it added copy_symlink_at, opens directories with O_DIRECTORY | O_NOFOLLOW, and
reaches every child through this process's own descriptor. The guard refused a
release that is strictly safer than the one it accepted.
The property worth asserting is that the copy opens its source with
O_NOFOLLOW, so a symlink swapped in cannot redirect the read. Pinning the
exact expression asserted the spelling instead, which is why a rename read as
a removed fix. The check now matches the call and the flag together.
Verified against the real archives rather than by inspection:
v0.3.0 (src.at, O_NOFOLLOW) accepted
v0.2.1 (src, O_NOFOLLOW) accepted, so the change is backwards
compatible with what is packaged today
first argument renamed accepted
extra flag or argument added accepted
O_NOFOLLOW dropped refused
call replaced with File::open refused
flag left only in a comment refused
End to end with the real feed: the hook on master exits 1 with the refusal,
and with this change exits 0 and reports 0.3.0 with its verified checksum.
The other eight literals are untouched.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Every channel has failed since 0.2.1 landed: one package failing fails the
whole build, and the build step aborts the release before sign, promote or
sync. Nothing has published on edge, rc or stable since 2026-09-11, and 26
built packages have been rebuilt and discarded every cycle.
backend::redo::tests::redo_refuses_changed_sources_and_destination_collisions
writes a file and immediately asks redo to notice the edit. flea decides
"changed" from ctime alone -- src/backend/undo.rs records (ctime, ctime_nsec)
as the whole identity -- and this kernel stamps ctime from the coarse clock,
so two writes microseconds apart share a timestamp and the guard sees no
change. redo returns Ok where the test demands Err, which is why it fails
almost every run rather than intermittently.
Measured on this builder: 196/200 back-to-back write pairs on /dev/shm and
192/200 on the root filesystem produced an identical ctime. That also retires
the premise of 82363cb: /dev/shm does not buy finer timestamps here, so moving
the suite to tmpfs could never have fixed this, and the comment saying it does
is corrected. A probe cannot decide this at runtime either -- one using stat
reports the filesystem as fine-grained, because the stat subprocess alone
costs more than the granule it is trying to measure.
Both halves belong upstream in thisisgm/flea: the test assumes a resolution
the kernel never promised, and the identity it exercises cannot see a
same-granule edit, which is a real hole in undo/redo rather than only a test
artifact. Skipping one test is the narrow fix; holding the package back would
have stalled the other 26.
Only this test is affected. new_file_is_recreated_but_changed_or_replaced_
files_survive_undo asserts the same refusal and passes, because enough work
separates its write from the identity capture to cross a granule.
Verified with bin/repo build --package flea: filesystem suite 63 passed,
main suite 528 passed, flea 0.2.1-3 built.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ryan Hughes