Am 20.05.25 um 19:27 schrieb Christoph Liebender:
Am 19.05.25 um 19:48 schrieb Omar Polo:
Usually we try to keep these kind of changes local to the ports tree
because upstream may not care and then it could break easily. However,
in golang this is a bit weird to do. So, you already have Unveil in
golang.org/x/sys, which is a "indirect" dependency of anubis, but
relying on it could break if future release stops depending on it. On
the other hand, i don't think we have a way to add a dependency to an
existing go project for the build.
www/anubis builds from a vendored tarball anyway so manually adding a go
module would probably complicate the Makefile even more. Getting
go.port.mk to build with this vendored tarball was already complicated
enough, imho.
second thing, the usage pattern of unveil is thought to be along the
lines of
if (unveil(path, perm) == -1)
err(1, "unveil");
and your unveil binding is lacking the error checking. I think you
should bubble up the errors returned by unveil(2) and call log.Fatal if
they fail, as upstream already does for other failing points.
Yes, it makes sense to be pedantic about unveil calls failing. After
all, it indicates misconfiguration to the user early on when starting
the daemon. I've attached an updated diff.
- Christoph
Ping! Anyone else interested in reviewing/testing this patch? I consider
stepping up as MAINTAINER for anubis after this patch is applied.
