format: archives get settings - a password on zip, permissions and an owner on tar.gz

[donislawdev]

Settings for archives: a password on zip, permissions and an owner on tar.gz.
Three commits, one subject.

A zip can be locked

tfg generate --format zip --size 30kb --set entries=3 \
  --set password=Secret123 --set encryption=aes-256

writes an archive of exactly 30720 B that 7-Zip opens with that password
and refuses without it. aes-128, aes-192, aes-256.

It is possible at all because of one measurement. A stream cipher does not
change the length of what it encrypts, so a lock adds a fixed count per
entry - measured twice over, from the size of the file and from the
compressed size field of what 7-Zip writes:

	data per entry	extra field, local + central	total
ZipCrypto	+12	0	+12
AES-128	+20	11 + 11	+42
AES-192	+24	11 + 11	+46
AES-256	+28	11 + 11	+50

So the size of the archive stays an exact function of its input and the
planning phase can still state it without building it, which is the guard the
whole container design rests on. Compression has no such property, and that is
why this setting exists and that one still does not.

Two more facts were read out of the bytes 7-Zip writes, and each decided half
the work:

• An AE-2 entry carries a CRC of zero, because the authentication code is
  what proves the contents. Nothing about the plaintext has to be known before
  the first byte, so an entry is encrypted as it streams and an archive of any
  size costs the memory of an archive of one byte.
• ZipCrypto carries the real plaintext CRC, so it cannot be written the
  same way. It is not here for that reason rather than because it was
  forgotten - MVP-FORMATS.md section 2.16 says what it would take.

The salt is derived from the run seed and never drawn. A salt from
crypto/rand gives a perfectly good archive that differs on every run, which
is untouchable rule 3 broken in the one place where every other check stays
green.

The password goes into the manifest in plain text, by the owner's decision.
A locked fixture nobody can open is worth nothing. It has its own guard, because
the next person to read it will assume it is a mistake.

Two settings say it together

A password with encryption=none, or an encryption with no password, is
refused and both refusals name both halves. That is forced by the window rather
than chosen: a menu cannot be empty, so encryption arrives as none from
every window run whether or not anybody looked at it, while a box somebody
types in arrives empty and is left out.

tar says plainly that it cannot

targz does not have a property called password is true and sends somebody
looking for the build that has it. There is none. Descriptors can now declare
what they deliberately cannot take, with the reason, and the refusal lands
on FORMAT rather than USAGE - a deliberate limitation is not a spelling mistake.

The alternative in the world is worse than either, and it is why this refuses
instead of ignoring. Measured: 7-Zip accepts -p on a tar, exits 0, prints
nothing and writes a plaintext archive. Somebody asking for a locked fixture
gets an open one and never finds out.

A tar.gz can say what its files may do

--set entry_mode=755 --set entry_owner=root gives an archive where
tar -tvzf reads -rwxr-xr-x root/root. Modes 000 through 777, owners
unset, root, user.

It costs no bytes: every field of a USTAR header is fixed width. The useful
cases are the ones nobody makes by accident - 000 is a file nothing can read
after unpacking, 777 is one a scanner should have something to say about, and
an archive claiming root owns everything is what a careless extractor turns
into a privilege problem.

The defaults are what this format has always written, to the byte.

Both settings sit in the shared archive vocabulary while only targz names them,
which is the other direction of the same asymmetry the password showed.

Two findings that were not the task

A mutation found that two of the new guards were proving less than they
said. The archiver guard could not see a broken keystream, and the reason is a
property of AE-2 rather than an oversight: its authentication code is computed
over the ciphertext, so a reader checks that nobody edited the encrypted bytes
and never that the plaintext is what was put in. Turn the counter the wrong way
and 7-Zip still says "Everything is Ok". It now extracts the archive for real
and compares against the same archive built unlocked. The determinism guard
could not see a salt that ignored the seed, because the children are seeded from
the run too - it now reads the salt bytes directly.

Go cannot read a lot of the .tar.gz files this tool writes, and nobody knew.
Found because a guard tried to read an archive we had just written and could
not. Measured:

comment length compress/gzip accepts	511 B, refuses from 512
our padding channel	up to 4096 B through that comment
archive sizes readable by Go	548 of 866
not readable	318 (37%), first at 10269 B

Every one of those is fine to 7-Zip, GNU tar and bsdtar, and every one fails in
a Go program with gzip: invalid header - which reads like a corrupt file
rather than like a field this reader will not take. Testers write tools in Go.

Not fixed here. Both ways of fixing it move bytes, which is untouchable rule
3 and the owner's call. Written up as O163 with the two options and what each
costs. The guard steps past the gzip header by hand meanwhile, so a test about
permissions does not fail on a fault that is not its subject.

Evidence

• 7-Zip opens every locked archive with the right password and refuses the
  wrong one and none at all. Contents are extracted and compared against the
  unlocked archive, so a scrambled keystream cannot pass.
• Exact size held for every method across four sizes, including odd ones.
• TestOurOwnGeneratorsHaveNotDrifted green: nothing that was not asked for
  moved.
• Twelve new guards, ten proven by mutation. One is on the unproven list with
  its reason - it defends a property of the USTAR header rather than of any line
  of ours.
• Code shape gates green. D1 parity now 97 of 108.