Quoting Dragan FOSS (dragan.foss@???):

> Actually (and TBH..), this is a bug in libidn2, which isn't in
> systemd source tree...at least for now ;>

So, one thing to bear in mind about ElReg is that it's very much a
clickbait site, whose stock-in-trade is pumping up controversy and
scandal out of (usually) rather little. So, they often play fast and
loose with the truth, and people really should please _not_ expect them
to be a reputable IT news outlet, because they just aren't.

It appears they're also thin-skinned about that: An ElReg editor
rejected my comment, with a complaint back to me in e-mail by ElReg
editor Chris Williams claiming the story _did_ make clear the bug isn't
within systemd. (Dng thread readers and those who read the ElReg story
got the impression they were saying it was a systemd bug, right? I
did.)

Subject: Actually, this isn't a systemd bug, for a change.

Author Chirgwin did not bother to check basic facts. It turns out the
error is in the GNU IDN (internationalised domain name) library
'libidn2', which systemd's sometimes-installed-but-optional
systems-resolved component will use if the library exists. Note that the
recommended workaround was to recompile systems-resolved to ignore
libidn2.

Now, it's their feedback forum, and if they really insist on selectively
suppressing critics, that's their privilege, but IMO it doesn't reflect
credit on them.

To be fair, as Mr. Williams says to me in his private mail, the article does
mention (five paragraphs down) that the problem got isolated down to
libidn2, but nowhere says libidn2 isn't a systemd lib, and meanwhile the
story's headline and opening paragraphs suggested systemd as root cause.