Hello William,

On Thu, 1 Feb 2024 at 17:52, William Lallemand <wlallem...@haproxy.com> wrote:

> > I consider getrandom() a modern and simple solution to all those problems.
>
> Unfortunately this is still a fallback solution if getrandom() is not
> accessible or if the support is not built, as this is a fallback in
> openssl too.I don't want HAProxy to require getrandom() to work, even if
> this is not an ideal solution, there is no reason it shouldn't work
> without it, at least for the sake of portability.

Although freebsd has getrandom(), openbsd uses a different API and I'm
sure there are lots of other operating systems that do not provide
this API.

So yes, a single code path would have been nice, but you are right, it
isn't realistic.



> > > I'll check if we can do something like this instead of needing a explicit 
> > > option, but
> > > if that's not possible we will require GETRANDOM in the --enable-haproxy 
> > > build option.
> >
> > Actually I think wolfssl should add feature detection just like it
> > does with other optional syscalls. But that is not what the suggested
> > wolfssl 5.6.6 release does.
>
> It does not seem to be the wolfSSL philosophy :/ Everything needs to be
> compiled manually and there is a lot of options, it's quite complicated
> to obtain an optimized built... We recently saw that they've done
> something like this for AES-NI, so maybe we could try to push them to a
> more dynamic build system.

Wolfssl sure can be hard to love sometimes.


> I opened a wolfSSL issue https://github.com/wolfSSL/wolfssl/issues/7197
> feel free to participate, we could try to push them to the detection of
> getrandom() during the build of their library, and fix their urandom
> Implementation.

Yes, thank you, I will subscribe and participate.


> We could also try a call to RAND_bytes() after the chroot and exit with
> an error saying that the library is not compatible with chroot.

I definitively prefer failing fast/early, to avoid getting blindsided.


Let's see what can be improved at wolfssl.



Thank you,

Lukas

Reply via email to