On Sat, Mar 14, 2026 at 08:22:17AM -0400, Winnie Quinn wrote: > On Mar 7, 2026, at 3:26???AM, Philip Guenther <guenther gmail ! com> wrote: > > > Given what we know now, would it have been better if pledge() only > > took one argument and there was a separate pledgeexec() syscall that > > only ldd called? I'll answer with a fully qualified "maybe" > > For whatever it is worth, I find the second argument to pledge to be > extremely useful. To give one example, I use it for sandboxing Rust > development and the associated building of dependencies from crates.io. > Without it, I would have to resort to using chroot, an approach both > inconvenient (due to having to maintain the chroot) and less secure (due > to the lack of syscall filtering). It seems like the prevailing opinion > is that the second argument to pledge was a mistake,
No, the _concept_ of execpromises is not a mistake. As you've discovered, it can indeed be used to good effect. The unfortunate part is that in practice using it correctly turned out to be more difficult than anyone had assumed. Since it's implemented as part of pledge(), that lead to people seeing NULL as the second argument all over the place, and along with the previous suggestion from years ago not to use it, there was basically an unclear message as to whether it was slated for removal. I used it from time to time in programs that were only ever intended to be used internally, but always with the proviso that the code might need to be changed in the future. If the same functionality had been implemented as a separate function, there might have been less confusion and more adoption. That seems to be the prevailing opinion, not that it should be changed now or removed. > but I really hope it sticks around Same here. Although if the functionality of execpromises was separated out and implemented with it's own function, I can see how that might facilitate future development and encourage usage in new code.
