Fix the security audit and adversarial hunt findings against 4.6.0 - #330

WrappingIO.write iterated the shared listener set while start_capturing
and stop_capturing on another thread added or removed bars, which on
3.14t and 3.15t raised "Set changed size during iteration" tens of
thousands of times per run and dropped bar updates. The listener set is
now guarded by a small dedicated StreamWrapper.listeners_lock that every
WrappingIO shares, held only around the add, remove and the snapshot in
write(), never while calling out, so it cannot take part in a lock-order
cycle with a logging handler or a locking target stream. The wider
StreamWrapper.lock (reentrant) guards wrap, unwrap and capture
transitions.

Both classes pickle and deepcopy again by dropping the locks in
__getstate__ and recreating them on load. StreamWrapper has class-level
default locks so a subclass that skips super().__init__() keeps working.
Unwrapping delivers the dropped wrapper's buffered text to the original
stream and never raises for a stream that cannot take it (logged at
DEBUG).

What working code can notice: WrappingIO gains an optional lock=
keyword (api_surface_snapshot regenerated), its default lock is a plain
threading.Lock, and text that was buffered in a wrapper at unwrap time
now reaches the original stream instead of being lost.

The new-style widget formatter resolved any attribute path a template
named, so a template taken from user input could walk {variables.x.__class__}
and further into the interpreter. Rendering goes through a string.Formatter
subclass that refuses attribute segments starting with two underscores
and raises ValueError; single-underscore names and everything else render
exactly as in 4.6.0. Non-str templates with a callable format() (lazy
translation proxies) are rendered through str(); None, lists and numbers
raise TypeError as before.

ProgressBar(desc=...) is rendered literally as f'{desc}: ' and is never
a format template; a prefix assigned afterwards is a template as before.
PROGRESSBAR_MINIMUM_UPDATE_INTERVAL that is not a non-negative finite
number is ignored with one WARNING per distinct value instead of raising
at construction.

What working code can notice: templates addressing __dunder__ paths now
raise ValueError, a desc containing braces renders them literally, and a
bad interval variable logs instead of raising.

Validate every size option through size_to_bytes with a minimum and a
parser error (status 2) instead of a traceback, reject a missing input,
a directory input, a directory output and an output path that is also an
input before the output is truncated, and close every input after its
copy. An early-closing reader (`... | head`) ends the copy quietly with
status 0: the BrokenPipeError is caught and, when the broken stream is
the process's real stdout (fd 1), the descriptor is pointed at os.devnull
so the interpreter's exit flush cannot raise again. A replacement
sys.stdout that owns another descriptor is left alone. Ctrl-C exits 130.

main() is split into small helpers (_parse_size_option, _collect_inputs,
_check_output_path, _open_input, _copy_stream) with no behaviour change
beyond the above.

What working code can notice: invalid -s/-B/-L values exit 2 with a
message instead of a traceback, `-o` onto an input file is refused, and
`... | head` exits 0 where 4.6.0 exited 120 with "Exception ignored".

…play

Batch item labels are data, not terminal markup: every ESC-introduced
sequence and every C0/C1 control is stripped before the label becomes a
MultiBar key, so an item cannot move the cursor, retitle the terminal or
hide output from the other rows. Labels that are not str are rendered
through str() first. A finished task's bar is finished (end='') before
it is dropped so its stream listeners, capture refcounts and resize
handler return to baseline instead of leaking per task.

In the shell runner the {} and {item} placeholders are substituted in a
single regex pass, so placeholder text inside an item is never expanded
again, and shell=True with a list or callable template is a TypeError:
subprocess would run only the first element through the shell and drop
the item.

The ANSI detection called the console-mode probe on Windows for every
stream, including pipes and files, where it reports on the console the
process happens to own rather than on the stream being asked about.
The probe now runs only when the stream is a tty, matching the other
platforms.

