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.

Accidental debug-enabled version

From: Daniel Stenberg via curl-library <>
Date: Wed, 11 Jan 2023 14:24:57 +0100 (CET)

Hi team,

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

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.

  | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features
Received on 2023-01-11