• Align neo4j.conf patch with previous patch.
• Put databases in /var/db instead of $PREFIX/share.

• Update to use ${PREFIX}/etc as requested.

Ok, that's fair enough: I'll check to make sure that this will work with config files in ${PREFIX}/etc. What is your view on the weird ${PREFIX}/libexec/bin/neo4j-* path with symlinks to /usr/local/bin? My patch (or at least my local version that I've since hacked up some more!) puts cypher-shell, neo4j-admin, etc., into ${PREFIX}/bin and avoids the symlinks entirely. I think this sounds compatible with your view?

Actually, we can simplify a lot of this patching if we follow the Neo4j convention of putting config stuff in somewhere like /usr/local/neo4j/conf instead of /usr/local/etc... thoughts?

Some very small nits on which I would happily defer (well, except for the spelling one). Otherwise LGTM.

• Restore tabs to print_args().

In D10751#223329, @kib wrote:

For new functions in rtld, I use normal style(9), so rtld slowly migrates to proper indentation. For smaller changes to existing functions I do follow existing style of 4 spaces indent/2 spaces continuation.

• Add a missing rtld_strerror()
• Convert some _rtld_error() calls to rtld_printf().
• Use four spaces for second-level indent.
• Be clear about user- vs path-derived descriptor.

• Remove some superfluous parentheses.
• Remove redundant fstat(2) call.

LGTM. I'm also happy to fix this upstream: what should the Python shebang line be instead of #!/usr/bin/env python?

Ok, I think I've addressed all of these points now. I suppose that my use of strncmp comes from... my fingers just don't want to type functions that start with strc? :) Anyhow, I've changed all of the strncmp to strcmp and strnlen to strlen as you've asked.

• Address comments in kib's review.

• Fix argv/environ/aux shift calculations.

• Drop unnecessary defensive braces.

In D10751#222929, @jonathan wrote:

• Merge 'origin/master' into arcpatch-D10751

• Merge 'origin/master' into arcpatch-D10751

• Apply a style(9) fix.

• Remove a stray (debug) utrace(2) invocation.

• Add more explicit argument parsing to rtld.
• Merge remote-tracking branch 'origin/master' into arcpatch-D10751

In D10751#222729, @kib wrote:

I do not like these argv0 tricks, I intend to implement normal options parsing for the direct mode. One of the options would take the file descriptor number and do what your trick does. I think that this is better than the trick since it allows to easily invoke and test the functionality from the shell.

I've just opened D10751 as a more rtld-centric way of achieving (hopefully) the same effect, now that D10701 has landed and ld-elf.so.1 is directly executable.

In D9030#222200, @kib wrote:

But important point is that new syscall extends kernel ABI, and by its nature, this change is with us forever. If we start consider the approach wrong and better approach emerges, we still must maintain the syscall, due to the backward compatibility guarantees.

In D9030#221824, @kib wrote:

What is slightly less obvious is how to pass the binary to ld.so, but: ELF format specified a way to run binaries by filedescriptor for long time. Look at the AT_EXECFD aux vector, we still have this code in rtld.c (it might somewhat rotten, but this is easily fixable). Then the standalone-runnable ld.so only needs to grow an option to specify which fd points to the binary, in addition to AT_EXECFD.

• Don't honour setuid/setgid with custom interpreter.

• Don't honour setuid/setgid with custom interpreter.

In D9030#221740, @kib wrote:

Let's split two things. I thought that your issue at hand was the conflict between the nature of capability mode disallowing implicit root and absolute lookups, badly interfering with the typical absolute path specification for ELF interpreters.

In D9030#221707, @kib wrote:

As is, the thing is unbelievable security hole. Unprivileged user can execute suid binary with arbitrary code injected instead of official interpreter. Even for the static suid binary, it seems. Please correct me.

In D9030#221693, @brooks wrote:

FWIW, I'm not a fan of the NULL terminated argv and envv arguments as they make argument validation in CheriABI harder, but I mostly think that ship has sailed. If I were to fix it I'd make the syscall a into a __ffexecve() that takes lengths and have ffexecve() be a user space wrapper that counts the lengths of the vectors and passes them down.

