From: Jonas 'Sortie' Termansen Subject: Re: Miscellaneous LibreSSL portability fixes To: Theo de Raadt , Theo Buehler Cc: tech@openbsd.org Date: Sat, 2 Nov 2024 20:51:25 +0100 Hi Theo & Theo, Thank you for your quick replies :) The reason I send these patches now is because I've been shipping LibreSSL as the libssl for Sortix for a decade now. My patchset is really small now and I wanted to achieve a supported operating system status where it builds out of the box. I just need to a couple one line tweaks and fix some issues on my end and I'm there. On 11/2/24 18:59, Theo Buehler wrote: > I landed this one, hopefully I'm not asked to back it out again. Thanks Theo :) In my opinion it's cleaner since the cast isn't needed and struct msghdr in OpenBSD doesn't use caddr_t either. On 11/2/24 18:59, Theo Buehler wrote: > I remember getting pushback on this last time you sent it. > > Unfortunately, it was already shot down by Theo. Another thing: %lld > doesn't work on Visual Studio C (which some of our users use), so we > would need to use PRIu64. We could consider carrying a patch in > portable for this. Oh - I'm sorry. I forgot I had sent that hunk before, it has been years. That's a really good point about Visual Studio C. Oh I wasn't even aware of the libressl-portable patches mechanism, I see it now in update.sh. That sounds like a much better solution than upstream OpenBSD. I'll propose a follow up there? On 11/2/24 18:59, Theo Buehler wrote: > It's annoying. But it's also annoying that there's no suitable portable > substitute for what we want to do. > > I'm not super keen on carrying such a patch in portable, but I expect > at some point we will need to. The reliable portable design for a 'create an unique temporary unix socket' is to have a loop generating random path names and binding until you succeed. netcat could gain such a loop to solve the race. mktemp is useful for proposing a random path name that may already be taken, which is handy for unix sockets here, and I agree it's a valid and useful use case. mktemp became obsolete in the standard because novices didn't use it safely with existence checks, and mkstemp was easier to use safely (but doesn't solve Unix sockets). mkstemp + unlink is the standard equivalent of mktemp. Yeah, my proposal is just as racy as it ever was, I actually hadn't noticed the lack of an outer loop. If you prefer the code as it was, that sounds totally good to me. :) On 11/2/24 18:09, Theo de Raadt wrote: > Where does it say this? If true the number of portability issues this > will create, adjacent to security, is assuredly non-zero. I don't believe > this to be true nor practical. POSIX.1-2024 "All of the types shall be defined as arithmetic types of an appropriate length [...] Additionally: nlink_t, uid_t, gid_t, and id_t shall be integer types." We've basically always been allowed to pick our ABI here, it's the same language allowing 64-bit time_t and off_t. I'm doing an experimental operating system to explore designs and their consequences. I will bear the full burden of my choices, review all the security implications, and I'm happy to carry the patches I need. It's totally ok that you're saying no :) I would never suggest such changes for the wider OpenBSD, only the one portable file I had issues with, and it turns out I didn't know about the patches feature. (Btw the breakage for 64-bit uid_t and gid_t has been small. It's mostly just printf issues which are caught with -Werror=format. I am unaware of any security issues so far although yes I am concerned about silent truncation.) Jonas Termansen