OSS-Fuzz: no maintainer receives findings; project metadata points at the old repo

[Goldziher]

ttf-parser has been a live OSS-Fuzz project since google/oss-fuzz#12663 merged in January 2025, and the build is green. This repository was never told, and the project metadata has three problems. Filing so it is tracked rather than lost.

Current google/oss-fuzz/projects/ttf-parser/project.yaml:

homepage: "https://github.com/RazrFalcon/ttf-parser"
main_repo: "https://github.com/RazrFalcon/ttf-parser.git"
language: rust
sanitizers:
  - address
fuzzing_engines:
  - libfuzzer
vendor_ccs:
- "david@adalogics.com"
- "arthur.chan@adalogics.com"
- "fuzzing@fuchsia.dev"

1. No maintainer receives findings. There is no primary_contact and no auto_ccs. OSS-Fuzz bug trackers are access-restricted to listed contacts for the 90-day embargo, so no ttf-parser maintainer can read reports against a crate with 92.9M downloads. This is the item that actually matters.

2. Stale repository URLs. homepage and main_repo point at RazrFalcon/ttf-parser. The clone still works through GitHub's redirect, but a stale main_repo degrades OSS-Fuzz's commit-range bisection when it tries to attribute a regression.

3. The fuzz targets are vendored in oss-fuzz. The Dockerfile ends with COPY fuzz $SRC/ttf-parser/fuzz, which overwrites anything the clone provides. That is why #179 — which added a fuzz/ crate here — could not have taken effect, and why it was closed.

Fixing 1 and 2 is a small PR against google/oss-fuzz and needs only a maintainer email address. Fixing 3 means dropping the COPY fuzz line and the vendored tree there, then landing the targets here so this repo becomes authoritative; that ordering avoids a window where $SRC/ttf-parser/fuzz does not exist.

Related: #179 (closed), and testing-tools/ttf-fuzz, which has not compiled since 0.8.0 and should be deleted once a replacement lands.

[arthurscchan]

@Goldziher No problem at all. I will make some discussion with my colleagues on OSS-Fuzz works and see how I could help on this.