Developers’ Weblog

Sponsored by
HostEurope Logo

Developers’ Weblog

⚠ This page contains old, outdated, obsolete, … historic or WIP content! No warranties e.g. for correctness!

All 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

Happy Spring Equinōx to everyone!

I merged the crypto improvements to HEAD: we now have improved Rijndael CBC code for UVM swapencrypt, and this code uses the VIA C3/C7 PadLock™ ACE if existing — whose code contained a now-fixed data corruption bug.

Next on the TODO list is: make vnd(4)’s encryption use the same code if AES is chosen as cipher algorithm. Allow selection of Blowfish (stay compatible), AES-128, AES-192, AES-256; other algorithms may follow. We will need a new keyfile format and stay backwards-compatible, but this is not a problem.

We got a PUA assignment from U+F900‥F97F (tentatively) for our encoding proposal, and should use “one of the various non-characters” for the NUL encoding. But: “Emoticon U+FDD0 is actually Unicode for the eye of the basilisk…” — U+F000‥F7FF are now reserved for Linux’ straight-to-font map (and some subranges are used by Windows® and Mac), and F800‥F89F for Mac (and possibly, Linux). — Although I got scolded again for chosing a 16 bit wide character type, I believe this compromise with all its good and bad sides is the right way to go for us at the moment. As for how to codify this, I still do not have a final answer, but I think using wrappers for SUSv3 functions which cannot fully support the proposal is a good idea. Most use cases should work with the SUSv3 functions, anyway.

I still haven’t ported mksh to BSD/OS 3.1, OSF/1 V2.0 and Ultrix V4.5…

MirBSD Logo