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.