On Fri, Feb 25, 2022 at 10:52 AM Ben Walton <[email protected]> wrote: > > On Fri 25 Feb 2022, 11:39 Jeffrey Walton via users, <[email protected]> > wrote: >> >> Hi Everyone, >> >> I was looking at the libexpat recipe again. This kind of jumps out >> from >> https://sourceforge.net/p/gar/code/HEAD/tree/csw/mgar/pkg/libexpat1/trunk/Makefile#l42: >> >> # No high-entropy random in old Solaris versions >> EXTRA_CPPFLAGS += -DXML_POOR_ENTROPY >> >> Solaris has /dev/urandom. It meets requirements. As far as I know, >> even the earlier versions of the device were sufficient for >> cryptographic needs. It may be time to revisit that define. > > Yeah, I'd drop it and see that it passes the test suite. Not sure how far > back you'd need to go os and hardware worse to still need it, but arms pretty > ancient to me.
Here's some more reading on XML_POOR_ENTROPY: https://github.com/libexpat/libexpat/issues/172. It looks like libexpat needs a good random source for some hash tables. Or more specifically, to avoid collisions due to a poor entropy source. If the entropy source produces collisions, then it is considered poor. I personally think this problem should probably be addressed differently. Instead of asking users to evaluate their entropy source, I think libexpat should obtain a uniform distribution via something like operating system random source + SipHash. SipHash should produce a uniform distribution and it only requires entropy once to key the algorithm. It does not need a constant stream of bytes. Getting back to libexpat, it looks like /dev/urandom is sufficient nowadays. Also see https://github.com/libexpat/libexpat/blob/master/expat/lib/xmlparse.c#L122. You would get into trouble if the /dev/urandom device was missing. Jeff
