Merge remote-tracking branch 'upstream/main' into vfazio-thread_get_ident

Author: vfazio

Doc/library/configparser.rst

@@ -1244,6 +1244,10 @@ ConfigParser Objects
       *space_around_delimiters* is true, delimiters between
       keys and values are surrounded by spaces.
 
+      .. versionchanged:: 3.14
+         Raises InvalidWriteError if this would write a representation which cannot
+         be accurately parsed by a future :meth:`read` call from this parser.
+
    .. note::
 
       Comments in the original configuration file are not preserved when
@@ -1459,6 +1463,17 @@ Exceptions
 
     .. versionadded:: 3.14
 
+.. exception:: InvalidWriteError
+
+   Exception raised when an attempted :meth:`ConfigParser.write` would not be parsed
+   accurately with a future :meth:`ConfigParser.read` call.
+
+   Ex: Writing a key beginning with the :attr:`ConfigParser.SECTCRE` pattern
+   would parse as a section header when read. Attempting to write this will raise
+   this exception.
+
+   .. versionadded:: 3.14
+
 .. rubric:: Footnotes
 
 .. [1] Config parsers allow for heavy customization.  If you are interested in

Doc/library/multiprocessing.rst

@@ -107,6 +107,8 @@ Contexts and start methods
 Depending on the platform, :mod:`multiprocessing` supports three ways
 to start a process.  These *start methods* are
 
+  .. _multiprocessing-start-method-spawn:
+
   *spawn*
     The parent process starts a fresh Python interpreter process.  The
     child process will only inherit those resources necessary to run
@@ -117,6 +119,8 @@ to start a process.  These *start methods* are
 
     Available on POSIX and Windows platforms.  The default on Windows and macOS.
 
+  .. _multiprocessing-start-method-fork:
+
   *fork*
     The parent process uses :func:`os.fork` to fork the Python
     interpreter.  The child process, when it begins, is effectively
@@ -137,6 +141,8 @@ to start a process.  These *start methods* are
        raise a :exc:`DeprecationWarning`. Use a different start method.
        See the :func:`os.fork` documentation for further explanation.
 
+  .. _multiprocessing-start-method-forkserver:
+
   *forkserver*
     When the program starts and selects the *forkserver* start method,
     a server process is spawned.  From then on, whenever a new process
@@ -2987,6 +2993,9 @@ Beware of replacing :data:`sys.stdin` with a "file like object"
 
     For more information, see :issue:`5155`, :issue:`5313` and :issue:`5331`
 
+.. _multiprocessing-programming-spawn:
+.. _multiprocessing-programming-forkserver:
+
 The *spawn* and *forkserver* start methods
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 

Doc/whatsnew/3.14.rst

@@ -70,6 +70,22 @@ Summary -- release highlights
 * :ref:`A new type of interpreter  <whatsnew314-tail-call>`
 
 
+Incompatible changes
+====================
+
+On platforms other than macOS and Windows, the default :ref:`start
+method <multiprocessing-start-methods>` for :mod:`multiprocessing`
+and :class:`~concurrent.futures.ProcessPoolExecutor` switches from
+*fork* to *forkserver*.
+
+See :ref:`(1) <whatsnew314-concurrent-futures-start-method>` and
+:ref:`(2) <whatsnew314-multiprocessing-start-method>` for details.
+
+If you encounter :exc:`NameError`\s or pickling errors coming out of
+:mod:`multiprocessing` or :mod:`concurrent.futures`, see the
+:ref:`forkserver restrictions <multiprocessing-programming-forkserver>`.
+
+
 New features
 ============
 
@@ -396,12 +412,26 @@ concurrent.futures
   same process) to Python code.  This is separate from the proposed API
   in :pep:`734`.
   (Contributed by Eric Snow in :gh:`124548`.)
-* The default ``ProcessPoolExecutor`` start method (see
-  :ref:`multiprocessing-start-methods`) changed from *fork* to *forkserver* on
-  platforms other than macOS & Windows. If you require the threading
-  incompatible *fork* start method you must explicitly request it by
-  supplying a *mp_context* to :class:`concurrent.futures.ProcessPoolExecutor`.
-  (Contributed by Gregory P.  Smith in :gh:`84559`.)
+
+.. _whatsnew314-concurrent-futures-start-method:
+
+* The default :class:`~concurrent.futures.ProcessPoolExecutor`
+  :ref:`start method <multiprocessing-start-methods>` changed
+  from :ref:`fork <multiprocessing-start-method-fork>` to :ref:`forkserver
+  <multiprocessing-start-method-forkserver>` on platforms other than macOS and
+  Windows where it was already :ref:`spawn <multiprocessing-start-method-spawn>`.
+
+  If the threading incompatible *fork* method is required, you must explicitly
+  request it by supplying a multiprocessing context *mp_context* to
+  :class:`~concurrent.futures.ProcessPoolExecutor`.
+
+  See :ref:`forkserver restrictions <multiprocessing-programming-forkserver>`
+  for information and differences with the *fork* method and how this change
+  may affect existing code with mutable global shared variables and/or shared
+  objects that can not be automatically :mod:`pickled <pickle>`.
+
+  (Contributed by Gregory P. Smith in :gh:`84559`.)
+
 
 contextvars
 -----------
@@ -637,18 +667,30 @@ mimetypes
 multiprocessing
 ---------------
 
-* The default start method (see :ref:`multiprocessing-start-methods`) changed
-  from *fork* to *forkserver* on platforms other than macOS & Windows where
-  it was already *spawn*. If you require the threading incompatible *fork*
-  start method you must explicitly request it using a context from
-  :func:`multiprocessing.get_context` (preferred) or change the default via
-  :func:`multiprocessing.set_start_method`.
+.. _whatsnew314-multiprocessing-start-method:
+
+* The default :ref:`start method <multiprocessing-start-methods>` changed
+  from :ref:`fork <multiprocessing-start-method-fork>` to :ref:`forkserver
+  <multiprocessing-start-method-forkserver>` on platforms other than macOS and
+  Windows where it was already :ref:`spawn <multiprocessing-start-method-spawn>`.
+
+  If the threading incompatible *fork* method is required, you must explicitly
+  request it via a context from :func:`multiprocessing.get_context` (preferred)
+  or change the default via :func:`multiprocessing.set_start_method`.
+
+  See :ref:`forkserver restrictions <multiprocessing-programming-forkserver>`
+  for information and differences with the *fork* method and how this change
+  may affect existing code with mutable global shared variables and/or shared
+  objects that can not be automatically :mod:`pickled <pickle>`.
+
   (Contributed by Gregory P. Smith in :gh:`84559`.)
+
 * :mod:`multiprocessing`'s ``"forkserver"`` start method now authenticates
   its control socket to avoid solely relying on filesystem permissions
   to restrict what other processes could cause the forkserver to spawn workers
   and run code.
   (Contributed by Gregory P. Smith for :gh:`97514`.)
+
 * The :ref:`multiprocessing proxy objects <multiprocessing-proxy_objects>`
   for *list* and *dict* types gain previously overlooked missing methods:
 

Lib/configparser.py

@@ -161,7 +161,7 @@
            "InterpolationMissingOptionError", "InterpolationSyntaxError",
            "ParsingError", "MissingSectionHeaderError",
            "MultilineContinuationError", "UnnamedSectionDisabledError",
-           "ConfigParser", "RawConfigParser",
+           "InvalidWriteError", "ConfigParser", "RawConfigParser",
            "Interpolation", "BasicInterpolation",  "ExtendedInterpolation",
            "SectionProxy", "ConverterMapping",
            "DEFAULTSECT", "MAX_INTERPOLATION_DEPTH", "UNNAMED_SECTION")
@@ -375,6 +375,14 @@ class _UnnamedSection:
     def __repr__(self):
         return "<UNNAMED_SECTION>"
 
+class InvalidWriteError(Error):
+    """Raised when attempting to write data that the parser would read back differently.
+    ex: writing a key which begins with the section header pattern would read back as a
+    new section """
+
+    def __init__(self, msg=''):
+        Error.__init__(self, msg)
+
 
 UNNAMED_SECTION = _UnnamedSection()
 
@@ -973,6 +981,7 @@ def _write_section(self, fp, section_name, section_items, delimiter, unnamed=Fal
         if not unnamed:
             fp.write("[{}]\n".format(section_name))
         for key, value in section_items:
+            self._validate_key_contents(key)
             value = self._interpolation.before_write(self, section_name, key,
                                                      value)
             if value is not None or not self._allow_no_value:
@@ -1210,6 +1219,14 @@ def _convert_to_boolean(self, value):
             raise ValueError('Not a boolean: %s' % value)
         return self.BOOLEAN_STATES[value.lower()]
 
+    def _validate_key_contents(self, key):
+        """Raises an InvalidWriteError for any keys containing
+        delimiters or that match the section header pattern"""
+        if re.match(self.SECTCRE, key):
+            raise InvalidWriteError("Cannot write keys matching section pattern")
+        if any(delim in key for delim in self._delimiters):
+            raise InvalidWriteError("Cannot write key that contains delimiters")
+
     def _validate_value_types(self, *, section="", option="", value=""):
         """Raises a TypeError for illegal non-string values.
 

Lib/test/test_configparser.py

@@ -2192,6 +2192,30 @@ def test_multiple_configs(self):
         self.assertEqual('2', cfg[configparser.UNNAMED_SECTION]['b'])
 
 
+class InvalidInputTestCase(unittest.TestCase):
+    """Tests for issue #65697, where configparser will write configs
+    it parses back differently. Ex: keys containing delimiters or
+    matching the section pattern"""
+
+    def test_delimiter_in_key(self):
+        cfg = configparser.ConfigParser(delimiters=('='))
+        cfg.add_section('section1')
+        cfg.set('section1', 'a=b', 'c')
+        output = io.StringIO()
+        with self.assertRaises(configparser.InvalidWriteError):
+            cfg.write(output)
+        output.close()
+
+    def test_section_bracket_in_key(self):
+        cfg = configparser.ConfigParser()
+        cfg.add_section('section1')
+        cfg.set('section1', '[this parses back as a section]', 'foo')
+        output = io.StringIO()
+        with self.assertRaises(configparser.InvalidWriteError):
+            cfg.write(output)
+        output.close()
+
+
 class MiscTestCase(unittest.TestCase):
     def test__all__(self):
         support.check__all__(self, configparser, not_exported={"Error"})

Misc/NEWS.d/next/Library/2025-02-21-20-22-45.gh-issue-65697.BLxt6y.rst

@@ -0,0 +1 @@
+stdlib configparser will now attempt to validate that keys it writes will not result in file corruption (creating a file unable to be accurately parsed by a future read() call from the same parser). Attempting a corrupting write() will raise an InvalidWriteError.