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
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
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
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.
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
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.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-01-11