PEP 819: Add information about duplicate keys and integer parsing

Update the PEP to clarify that integers and floats should be serialized to strings,
and specify that when there are duplicate keys the second key wins in a JSON object.

Author: emmatyping

peps/pep-0819.rst

@@ -235,6 +235,40 @@ JSON schema for wheel metadata has been produced.
 This schema will be updated with each revision to the wheel metadata
 specification. The schema is available in :ref:`0819-wheel-json-schema`.
 
+Handling of Integer and Float Values in JSON Package Metadata
+-------------------------------------------------------------
+
+While no core metadata or wheel metadata values are currently encoded as
+integers or floats, when decoding a JSON file, integer and float values should
+be decoded as strings for both core metadata and wheel metadata. This is to
+avoid compatibility issues due to differences in precision and representation
+of integers and floats between languages and parsers. This also mitigates a
+security risk with integer parsing denial of service attacks based on
+`CVE-2020-10735 <https://github.com/advisories/GHSA-6jr7-xr67-mgxw>`__.
+
+If a future field of core metadata or wheel metadata needs to be encoded as an
+integer or float, the field MUST be decoded lazily after loading the JSON
+document. This minimizes the risks of denial of service attacks by minimizing
+the integer parsing allowed during the deserialization process.
+
+If using the Python :mod:`!json` module, parsing integers and floats as strings
+can be accomplished by setting the ``parse_int`` and ``parse_float``
+keyword arguments to :func:`json.load` or :func:`json.loads` to :class:`str`.
+
+Handling of Duplicate Keys in JSON Package Metadata
+---------------------------------------------------
+
+JSON does not define semantics for duplicate keys in a JSON document. However,
+different parsers treat duplicate keys differently. Tools SHOULD NOT generate
+duplicate keys in JSON package metadata. However, it is likely duplicate keys
+may be generated anyway, so tools consuming JSON package metadata should handle
+duplicate keys gracefully. In the interest of compatibility and matching the
+behavior of the Python :mod:`!json` module, if duplicate keys are encountered,
+the second duplicate key should be used as the data for that key. This matches
+the behavior of many JSON parsers such as those in Python, Rust, Go, and the
+ECMAScript Standard. Tools MAY warn about duplicate keys in JSON package
+metadata.
+
 Deprecation of the ``METADATA``, ``PKG-INFO``, and ``WHEEL`` Files
 ------------------------------------------------------------------
 
@@ -272,25 +306,13 @@ or ``WHEEL`` files.
 Security Implications
 =====================
 
-One attack vector with JSON encoded core metadata is if the JSON payload is
-designed to consume excessive memory or CPU resources in a denial of service
-(DoS) attack. While this attack is not likely to affect users whom can cancel
-resource-intensive interactive operations, it may be an issue for package
-indexes.
-
-There are several mitigations that can be made to prevent this:
-
-#. The length of the JSON payload can be restricted to a reasonable size.
-#. The reader may use a :class:`~json.JSONDecoder` to omit parsing :class:`int`
-   and :class:`float` values to avoid quadratic number parsing time complexity
-   attacks.
-#. I plan to contribute a change to :class:`~json.JSONDecoder` in Python
-   3.15+ that will allow it to be configured to restrict the nesting of JSON
-   payloads to a reasonable depth. Core metadata currently has a maximum depth
-   of 2 to encode mapping and list fields.
-
-With these mitigations in place, concerns about denial of service attacks with
-JSON encoded core metadata are minimal.
+JSON encoded core metadata and wheel metadata have the potential for a denial
+of service attack due to the quadratic parsing time complexity of parsing of
+integers. This PEP mitigates this risk by requiring that integers and floats be
+parsed as strings, and only lazily parsed into integers or floats after the
+initial deserialization of the JSON document. With these mitigations in place,
+concerns about denial of service attacks with JSON encoded package metadata are
+considered minimal.
 
 
 Reference Implementation