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.
No comments:
Post a Comment