a2til's whole job is opening files other people made — disk images and archives from emulators, the internet, and thirty-year-old floppies. It treats that input as hostile, and reports of places where it fails to are welcome.

Please report anything with a security dimension privately first:

TODO before release: a contact address, and (once the public repository exists) whether private reports go through the tracker's private-report feature or by mail.

For anything already public, or where you would rather discuss it in the open, an ordinary issue is fine.

A malformed or hostile image should produce a controlled error, and never:

• an unhandled low-level exception (IndexError, struct.error, UnicodeDecodeError, RecursionError)
• a hang or an unbounded loop
• unbounded memory use from a length the image declares
• a write outside the directory the caller named, from a filename the image supplies (disk and archive names are not host paths: DOS 3.3 stores thirty arbitrary bytes, an HFS name may contain /, and a NuFX pathname is whatever the archive says)
• damage to an image beyond the operation that was asked for

test/test_fuzz.py (Hypothesis) is the standing test for the first three, across every engine.

• a2til writes to images you point it at. That is the tool. readonly=True on Volume/mount, or a bytes source, opens without write intent and makes every mutation raise up front.
• a2til repair IMAGE modifies the image. That is the command's whole job: it fixes a subdirectory header older a2til builds wrote one entry early (see notes/kludges.md). Nothing else writes without being asked — opening an affected image reports the problem and changes nothing.
• A disk image is not a sandbox. Extracting a file to a host directory writes a file to that directory.

Pre-1.0: fixes land on master and in the next release. There are no maintained release branches yet.