kevans91

While not receiving a response isn't ideal, I note that we actually have two secteams: secteam@ and ports-secteam@; something like luatex should go to the latter, but their level of activity has been kind of hit or miss in my experience. Curating security issues in ports is kind of hard due to the size of it and we probably more often than not end up getting hit with patching things a little after disclosure because of it.

fwiw, characterizing Andres as a sysadmin isn't really the whole picture; he's a postgres developer that conducts benchmarking operations with some frequency (and he's quite good at what he does)... he's perhaps naturally a bit more sensitive to things like the cumulative effect of 500ms or so over a number of sshd invocations.

To be fair, for the vast majority of FreeBSD users flua is essentially nonexistent; it was pushed off into /usr/libexec and renamed so that it doesn't get used by consumers of base in such a way that it can't be updated.

We (FreeBSD) should really reconcile our diff against OpenBSD and figure out what of the work I've done downstream makes sense and what doesn't. I'd imagine there's a healthy amount in both categories.

Right, in this case specifically we're running off a limited bootstack allocated in the kernel's .bss (somewhere between 2 to 6 pages, generally); we won't finish initializing VM until shortly after this sort is done (in some of the SYSINITs that we're sorting).

> [...] But if you use pkg, and the new point release added a syscall, you will have problems installing new packages (or upgrading) once the package builders update; I don't quite remember the timeline, but it's usually a few months after the point release. [...]

The previous release in the branch gets dropped after ~3 months, probably aligned to the end of the month that its EOL lands in; then pkg builders switch to the newer release in the branch.

Yes, this is great... I was given a Macbook with a Norweigan keyboard for testing a port of FreeBSD on it, and I quickly discovered that the keyboard layout remapping stuff available via the UI won't remap at least this one key to what I'd find on my US keyboard.

Race conditions in places like this are exceedingly hard to write reliable tests for. It may take one, two boots; dozens, or thousands, or you may just get insanely lucky and whatever arbitrary # boots you do to try and reproduce it was still simply not enough. It's hard to have any level of confidence, in many cases.

iocage as well... I've been trying to sucker someone into writing a new jail manager in flua, since we have that in base. It hasn't worked yet.

Not sure we have anyone that could really call themselves a maintainer for sed, but I am a FreeBSD committer that has put thought into this problem in the past.