`--append-only` does not protect retention integrity: attacker-controlled `--time` lets a compromised client force real snapshots out of the keep policy

Summary

Append-only mode (rest-server --append-only) is designed to let a compromised backup client keep writing without being able to delete or overwrite existing data. That protects the stored pack files. It does not protect the correctness of forget retention decisions, and I think that gap is worth closing or at least documenting more prominently.

The problem

restic backup accepts --time, --host, and --tag as free-form client-supplied values, and restic forget keeps the last snapshot in each time bucket. A client that can append (which is the whole point of append-only) can create arbitrary snapshots that land in any bucket the retention policy uses.

An attacker who has compromised a client with append-only credentials can therefore:

1. Back up an empty directory repeatedly with --time set to the end of each day/week/month/year within the retention window, and with --host/--tag matching the legitimate client so snapshot filters don't distinguish them.
2. These fake snapshots become the "keepers" for --keep-daily / --keep-weekly / --keep-monthly / etc.
3. On the next forget --prune run from the trusted host, the real snapshots — no longer selected by the policy — are removed, and prune deletes the underlying data.

The attacker never deletes anything themselves. Append-only holds. The data is destroyed by the operator's own trusted pruning, using attacker-planted metadata. This defeats the specific threat model append-only exists to address.

Expected behavior

A compromised append-only client should not be able to influence which snapshots the operator's retention policy keeps or discards.

Possible directions for a fix

Looking for maintainer guidance on which is acceptable:

• Server-side timestamp enforcement: an option for rest-server / the repo to reject or ignore client-supplied --time that deviates from the server's clock beyond a small tolerance, so snapshots can't be backdated/postdated into arbitrary buckets.
• forget safety heuristics: warn (or refuse without --force) when a forget run would drop snapshots in favor of newly-appeared empty/near-empty ones, or when many snapshots share suspicious timestamps.