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: Accidental debug-enabled version

From: Jeffrey Walton via curl-library <>
Date: Wed, 11 Jan 2023 08:37:05 -0500

On Wed, Jan 11, 2023 at 8:25 AM Daniel Stenberg via curl-library
<> wrote:
> The other day a user submitted an issue that made it obvious to me that they
> had accidentally and unintionally built a debug-enabled libcurl and might have
> used that in production unless I had told them about and talked them out of
> it.
> A debug-enabled libcurl has debug and test code conditionally built in that
> makes it unsuitable and unwise to ship and use in production. Some of that
> test code can be made to act funny or even wrongly, most often controlled by
> simple environment variables.
> I was thinking of what we can do to make this less likely to happen without
> users being aware of exactly what is going on. Perhaps outputting a little
> warning at the top of the -V/--version output would help?
> Like this:
> $ curl -V
> WARNING: this libcurl is Debug-enabled, do not use in production
> curl 7.87.1-DEV (x86_64-pc-linux-gnu) libcurl/7.87.1-DEV OpenSSL/3.0.7
> zlib/1.2.13 brotli/1.0.9 zstd/1.5.2 c-ares/1.18.1 libidn2/2.3.3 libpsl/0.21.0
> (+libidn2/2.3.0) nghttp2/1.50.0-DEV ngtcp2/0.13.0-DEV nghttp3/0.9.0-DEV
> librtmp/2.3 libgsasl/2.2.0
> Release-Date: [unreleased]
> ...
> This warning exists as a pull-request:
> Feel free to comment here or in the PR.

I would not put it on the first line. Some folks may be parsing the
first line for a version number using something like:

     curl_version=$(curl -V | head -n 1 | cut -f 2 -d ' ')

Somewhere further down in the stack would probably be a better choice.

Received on 2023-01-11