The publish job runs only for a v* tag whose name matches __version__
and whose commit is the checked-out commit, so a manual dispatch on a
branch or a mistyped tag cannot publish. The built sdist and wheel are
listed and refused when they contain sync-conflict, .orig, .rej or .bak
files. The workflow token is limited to contents: read. Local secret
and environment files are ignored by git.

Two adversarial reviews of the previous commit found that the
transition lock was still held while logging ("wrapping excepthook")
and while flushing captured text into the original streams. A logging
handler that writes into a wrapper, or a target stream with its own
lock, could then wait on a thread that was waiting for the transition
lock: a deadlock 4.6.0 could not have, because it held no lock at all.
Moving the call-outs outside the lock naively made two overlapping
stop_capturing() calls deliver the same text twice.

Now every transition takes the buffered text under the lock
(WrappingIO._take) and writes it to the original stream after
releasing it (WrappingIO._deliver), so nothing blocks while the lock is
held and no text is delivered twice. The excepthook installation logs
after the lock is released.

The locks live in a small shared box, _SharedLock, that a StreamWrapper
and the wrappers it installs hold in common. The box keeps its identity
through pickle and deepcopy whichever object is the root, so restored
wrappers share the restored lock, subclass slots survive (default
pickling again, no __getstate__), subclasses that define __eq__ without
__hash__ construct, and a forked child gets fresh unlocked locks for
every live box through os.register_at_fork, standalone wrappers
included. Lock annotations evaluate on 3.10 to 3.12, where
threading.Lock is a factory function.

What working code can notice: StreamWrapper.lock and listeners_lock
are read-only properties (both were introduced on this branch, 4.6.0
had neither), and get_type_hints(WrappingIO.__init__) works again on
3.10 to 3.12.

ProgressBar(desc=...) rendered the literal text by inserting the plain
str into the widget list, so bar.widgets[0] was a str where 4.6.0 (and
prefix=) had a FormatLabel; a subclass that rewrites that label after
start() silently missed it. The desc-derived prefix is now escaped and
wrapped in a FormatLabel when the widgets are built, while bar.prefix
keeps the raw f'{desc}: ' value that the fast path renders verbatim.

The safe formatter also refuses the non-dunder attributes that lead
from a generator, coroutine, traceback or frame stored as a bar
variable to a frame's globals (f_globals, f_locals, f_builtins,
f_back, gi_frame, cr_frame, ag_frame, tb_frame).

The once-per-value warning for a bad PROGRESSBAR_MINIMUM_UPDATE_INTERVAL
records the value under a lock before logging, so concurrent first
constructions produce one record, remembers every distinct value, and
its lock is reset in a forked child.

Refuse an -o path that is the file stdin is open on, an unreadable
input and a closed stdin before the output is opened, so the output is
never truncated for an invocation that then fails. Reject a size option
above sys.maxsize instead of raising OverflowError from read(). Flush
the output inside the guarded block, so a broken pipe that is only
noticed when a small copy's buffer reaches the pipe exits 0 like a
large one.

The render thread snapshots the bars and a worker may delete one
(task_finished) before the finished-bar path runs. That path now
returns early for a bar that is no longer registered, undoes its
timestamp if the bar vanished while it was stamped, and ignores a
concurrent removal when expiring it, instead of leaking the entry or
raising KeyError from the render thread.

…ames

The version check accepted only `__version__ = '...'`; the annotated
spelling `__version__: str = '...'` failed the guard although the
package built. The stray-file pattern matched any path containing
.orig, .rej or .bak; it now matches those as file extensions only.

The test relied on 30 ms sleep differences between five workers and
failed twice on a loaded machine. Only one item can now complete until
a gate opens, so the first yielded pair is deterministic.

test_wrapping_io_and_a_redirecting_bar_deepcopy_and_pickle deep-copied a
started, redirecting bar and a StreamWrapper holding one, and dropped the
copies. A copy of a started bar is itself a started bar, so its __del__
ran finish() whenever the gc got to it, usually inside a later test,
where it dropped the singleton's capture count and restored sys.stdout
under that test's feet. That is what made
test_redirected_stderr_lines_are_flushed_above_bar fail now and then
under coverage. The copies are marked finished before they go.

