Solved libxml2 and apache24

K

kjpetrie

Having received security warnings for the last ten days or so about textproc/libxml2 I wondered why FreeBSD uses an unsupported version and tried to contact the maintainer, only to find the maintainer is a mailing list of which I'm not a member. Ah well, I expect I know the answer anyway - libxml2 is a library providing functions for any program which needs to process XML and there are a lot of those, so checking the compatibility of newer versions wouldn't be trivial.

In my case the library is needed by www/apache24 which seems alarming because that's an Internet-facing program and therefore particularly vulnerable to any attack. However, I then asked myself why Apache would need to parse XML. After all, it's basically a file server and its job is simply to pass a bit-for-bit copy of any file across the network. It doesn't need to understand that file or even know what that file is for, just send it as it is. So, would I be right in thinking the only reason Apache needs libxml2 is to read its own configuration files and convert the XML (or XML-like) data in those into database structures or objects?

If so, then vulnerabilities are less of a worry because the only person writing those files is the administrator, and if anyone else could alter those the system would already be so compromised a vulnerability wouldn't matter!
 
The question was why Apache needs libxml2. I wasn't raising a concern, just seeking confirmation or otherwise of my conclusion. I'm sure the maintainers are well aware of the problem and tired of people nagging.

After reading the bugzilla threads - what a hornet's nest! I'm not going in there.
 
CyberCr33p thank you for this link!!!

I recommend reading this as it is a valuable lecture, relevant not only for getting an understanding of "upstream" struggles.
The situation of FOSS-maintainers mentioned there also applies to our ports maintainers.

Struggling with PR 279705 seems to continue, as we can see commits there that has been reverted.
This is actually an interesting case in some negative sense.
 
It's not uncommon to see diizzy's commits reverted.
He(diizzy) tends to value his own opinion over the maintainer's.
(vishwin@, sunpoet@ and others in particular often disagree with him.)
 
That's quite not the case but vishwin@ tends to create a lot of fricition with various committers including procrastinating.
 
PR 287391 now shows a commit with highly interesting comments:

No, that's certainly not how it works. Upstream's recent announcement regarding security issues has nothing to do with FreeBSD ports. When we have vulnerable software in ports, it gets marked vulnerable in vuxml, period.

Hiding vulnerabilities is a disservice to our users. If there is an announcement, everybody can react the way they need to. In this case, the pressure finally made you commit the backports instead of discouraging submitters and committers who wanted to do the right thing.

It's really beyond me how two committers can be so stubbornly arguing against security fixes. There's people trying to run professional services with FreeBSD and ports/pkgs.
Click to expand...
I do think it is time calling "Houston we have a problem!" although this case may be fixed, but that certainly is not the way it should happen again.
A decent debriefing with the participants for doing better has to be done, at least that would happen in a professional environment.

And clearly speaking, fixing security vulnerabilities has to be done by following the rules in a timely manner. That has to be done in a professional attitude as there is a dark market for zero-days and delaying fixes.
 
Turns out www/mod_php83 needs it too. Ah well, at least there's a patched version on the way. Looks as if this shouldn't be used on any untrusted data, anyway, given that was never the author's intention.

PS. I assumed as OP I could lock or close this to prevent it degenerating into a flame war. If I can I can't see how.
 
kjpetrie said:
Turns out www/mod_php83 needs it too. Ah well, at least there's a patched version on the way. Looks as if this shouldn't be used on any untrusted data, anyway, given that was never the author's intention.

PS. I assumed as OP I could lock or close this to prevent it degenerating into a flame war. If I can I can't see how.
Click to expand...
I think you are only able to mark it as solved but you already did.
 
kjpetrie said:
Turns out www/mod_php83 needs it too. Ah well, at least there's a patched version on the way. Looks as if this shouldn't be used on any untrusted data, anyway, given that was never the author's intention.

PS. I assumed as OP I could lock or close this to prevent it degenerating into a flame war. If I can I can't see how.
Click to expand...
For those installing php 8.4.10 from source and not from the ports/pkgs:
update your /textproc/libxml2 port to the "latest" safe version (currently 16.0.4) and
ln -s libxml2.so.16.0.4 libxml2.so.2
before making PHP 🙄
 
You must log in or register to reply here.
Back
Top