Update with -U9999.

Would you please upload a diff with full context (-U9999)? Thanks.

Update to new libcasper version.

Hi Guys :)

Maybe what I'm about to say is blasphemy in our circles, but it looks like this tries to solve a problem that an object oriented programming language with virtual functions (C++) could easily solve. libcasper's header file would provide declarations for abstract base classes for all sorts of handles. Then there are two implementations of these classes: one that acts as a no-op and one that is actually built on top of Capsicum. That way there is no need to resort to linker tricks.

I don't really much like this approach, plus there is a high risk to have libcaspermock and libcasper out of sync

The changes proposed seem ok, in so long as it addresses the regression I reported on svn-src-all@.

@ngie Thoughts? I'd like to commit this and move on to other things, so review/approval is highly appreciated.

In D8753#181465, @oshogbo wrote:

The only situation I can think of where you would like to have two libraries is when you would install something from ports which you don't want to use Casper and your base system is using Casper.

The behavior of few functions are a little bit different libcasper and libcaspermock but this still could be merged somehow.
The only situation I can think of where you would like to have two libraries is when you would install something from ports which you don't want to use Casper and your base system is using Casper.

Why do we need a separate library for this? Why not just turn MK_CASPER=no into the equivalent of cap_enable() -> false?

Example of usage: https://reviews.freebsd.org/D8754

In D8746#181220, @cem wrote:

For local dotdot lookups in capsicum mode, I think it will be very easy to add some unit tests confirming correct behavior.

For local dotdot lookups in capsicum mode, I think it will be very easy to add some unit tests confirming correct behavior.

Fix regression when stdin/out/err fds are are overridden by shell.
Found by Kyua tests.

Guys, are we happy with the state of things? I am keen to commit it, given relevant approval is provided.

Update diff with one that survived building head@r309672:

1. buildword && buildkernel on FreeBSD 10.3-R i386
2. universe on FreeBSD 11.0-R amd64

Should have ticked 'accept'

In D8543#180755, @pawel.biernacki-gmail.com wrote:

Since dd was removed from bootstrap in 309412, can this be recommitted?

Since dd was removed from bootstrap in 309412, can this be recommitted?

As I see libcapsicum is header only https://svnweb.freebsd.org/base/head/lib/libcapsicum/Makefile?revision=306726&view=markup.
The breakage was obviously caused by lack of that header in installed system older than 12-C.

See https://reviews.freebsd.org/D8605 for one possible resolution

I think we should have a fake libcapiscim that's all defeined as no-op success functions and add that to libegacy. We don't need to install the full libcapsicim and there's ordering issues trying to do so.

Thanks for you work, but I like more your previus patch :)
So I would like to fix the problem with that patch in a little different meaner basically install libcapsicum.
I will do that today, and replay your patch.

Reopening due to dd/build toolchain issues.

Make it compile on older releases as dd is part of bootstrap and pre 12-C don't have capsicum_helpers.h installed.