• Disable ffexecve(2) with non-ELF image activators.

• Merge 'origin/master' into arcpatch-D9030
• Add !have_interp for consistency.
• Rename fldexec to ffexecve.
• Add ffexecve to execve(2) man page.

LGTM

Some of these questions may not make sense to those thoroughly versed in DTrace, but I'm new in this corner of the world. :)

• Fix MLINKS for fldexec.

Rebase onto -CURRENT

• Remove auto-generated files from diff.

usbconfig output is here: http://pastebin.com/iqJix3h2

I think this might address all of the comments properly now?

• New port: devel/llbuild
• Change post-stage to post-install for docs.
• Fix typo: "swift-llbuild", not "switch-llbuild"!
• Add the llbuild binary to the build and plist.
• Fix licensing: use ports' multi-license support.

• Fix typo: "swift-llbuild", not "switch-llbuild"!

• Change post-stage to post-install for docs.

Thanks for the comments: I think I've managed to address them.

• Add {BC,LL}OBJS to bsd.lib.mk's CLEANFILES.
• Remove redundant C++/non-C++ logic.
• Improve whitespace consistency.

The distinction between .bc and .bco was actually purposeful. The next step in the process is to add IR build rules for whole programs, and then we might end up with conflicts between the IR file that's analogous to cp.o and the IR file that's analogous to the cp binary (i.e., the result of llvm-link). So, we used .bco as the bitcode suffix that's analogous to .o (much like .pico is the PIC suffix for .o files).

This is a much simpler change after rS307075. How does it look to everyone now?

Looks like a good idea to me. Perhaps it's worthy of a comment explaining why we use abort() within a library? It could contain the same text as at the top of this review, but it might be a slightly surprising thing to discover if you haven't been party to the review.

Rework this change based on rS307075 (suffix rule files).

• Merge 'origin/master' into arcpatch-D6805

A fairly cursory look didn't turn up any obvious problems for me, but I would like to take a deeper look over the next few days.

Thanks for responding... sounds like a tough problem until we make the leap to Python 3.

Indeed, I did have that exp-run done:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210331

Not that we're well clear of code freezes on -CURRENT (and I think that I've addressed @bdrewery's comments), are folks ok with me committing this?

Very nice.

LGTM

Looks good to me in principle; see inline comment above.

I think that these are all fine to make readable, for the same reason that the hostname is ok: allowing information to "leak" in a way that enables more software to use Capsicum sandboxing is a net win. If we wanted to obscure the host UUID then we should also be hiding anything that could be used to identify the machine, which seems distinctly unhelpful in our overall goal of World Domination (tm).

In D8000#165698, @rwatson wrote:

I'm fine with exposing the hostname here -- the goal of Capsicum has always been to be pragmatic about getting software running where it doesn't violate isolation properties. You could argue that this is an information leak and/or might cause problems for deterministic replay-style applications of Capsicum -- but I'd rather we had more code working in a sandboxing. :-)

Agreed: this change makes perfect sense to me after rS305756.

• Simplify {BUILD,RUN}_DEPENDS.

• Remove superfluous GH_PROJECT variable.
• Move GitHub details to below LIB_DEPENDS.
• Clean up COMMENT to satisfy portlint -A.
• Change pkg-plist to PLIST_FILES.

I think I'd be more comfortable if the bug fixes were committed separately from the Capsicum changes (making everything easier to upstream?) and if the Capsicum-specific stuff could be refactored out as much as possible to reduce the in-line #ifdef content. In particular, it would be nice if there could be struct sandbox or the like to capture all of the additional state required by Capsicum, and the contents of that structure could be different on FreeBSD, OpenBSD, etc. If there were a function called start_sandbox(struct sandbox *sbp) or the like, possibly together with a set_flags(int fd, struct sandbox *) or something, it would allow a nice, fair comparison between the Capsicum and Pledge LoC.

In D7773#164148, @cem wrote:

I'm not a fan of introducing additional forks into otherwise straightforward programs. I think we might introduce more bugs that way than we mitigate with capsicum. I'd rather just allocate a list or array and preopen all inputs.

Updated port to Fix All The Things (TM)