@@ -240,18 +240,17 @@ The .dist-info directory
240240 secure hashes. Unlike PEP 376, every file except RECORD, which
241241 cannot contain a hash of itself, must include its hash. The hash
242242 algorithm must be sha256 or better; specifically, md5 and sha1 are
243- not permitted, as signed wheel files rely on the strong hashes in
244- RECORD to validate the integrity of the archive.
243+ not permitted.
245244#. PEP 376's INSTALLER and REQUESTED are not included in the archive.
246- #. RECORD.jws is used for digital signatures . It is not mentioned in
247- RECORD.
248- #. RECORD.p7s is allowed as a courtesy to anyone who would prefer to
249- use S/MIME signatures to secure their wheel files. It is not
250- mentioned in RECORD .
245+ #. RECORD.jws and RECORD.p7s are deprecated . Where they are still
246+ used, neither RECORD.jws nor RECORD.p7s are mentioned in RECORD.
247+ Build backends and other tools must not add them to wheels anymore,
248+ installers should be aware that these files may still be part of
249+ some wheels .
251250#. During extraction, wheel installers verify all the hashes in RECORD
252- against the file contents. Apart from RECORD and its signatures,
253- installation will fail if any file in the archive is not both
254- mentioned and correctly hashed in RECORD.
251+ against the file contents. Apart from RECORD, RECORD.jws and
252+ RECORD.p7s, installation will fail if any file in the archive is not
253+ both mentioned and correctly hashed in RECORD.
255254
256255Subdirectories in :file: `.dist-info/ `
257256^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -300,52 +299,6 @@ documentation and so forth from the distribution. During installation the
300299contents of these subdirectories are moved onto their destination paths.
301300
302301
303- Signed wheel files
304- ------------------
305-
306- Wheel files include an extended RECORD that enables digital
307- signatures. PEP 376's RECORD is altered to include a secure hash
308- ``digestname=urlsafe_b64encode_nopad(digest) `` (urlsafe base64
309- encoding with no trailing = characters) as the second column instead
310- of an md5sum. All possible entries are hashed, including any
311- generated files such as .pyc files, but not RECORD which cannot contain its
312- own hash. For example::
313-
314- file.py,sha256=AVTFPZpEKzuHr7OvQZmhaU3LvwKz06AJw8mT\_pNh2yI,3144
315- distribution-1.0.dist-info/RECORD,,
316-
317- The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in
318- RECORD at all since they can only be added after RECORD is generated.
319- Every other file in the archive must have a correct hash in RECORD
320- or the installation will fail.
321-
322- If JSON web signatures are used, one or more JSON Web Signature JSON
323- Serialization (JWS-JS) signatures is stored in a file RECORD.jws adjacent
324- to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of
325- RECORD as the signature's JSON payload:
326-
327- .. code-block :: json
328-
329- { "hash" : " sha256=ADD-r2urObZHcxBW3Cr-vDCu5RJwT4CaRTHiFmbcIYY" }
330-
331- (The hash value is the same format used in RECORD.)
332-
333- If RECORD.p7s is used, it must contain a detached S/MIME format signature
334- of RECORD.
335-
336- A wheel installer is not required to understand digital signatures but
337- MUST verify the hashes in RECORD against the extracted file contents.
338- When the installer checks file hashes against RECORD, a separate signature
339- checker only needs to establish that RECORD matches the signature.
340-
341- See
342-
343- - https://datatracker.ietf.org/doc/html/rfc7515
344- - https://datatracker.ietf.org/doc/html/draft-jones-json-web-signature-json-serialization-01
345- - https://datatracker.ietf.org/doc/html/rfc7517
346- - https://datatracker.ietf.org/doc/html/draft-jones-jose-json-private-key-01
347-
348-
349302FAQ
350303===
351304
@@ -361,34 +314,6 @@ Wheel defines a .data directory. Should I put all my data there?
361314 in *wheel's * ``.data `` directory.
362315
363316
364- Why does wheel include attached signatures?
365- -------------------------------------------
366-
367- Attached signatures are more convenient than detached signatures
368- because they travel with the archive. Since only the individual files
369- are signed, the archive can be recompressed without invalidating
370- the signature or individual files can be verified without having
371- to download the whole archive.
372-
373-
374- Why does wheel allow JWS signatures?
375- ------------------------------------
376-
377- The JOSE specifications of which JWS is a part are designed to be easy
378- to implement, a feature that is also one of wheel's primary design
379- goals. JWS yields a useful, concise pure-Python implementation.
380-
381-
382- Why does wheel also allow S/MIME signatures?
383- --------------------------------------------
384-
385- S/MIME signatures are allowed for users who need or want to use
386- existing public key infrastructure with wheel.
387-
388- Signed packages are only a basic building block in a secure package
389- update system. Wheel only provides the building block.
390-
391-
392317What's the deal with "purelib" vs. "platlib"?
393318---------------------------------------------
394319
@@ -465,6 +390,7 @@ History
465390 :pep: `639 `.
466391- January 2025: Clarified that name and version needs to be normalized for
467392 ``.dist-info `` and ``.data `` directories.
393+ - January 2026: Deprecate RECORD.jws and RECORD.p7s :pep: `815 `.
468394
469395
470396Appendix
0 commit comments