On Wed, Jan 11, 2023 at 8:25 AM Daniel Stenberg via curl-library
<curl-library@lists.haxx.se> 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: https://github.com/curl/curl/pull/10278
>
> 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.
Jeff
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
