What happens
The naming flow reads the archive twice. unwritable_names opens it, reads the listing and builds the report the user answers. Then extract_with opens it again, reads the listing again in plan_for, and extracts. Nothing ties the second read to the first.
Between the two, the file can change. On the desktop the gap is as long as the user takes to read a dialog and type into it.
Why it is not urgent
The plan is rebuilt from the second read, so the answers are applied to whatever the archive says at extraction time, and every guard (rules, collisions, containment) runs against that same second read. So this does not let an unwritable name through: it is not a check-then-use hole.
What it does mean is weaker than that, and still worth stating: the user consented to a set of names that is not provably the set that was extracted. They were shown "these 3 entries need an answer", they answered, and a different archive may have been written. The listing that comes back names what was written, so nothing is hidden after the fact, but nothing warns during.
Options
- Do nothing, and say so in the doc comment. Given the threat model (the user chose this file through a native dialog on their own machine), that may well be the honest answer, and an explicit "we accept this" is worth more than silence.
- Or keep the archive open across the two calls, which changes the command signatures and makes the desktop hold a handle while a dialog is up.
- Or compare cheaply: record the size and mtime with the report and refuse if they moved by extraction time. Not a security boundary, but it turns a silent difference into a message.
The first is probably right. Filing it so the decision is recorded rather than defaulted into.
Found while auditing the Windows CI failure that led to #88.
What happens
The naming flow reads the archive twice.
unwritable_namesopens it, reads the listing and builds the report the user answers. Thenextract_withopens it again, reads the listing again inplan_for, and extracts. Nothing ties the second read to the first.Between the two, the file can change. On the desktop the gap is as long as the user takes to read a dialog and type into it.
Why it is not urgent
The plan is rebuilt from the second read, so the answers are applied to whatever the archive says at extraction time, and every guard (rules, collisions, containment) runs against that same second read. So this does not let an unwritable name through: it is not a check-then-use hole.
What it does mean is weaker than that, and still worth stating: the user consented to a set of names that is not provably the set that was extracted. They were shown "these 3 entries need an answer", they answered, and a different archive may have been written. The listing that comes back names what was written, so nothing is hidden after the fact, but nothing warns during.
Options
The first is probably right. Filing it so the decision is recorded rather than defaulted into.
Found while auditing the Windows CI failure that led to #88.