Download
Browse source Changelog
Documentation
Project   Bug Bounty   Help us   Known bugs   TODO Protocols   CA bundle   HTTP Cookies   HTTP/2   SSL Certs Releases   Security   Version numbers   Vulnerabilities curl tool   man page   Tutorial   HTTP scripting Who and Why
libcurl
ABI API Competitors Examples Features Mailing list Related libs Using libcurl Tutorial Testimonials
Get Help
curl-library curl-users Mailing lists Book: Everything curl Video presentations Report a bug Paid support
Development
Autobuilds Code review Code style Contribute Dashboard Deprecate Internals Release Notes Release Procedure Roadmap Run Tests Security Process Specifications Test curl
News
Changelog Release table
curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Considering a version 8 at some point...

From: Kamil Dudka via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 02 Jul 2020 12:34:45 +0200

On Wednesday, July 1, 2020 5:46:53 PM CEST Dan Fandrich via curl-library wrote:
> Maybe some of the distros maintaining their own LTS branches of curl would
> sponsor such a branch? Right now, there are several people in your shoes,
> doing the same difficult job of backporting security fixes using several
> curl releases as a baseline. Pooling resources would mean less work for
> everyone.

If there is an LTS upstream branch forked off the upstream release that our
packages are based on, I will be happy to push my backports to the upstream
LTS branch first and pick them from there. It might be not so easy while
fixing embargoed security issues but we have the same problem in the master
branch already.

> The big downside is the lack of choice on the baseline version to use as an
> LTS branch. RHEL and Ubuntu releases (for example) are based on whatever
> Fedora or Debian happen to have in their repos at the time the LTS release
> is cut. Switching libcurl to an LTS branch that might be a year or two
> older would be pretty disruptive.

Yes, we cannot easily adapt to the schedule of our competitors because we
need to take into account the schedule of our layered products, beta testing
done by our customers, etc.

We would also need to discuss at upstream what to fix in the LTS branch and
what not. A fix that is necessary for Red Hat's business might be useless
and risky for users of Ubuntu LTS, or vice versa. Consequently, some fixes
would have to be applied at distribution level anyway.

Kamil

> Maybe a better approach would be to get some embedded users to sponsor an
> LTS branch, since they usually have more flexibility in what version they
> choose for their products. That also might not be so straightforward either
> since, in my experience, most embedded companies don't really care much
> about security. But, it might work if only a handful of companies pony up.
>
> Dan

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-07-02