libexpat and XML_POOR_ENTROPY

Jeffrey Walton noloader at gmail.com
Sat Feb 26 20:14:02 CET 2022


On Fri, Feb 25, 2022 at 10:52 AM Ben Walton <bwalton at opencsw.org> wrote:
>
> On Fri 25 Feb 2022, 11:39 Jeffrey Walton via users, <users at lists.opencsw.org> 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


More information about the users mailing list