It is very hard to respond to such a long message including so many
points and various inaccuracies. You should try implementing your ideas
in smaller pieces and focus on real world cases (an actual exploit
rather than fragments of possibilities could help you make your point).
However one fundamental part not mentioned is pledge() has a promise
"prot_exec". Can ffmpeg or other programs using those libraries be
pledged with a set of promises that does not include "prot_exec"?
On Thu, Jul 02, 2026 at 02:27:32AM +0000, nibletz wrote:
[...]
> 5. Codec Library Information Leak Hardening and Ports-Wide Pledge Coverage
[...]
> - Audit ports that process untrusted network or file input for pledge/unveil
> coverage, prioritizing media decoders, parsers, and network-facing daemons
Yes, please do help. By my count 1.4% of ports are currently pledged.
There are definitely more that could use it.
> - Track pledge/unveil coverage as a documented property of each port, similar
> to how WANTLIB or other port metadata is tracked, so coverage gaps are
> visible rather than implicit
I spent some time making sure the pledge() comments in Makefiles are
(reasonably) accurate, while that could be improved it does mean the data is
available:
find /usr/ports -name Makefile | xargs grep -li '^# uses pledge'
> 23. Sandboxed Multi-Process Architecture for Media Processing
[...]
This is something that is possible for the application to do itself and
obviously web browsers already do something like this (although in many
cases browsers have "prot_exec" because of JIT, there are likely
improvements that could be considered there too).
> 27. Implementation Priorities
[...]
> 6. Ports-Wide Pledge Coverage and Sandboxing (Items 5, 23)
I don't know how you decided that's sixth, when you say:
> - Addresses the structural gap that makes the rest of the chain possible
