Re: git: dceb46fc8a6e - main - textproc/libxml2, textproc/libxslt: vulnerable

Am 14.07.25 um 09:01 schrieb Kevin Bowling:
> On Sun, Jul 13, 2025 at 10:25 AM Michael Osipov <michaelo@freebsd.org> wrote:
>>
>> On 2025-07-12 11:13, Matthias Andree wrote:
>>> The branch main has been updated by mandree:
>>>
>>> URL: https://cgit.FreeBSD.org/ports/commit/?id=dceb46fc8a6eea281dbafc46e6452a9d82550b09
>>>
>>> commit dceb46fc8a6eea281dbafc46e6452a9d82550b09
>>> Author:     Matthias Andree <mandree@FreeBSD.org>
>>> AuthorDate: 2025-07-12 09:10:11 +0000
>>> Commit:     Matthias Andree <mandree@FreeBSD.org>
>>> CommitDate: 2025-07-12 09:13:36 +0000
>>>
>>>       textproc/libxml2, textproc/libxslt: vulnerable
>>>
>>>       Note that libxslt is vulnerable, unfixed, and without maintainer.
>>>       Two of four vulnerabilities have been fixed.
>>>
>>>       Note that libxml2 in our ports is vulnerable and there is no upstream
>>>       release fixing these bugs, they need cherry-picks.
>>
>> Let me get this straight: If the port is not fixed within the next two
>> months you are going to remove it from the tree? Looking at the reverse
>> dependency tree in FreshPorts that would be devastating...
> 
> This would, humorously, have the effect of deadening VuXML itself.
> 
>> Is this your intention?
>>
>> Michael

The idea is of course that people are very aware we're on a time bomb. 
I managed to get the attention of two persons at least.

The problem around libxslt and xsltproc having no maintainer is real and 
there are several potential solutions to it:

- downstreams avoid it and move to use a different XSL processor.

- someone, possibly with a commercial backing and under public scrutiny, 
becomes the new maintainer.  We don't want a fake maintainer who has a 
hidden agenda involving backdoors and other exploits though

- libxslt and other code has apparently had use-after-free style memory 
handling bugs in the past.  We don't know yet what's in the two 
undisclosed bugs (see GNOME releng's wiki page link from the commit, 
issues #144 or #148).  We don't know if it's a backdoor that needs to be 
removed, if it's a harmless bug, or something enabling data theft or 
code injection in typical use cases.

At least we'll not be in a situation that can be rephrased as "we knew 
but didn't tell you".

Whether we'll pull the plug or extend deadlines or something will bring 
xsltproc/libxslt back to life, is a separate discussion that also a few 
hundred people will need to make and be part of.  Upstream maintainers, 
port maintainers, whoever else.


The take-home message #1 is, you can't just write your code and use a 
library in it, you're also responsible for the library you chose because 
that's what you end up executing.

Take home message #2 is, "act now", before exploits become widespread.

-- 
Matthias Andree
FreeBSD ports committer