v4.8.1

• sandbox.writes: [{task: X}] now grants what X and the tasks it runs
  write: their generates and sandbox.writes directories, and reading their
  dotenv files, so a sandboxed task running X, with task: or as a nested
  task X, needs no other entry for them. Their sandbox.reads are not
  granted.
• A task: entry in sources now covers what the task runs. {task: X}
  also takes in the sources of the tasks X runs through setup, deps and
  task: commands (including for: loops and deferred calls), transitively,
  with the vars those calls pass, so a task running X no longer lists X's
  dependencies. In generates it still copies X's own entries, and from:
  still copies its direct targets'. Such tasks, and wrappers reaching them, get
  new fingerprints and cache keys, and rebuild once. Calls behind an if:
  count too, so a missing task there fails with exit code 200, naming the
  calls leading to it; a deferred call depending on EXIT_CODE, or on
  {{.CHECKSUM}} in a task with from: or task: entries of its own, must
  be listed explicitly; a recursion whose end the references cannot see stops
  at 256 calls of one task, or 1000 calls in all, with exit code 204. A cycle
  between references is no longer an error.
• from: cmds now reads templated deferred calls, as they run after a
  success, instead of looking up their unrendered name; one depending on
  EXIT_CODE, or on {{.CHECKSUM}} in a task with from: or task: entries
  of its own, is refused. --watch follows them the same way.
• A folded task's exclude: entries no longer remove other tasks' files.
  In sources and generates, the exclusions of a task folded in by from:
  or task: apply to that task's own entries only; the referring task's own
  exclusions still apply to everything it folds in. Tasks folding a task that
  excludes files get new fingerprints and cache keys, and rebuild once.
• {{.CHECKSUM}} now covers the entries a from: or task: reference
  folds in wherever it is rendered after them: deferred commands,
  preconditions and the cache block, so a cache key now changes when only a
  referenced task's source does. Tasks with such entries get new cache keys,
  and miss the cache once; their fingerprints change too where the cache block
  embeds {{.CHECKSUM}}.
• A Jinja task with from: or task: entries renders its preconditions as
  Jinja again, instead of as Go templates.
• A cache entry now restores only the task's generated files. A poisoned
  file://, oci:// or vk entry could write any file in the project (the
  Taskfile, git hooks, other tasks' checksums) and reach outside it: a zip one
  in 4.8.0 and earlier by its names, either through a hard link already in the
  project (an oci:// one rewriting the linked file, a zip one changing its
  permissions). An entry holding anything outside the task's generates, or cached
  for another task or other sources, is now refused before anything is
  written, and the task runs instead. --import-cache still restores every
  task's files, but no restore writes into .git, or an import into the temp
  directory's tmp. Entries named with a .. component are refused, and
  restored files and directories lose their setuid, setgid and sticky bits.
• A cache entry holding a symlink out of the project is refused, unless
  the task sets cache: {outside_links: true} (for a virtualenv, say): the
  task's commands would otherwise write through a link a poisoned entry
  planted in its outputs. Links are followed through those already in the
  project, and one leading to a Taskfile or dotenv file Task read, .taskrc,
  .git (at any depth: a directory holding a nested repository too) or Task's
  temp directory is refused whatever the setting, so a task whose pnpm-style
  link points at a package holding one of these misses the cache. A task whose
  outputs hold such a link is not saved. An entry naming one file twice is
  refused. An entry whose restored files fail verification is removed again
  before the task runs, the files it replaced put back, and a restore that
  fails partway is undone the same way; if undoing fails, the task fails
  instead of running among restored files. A restore that is killed leaves
  nothing behind once the next restore runs. On Windows no symlink is restored; an
  entry holding one is a cache miss. These checks do not guard against other
  processes changing the project during a restore.