On Wed, Dec 16, 2020 at 12:00:20PM -0800, Yang Zhong wrote:
> Out of the changes in my original proof-of-concept patch, I've
> submitted the most obviously self-contained ones at this point.
> There are a few small changes scattered around the code, but it
> would make sense to wait and submit them in a bigger group as
> they're all pretty much the same thing.
> 
> The rest of the substantial changes depend on FreeBSD's
> mkostempsat() function. For testing, I've written a workaround
> got_opentemp_namedat() involving two chdirs - It's ugly and not
> something that can be committed. It's also possible to keep
> using got_opentemp_named() and such, but that also adds some
> extra path-modification code around them.
 
Thanks for the overview. It is nice to know that most of your code
has now been integrated upstream as far as possible.

By the way, your proof of concept does not seem to cover any of the helper
programs in libexec/, even though those programs are the primary consumers
of untrusted data. On OpenBSD, these programs run with pledge("stdio recvfd").
Capsicum support should perhaps focus on sandboxing these helpers before
a lot more additional effort is spent on the main process. Sandboxing only
the main process does not make a lot of sense, since it is only exposed
to data which has already been parsed and marshalled across inter-process
communication pipes. Any malicious repository data will hit code in the
libexec/ directory first.

> There was discussion of adding mkostempsat to OpenBSD:
> (apologies if I'm not using email right)
> 
> On Wed, Nov 25, 2020 at 12:39 PM Todd C. Miller <Todd.Miller@sudo.ws> wrote:
> >
> > On Wed, 25 Nov 2020 14:05:28 -0500, Ed Maste wrote:
> >
> > > Some of the functionality
> > > that exists in FreeBSD comes as a natural consequence of that - e.g.
> > > mkostempsat is needed when there's no concept of "/" in the sandbox.
> > > Similarly AT_FDCWD isn't usable in the sandbox.
> >
> > FWIW, adding mkostempsat(3) to OpenBSD is trivial to do.  I have
> > no objection to adding it...
> 
> I'm not familiar with the process of making contributions to
> OpenBSD. What would it take to add mkostempsat?

Todd has already submitted a patch this in private email. I suppose Todd
is still waiting for OKs from other OpenBSD developers at the moment.

Please wait with such patches until mkostempsat() appears in OpenBSD-current.

> Also, if mkostempsat does get added, I imagine that it'll go into
> the next OpenBSD release. So, if I add changes to got that depend
> on mkostempsat, got won't be compatible with this and earlier
> versions of OpenBSD, I imagine. Is this a problem?

No, it is not.
The 'main' branch of Got only needs to compile on OpenBSD -current.
It is convenient if the branch can be built on the most recent -stable
OpenBSD release, but that is not a strict requirement.

Cheers,
Stefan