src VS nvi2

The OpenBSD project released 7.4 of their OS on 16 Oct 2023 as their 55th release 💫

Well since https://www.openbsd.org/ still says

> Only two remote holes in the default install, in a heck of a long time!

I'm assuming not, but I could always be mistaken.

> building a cat from scratch

> That would be an interesting project.

Here is the source code of the OpenBSD implementation of cat:

> https://github.com/openbsd/src/blob/master/bin/cat/cat.c

and here of the GNU coreutils implementation:

> https://github.com/coreutils/coreutils/blob/master/src/cat.c

Thus: I don't think building a cat from scratch or creating a tutorial about that topic is particularly hard (even though the HN audience would likely be interested in it). :-)

> I don't know how they define `MAX`, but I'm guessing it's a typical "a>b?a:b"

Indeed: https://github.com/openbsd/src/blob/master/sys/sys/param.h#L...

> Then `SYS_kbind` seems to be a signed int.

It's an untyped #define: https://github.com/openbsd/src/blob/master/sys/sys/syscall.h...

I believe your whole analysis is correct, that running an elf file with an openbsd.syscalls entry with .sysno > INT_MAX will allow an out-of-bounds write.

I can reproduce it. And this is the commit that causes the issue: https://github.com/openbsd/src/commit/d21788ce70be80e9c4ed0c52c149e01147c4a823

This doesn’t really change your conclusion, but I think that’s the wrong file. This is the real doas afaict: https://github.com/openbsd/src/blob/master/usr.bin/doas/doas...

Still just a tidy 1072 lines in that folder though.

I spent 5 minutes staring at your file trying to understand how on earth it does the things in the man page, but of course it doesn’t.

OpenBSD developers are making serious effort to kill off indirect syscalls, the base system is completely clean, take a look at the work Andrew Fresh did to adapt Perl. He write a complete syscall "dispatcher" or emulator for the Perl syscall function so that it calls the libc stubs.

https://github.com/openbsd/src/commit/312e26c80be876012ae979...

The ports tree is also being cleansed of syscall(2) usage, until they're all gone.

msyscall, pinsyscall, recent mandatory IBT/BTI, xonly. OpenBSD is making waves, but people aren't really seeing them yet.

Actually, I got it wrong, too many vulnerabilities in flight. They did fix it: https://github.com/openbsd/src/commit/375ccafb2eb77de6cf240e...

nvi2 [0]: I got to like the simplicity of nvi when installing Void Linux on my laptop, but it had some annoying bugs that made me switch to nvi2. In general, it feels like `good' software; powerful enough by virtue of being a 1:1 vi clone with a few crucial improvements (multibyte, multi-undo, etc.), but simple enough to hack on if I miss some feature. Though no autocomplete means it's not suitable for more verbose languages, like Java.

QuickJS [1]: qjscalc is my go-to scientific calculator, and qjs my go-to JavaScript implementation for simple programs. The C interface is very nice to use, too. All in all, it feels very much like a "complete" engine, even if not quite as fast as one with JIT.

w3m [2]: Somewhat lacking as a web browser, but a very good pager. Would take it over less any day. Also has the best table display of any text-mode browser, supports inline images, and is rather extensible.

Wine [3]: It's gotten so good that I no longer have to dual boot Windows. Still not perfect, but definitely on my list of "good software".

[0]: https://github.com/lichray/nvi2

[1]: https://bellard.org/quickjs/

[2]: https://github.com/tats/w3m

[3]: https://www.winehq.org/

Don't confuse OpenVi/OpenBSD-vi, nvi1, and nvi2. These are all different programs that share the same heritage.

OpenVi is derived from OpenBSD vi, which derives from nvi version 1.79, released in 1996. There has been 25+ years of independent development as part of the OpenBSD base system and has diverged greatly in that time, with the development going in a different direction.

Nvi1, currently on version 1.8x, is maintained at https://repo.or.cz/nvi.git - I believe the latest version of this editor does have multibyte support, but this is not the OpenVi/OpenBSD version of the editor.

Nvi2 shares heritage as well but also, quite far removed from the original code, is actively maintained at https://github.com/lichray/nvi2 and also includes multibyte support.

(IIRC) the multibyte support in both Nvi1 and Nvi2 derives from nvi-m17n, developed as part of the KAME project by the late itojun - http://www.itojun.org/itojun.html ... the last update to nvi-m17n was about 3 years ago, and is available at https://cgit.freebsd.org/ports/tree/editors/nvi-m17n/files

Currently, optimizing for size using link-time garbage collection with GCC 11.2 on an x86_64 glibc Linux system gives a good idea of the changes over time and the different direction these editors have taken. OpenVi is also simplified in structure and does not have the three levels of abstraction of Nvi 1.8x - there is no library interface layer.

For OpenVi, the compiled binary is 280K, and for Nvi1 (nvi-1.81.6-45-g864873d3) the compiled binary is 528K (36K for vi, 528K for libvi).

OpenVi has a single configuration standard with no dependencies beyond curses.

Nvi1 has many options beyond trace/debug ("widechar" "gtk" "motif" "threads" "perl" "tcl" "db3/4" "internal-re") - so at least 255 different build variations are possible.

(I've not yet built Nvi2 myself on Linux so I can provide an actually fair comparison yet, but I will, and I'll summarize the data in an FAQ section of the README)

Nvi1 (https://repo.or.cz/nvi.git) looks like: