CURLOPT_COOKIEFILE: insist on "" for enable-without-file

The former way that also suggested using a non-existing file to just
enable the cookie engine could lead to developers maybe a bit carelessly
guessing a file name that will not exist, and then in a future due to
circumstances, such a file could be made to exist and then accidentally
libcurl would read cookies not actually meant to.

Reported-by: Trail of bits
Closes #9654

diff --git a/docs/libcurl/opts/CURLOPT_COOKIEFILE.3 b/docs/libcurl/opts/CURLOPT_COOKIEFILE.3
index d6615352b8544870da8d64c9a78248bb8de1ae81..df38946f6fff40338455e40d3a8ef2e789a7dd23 100644 (file)
--- a/docs/libcurl/opts/CURLOPT_COOKIEFILE.3
+++ b/docs/libcurl/opts/CURLOPT_COOKIEFILE.3
@@ -40,10 +40,9 @@ headers (Set-Cookie style) dumped to a file.
 It also enables the cookie engine, making libcurl parse and send cookies on
 subsequent requests with this handle.
 
-Given an empty or non-existing file or by passing the empty string ("") to
-this option, you can enable the cookie engine without reading any initial
-cookies. If you tell libcurl the file name is "-" (just a single minus sign),
-libcurl will instead read from stdin.
+By passing the empty string ("") to this option, you enable the cookie engine
+without reading any initial cookies. If you tell libcurl the file name is "-"
+(just a single minus sign), libcurl will instead read from stdin.
 
 This option only \fBreads\fP cookies. To make libcurl write cookies to file,
 see \fICURLOPT_COOKIEJAR(3)\fP.
@@ -61,6 +60,11 @@ option.
 
 Setting this option to NULL will (since 7.77.0) explicitly disable the cookie
 engine and clear the list of files to read cookies from.
+.SH SECURITY
+This document previously mentioned how specifying a non-existing file can also
+enable the cookie engine. While true, we strongly advice against using that
+method as it is too hard to be sure what files will stay that way in the long
+run.
 .SH DEFAULT
 NULL
 .SH PROTOCOLS