A flush takes the buffered text of both wrapped streams and then writes
it to the two original streams. When the stdout write raised, the
exception left the loop before the stderr text was written, and that
text was already gone from the buffer, so a broken stdout cost the
stderr lines of the same round.

Every taken text is now written before the first exception is raised.
Delivery stays as 4.6.0 did it: each caller writes what it took, at
once, with no lock held during the writes. A single ordered delivery
queue was tried first and taken back again, in both a non-blocking
shape (a caller returned with its own text still queued behind another
thread, so text written right after a stop landed above it, and a
flush during a render thread's delivery wrote nothing) and a blocking
shape (a lock-order cycle with a logging handler whose stream is the
wrapper, when the original stream itself logs).

Working code notices: an exception from the stdout target no longer
drops the stderr text flushed in the same call.

The shared resize registry saved the previous handler when its set of
bars was empty and restored it from the last uninstall(). Three ways out
of a bar skipped that restore: a bar collected without finish() left the
registry's handler installed for the rest of the process, a finish() off
the main thread hit the ValueError from signal.signal() with the bar
already discarded, after which the next bar saved the registry's own
handler as the "previous" one and the real one was lost for good, and a
handler installed from C (getsignal() returns None) made the restore a
TypeError. One bar whose _handle_resize() raised also skipped the other
bars and propagated out of the signal handler into unrelated code.

Whether the shared handler is installed is now read from getsignal()
instead of inferred from the set, so a handler that other code set over
ours is never clobbered. The saved handler is cleared only after a
restore succeeds, a restore that fails off the main thread is retried at
the next registration change or the next resize signal, None restores
SIG_DFL (SIGWINCH is ignored by default), every registered bar gets a
weakref finalizer that restores once no live bar is left, and a failing
bar is logged at WARNING on the progressbar.bar logger and skipped.

What working code can notice: a resize handler that raised now logs
instead of raising, and the previous handler comes back after bars that
were dropped without finish() or finished from a worker thread.

WrappingIO.write() appended to the StringIO buffer without a lock while
_take() read it, then truncated it. A write landing between the read and
the truncate was gone: deterministic with a buffer that pauses in
truncate(), and a handful of tokens per run in a six-thread stress on the
free-threaded builds. 4.6.0 has the same race.

Each WrappingIO now holds a reentrant lock in a shared-lock box that
write() and _take() take around the StringIO write, getvalue, seek and
truncate calls only. It is never held while a listener, the target
stream or the buffer's own flush() is called (a review found that a
replacement buffer whose flush() logs through a handler on the wrapper
deadlocked when the flush ran inside the lock), so it cannot take part
in a lock-order cycle with a logging handler. The box survives pickle,
deepcopy and fork like the listeners lock does, and the class-level
default keeps a subclass that skips super().__init__() working.

`progressbar FILE -o /dev/stdout | head -c1` exited 1. The file opened
for -o is not sys.stdout, so the quiet exit for a reader that went away
did not apply, and the interpreter reported the failing flush at exit.

_output_is_stdout() now also accepts a file whose fstat() reports the
same device and inode as sys.stdout, and _discard_broken_stdout() points
both descriptor 1 and the file's own descriptor at os.devnull so neither
the exit flush nor the exit stack's close raises again. Nothing changes
unless descriptor 1 is involved: a replacement stdout on another
descriptor, a regular output file and a FIFO given by path are left
alone.

python-utils before 4.1.4 scaled a value between 0 and 1/1024 to a
negative power, and DataSize and format_unit_value() used that power as
an index into their prefix tuple, so a fraction of a byte rendered with
the largest prefix ('0.1 YiB', '0.1 PiB'). 4.1.4 returns power 0 for
those values. The floor moves from 3.8.1 to 4.1.4, the development lock
follows, and two tests pin the rendering of a value below one byte.

What working code can notice: installing progressbar2 upgrades a
python-utils older than 4.1.4. Both packages already require Python
3.10 or newer.