Quoting Dragan FOSS ([email protected]): > 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. _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
