Libxml2's "no security embargoes" policy

Original Article ↗ Hacker News Discussion ↗

Reliance on libxml2 and maintenance reality

  • Commenters are alarmed that libxml2/libxslt, used in multi‑billion‑dollar products and OSes, are effectively solo‑maintained passion projects.
  • Some argue the real problem isn’t libxml2’s intrinsic “quality” but that corporations built critical infrastructure atop what are essentially hobby projects.
  • Others push back on framing libxml2 as “not production quality,” saying it works fine for most use and that browser/OS‑scale, internet‑facing security is a special case.

Corporate responsibility and funding

  • Strong sentiment that large companies (Apple, Google, Microsoft, banks, etc.) relying on libxml2 should fund maintenance instead of pushing security workload onto volunteers.
  • Suggestions include: direct sponsorships, support contracts, or companies effectively becoming upstream maintainers.
  • Counterpoint: coordination among many companies is hard; some see taxes/government funding for core OSS as more realistic, others reject that as “subsidizing bad business models.”

Licensing, “freeloading,” and expectations

  • Debate over whether permissive licensing (MIT/BSD) invites exactly this outcome and whether GPL/AGPL would deter corporate free‑riding.
  • Others note GPL doesn’t help with internal use and doesn’t solve the need for paid maintainers.
  • Some maintainers openly say they don’t care if corporations can’t use their GPL‑licensed code; they prioritize individuals and fair reciprocity.

Security reports, CVEs, and DoS severity

  • Many complain about “CVE inflation”: unreachable bugs, null derefs on malloc failure, panics, regex DoS, and obscure APIs all being labeled high‑severity.
  • Maintainers describe these reports as noisy, often lacking PoCs or patches, and primarily serving security vendors’ reputations.
  • Others emphasize that availability is part of security (CIA triad), and DoS can be life‑critical in contexts like healthcare or banking.
  • Several argue severity is highly context‑dependent and that worst‑case CVSS scoring plus compliance tooling creates busywork and drowns out truly critical issues.

Embargoes vs. full disclosure

  • Many support libxml2’s “no embargo” stance: treat security bugs like any other bug, public from the start, fixed when time/patches exist.
  • Rationale: embargoes impose schedules and expectations inappropriate for unpaid volunteers and largely benefit security firms and large vendors.

Roles and boundaries: maintainers vs users

  • Strong view that unpaid maintainers owe users nothing beyond the licensed code; “patch or payment or fork it yourself” is seen as reasonable.
  • Others stress emotional investment and social pressure make it hard for maintainers to simply say no, leading to burnout.
  • Some suggest explicit MAINTENANCE-TERMS documents stating: what is supported, how security is handled, and that low‑priority issues require patches or funding.