stet 0.8.1

A malformed-font crash fix. Font data arrives embedded in a PDF or a
PostScript program, so it is attacker-controlled in the same way any PDF
object is, and the affected code shipped in every release to date.

Fixed

• A malformed CFF font no longer panics the process. The Private DICT
  operator carries [size, offset], and both were bounds-checked with
  offset + size <= data.len(). CFF permits a real-number operand wherever an
  integer is expected, and f64 as usize saturates rather than wrapping, so a
  font declaring a size of 1e49 reached that check as usize::MAX and
  overflowed the add before it could reject anything. Shipped release builds
  are affected, not only overflow-checked ones: with checks off the add wraps
  to just below the offset, the <= data.len() bound then passes, and the
  slice panics instead. Three sibling sites had the same shape: the per-FD
  Private DICT of a CID-keyed font, and both local-Subr offsets, which are
  added to their Private DICT offset. DICT operands destined for an offset or
  length are now rejected up front unless they are finite, non-negative, and
  inside what a CFF offset can address.

  Font data is attacker-controlled in the same way any PDF object is — it
  arrives embedded in a PDF or in a PostScript program — so this was reachable
  from an untrusted input. Found by the weekly fuzz job.

Changed

• Crate descriptions and keywords across all eleven published crates now name
  what distinguishes stet — pure Rust, no C dependencies, prepress-grade CMYK
  and spot colour — rather than restating the crate name. stet-pdf-reader
  was previously described as "PDF parser and renderer", five words that fit
  every PDF crate on the registry.
• The stet facade no longer describes itself as a "PDF rendering engine". It
  depends on stet-render and stet-pdf (PDF output) and carries
  stet-pdf-reader as a dev-dependency only, so it cannot read a PDF; the old
  wording promised the one thing the crate does not do. PDF reading is
  stet-pdf-reader.

Downloads

stet-<version>-x86_64-unknown-linux-musl.tar.gz is the one most people
want: statically linked, no glibc requirement, no runtime libraries, no GUI.
It is the right choice for servers, CI and containers.

The -gnu Linux build adds the desktop viewer and needs glibc 2.35 or newer
(Debian 12, Ubuntu 22.04 and later) plus X11 or Wayland and OpenGL to open a
window. Rendering to files works without them.

macOS: the binaries are unsigned, so opening a downloaded archive from
Finder trips Gatekeeper ("cannot be opened because the developer cannot be
verified"). Installing with curl avoids it entirely, because the quarantine
attribute is set by the downloading application and curl does not set one:

curl -L <asset-url> | tar xz

If you already downloaded it in a browser, clear the flag with
xattr -dr com.apple.quarantine stet.

Windows: SmartScreen will warn that the publisher is unknown; choose
More info -> Run anyway. Code signing certificates cost money and stet does
not have one.

Rendering is identical across these artifacts with one caveat: the musl
build's libm differs from glibc's in the last bits, which can shift
antialiasing coverage by a pixel or two on heavily curved PostScript
artwork (measured: 265 of 5.4M pixels on one sample, invisible in practice;
all PDF samples tested were byte-identical). Do not generate rendering
baselines with one build and compare them against another.

Verify a download against SHA256SUMS.