From: Stuart Henderson <stu@spacehopper.org>
Subject: Re: www/anubis: add unveil(2) restrictions
To: Christoph Liebender <christoph@liebender.dev>
Cc: ports@openbsd.org
Date: Sun, 1 Jun 2025 11:58:02 +0100

On 2025/06/01 12:53, Christoph Liebender wrote:
> 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.

would be happier if you took maintainer already if adding patches like
this.