Re: Accidental debug-enabled version
On Wed, 11 Jan 2023, Dan Fandrich via curl-library wrote: Writing the same thing as the first line of -v output would double the chance it's actually seen. The PR has been updated to this effect now. -- / 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.html
Re: Accidental debug-enabled version
On Wed, 11 Jan 2023, Kamil Dudka wrote: Unless someone uses `curl -V 2>&1 | grep ...` like curl's autoconf test did it with GCC: https://github.com/curl/curl/commit/curl-7_49_1-45-gb2dcf0347 If they do then they, like us, will learn that it is wrong! =) -- / 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.html
Re: Accidental debug-enabled version
On Wed, Jan 11, 2023 at 02:24:57PM +0100, Daniel Stenberg via curl-library wrote: > Like this: > > $ curl -V > WARNING: this libcurl is Debug-enabled, do not use in production Writing the same thing as the first line of -v output would double the chance it's actually seen. -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Accidental debug-enabled version
On Wednesday, January 11, 2023 2:39:47 PM CET Daniel Stenberg via curl-library wrote: > On Wed, 11 Jan 2023, Jeffrey Walton wrote: > > > 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. > > Good point. We could also consider making the first two lines get sent to > stderr, as it gives the same visual but the command line you show here would > work... Unless someone uses `curl -V 2>&1 | grep ...` like curl's autoconf test did it with GCC: https://github.com/curl/curl/commit/curl-7_49_1-45-gb2dcf0347 Kamil -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Accidental debug-enabled version
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. OpenPGP_signature Description: OpenPGP digital signature -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Accidental debug-enabled version
On Wed, 11 Jan 2023, Jeffrey Walton wrote: 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. Good point. We could also consider making the first two lines get sent to stderr, as it gives the same visual but the command line you show here would work... -- / 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.html
Re: Accidental debug-enabled version
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: 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
Accidental debug-enabled version
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.html
