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
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Wed, 11 Jan 2023 08:40:10 -0500
Another option would be that building with debug creates curl-debug and
libcurl-debug (rather than curl and libcurl), which makes it really
difficult to unknowingly make this mistake.
It also handles libcurl-debug escaping into the wild and being silently
loaded by applications. And in a multi-user environment, make install
would not cause other users pain.
If you really want to use the debug version, e.g. in CI or with a
debugger, simply ln (-s) -f them to the standard names.
Anyone who does alias the debug versions to the standard ones has taken
an unobvious explicit action and can be assumed to know what they are doing.
The warning in the command tool is also a good idea, though perhaps not
on the first line. Perhaps make the version be n.m.o-DEBUG. That would
break most version parsers - which is a good thing if this is a mistake,
but easy to allow for if a script wants to deal with a debug version.
You also might consider having configure/cmake produce a warning when
DEBUG is enabled.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
On 11-Jan-23 08:24, Daniel Stenberg via curl-library wrote:
> 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.
>
Received on 2023-01-11
Date: Wed, 11 Jan 2023 08:40:10 -0500
Another option would be that building with debug creates curl-debug and
libcurl-debug (rather than curl and libcurl), which makes it really
difficult to unknowingly make this mistake.
It also handles libcurl-debug escaping into the wild and being silently
loaded by applications. And in a multi-user environment, make install
would not cause other users pain.
If you really want to use the debug version, e.g. in CI or with a
debugger, simply ln (-s) -f them to the standard names.
Anyone who does alias the debug versions to the standard ones has taken
an unobvious explicit action and can be assumed to know what they are doing.
The warning in the command tool is also a good idea, though perhaps not
on the first line. Perhaps make the version be n.m.o-DEBUG. That would
break most version parsers - which is a good thing if this is a mistake,
but easy to allow for if a script wants to deal with a debug version.
You also might consider having configure/cmake produce a warning when
DEBUG is enabled.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
On 11-Jan-23 08:24, Daniel Stenberg via curl-library wrote:
> 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.
>
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature