Skip to content

Commit 47e0ced

Browse files
author
Lukas Puehringer
committed
PEP 458: add hash algorithm transition plan
Add subsection to section "Managing Future Changes to the Update Process" that explains how to transition from an old (weak) to a new (stronger) hashing algorithm without disrupting client workflows.
1 parent dfbb24e commit 47e0ced

File tree

1 file changed

+43
-2
lines changed

1 file changed

+43
-2
lines changed

pep-0458.txt

Lines changed: 43 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1171,8 +1171,8 @@ Managing Future Changes to the Update Process
11711171
=============================================
11721172

11731173
If breaking changes are made to the update process, PyPI should implement these
1174-
changes without disrupting existing clients. For guidance on how to do so,
1175-
see the ongoing discussion in the TAP repository__.
1174+
changes without disrupting existing clients. For general guidance on how to do
1175+
so, see the ongoing discussion in the TAP repository__.
11761176

11771177
__ https://github.com/theupdateframework/taps/pull/107
11781178

@@ -1183,6 +1183,47 @@ This PEP adds the ability for clients to use TUF metadata to improve the
11831183
security of the update process.
11841184

11851185

1186+
Hash Algorithm Transition Plan
1187+
------------------------------
1188+
1189+
If the algorithm used to hash target and metadata files becomes vulnerable, it
1190+
SHOULD be replaced by a stronger hash algorithm.
1191+
1192+
The TUF metadata format allows to list digests from different hash algorithms
1193+
alongside each other, together with an algorithm identifier, so that clients
1194+
can seamlessly switch between algorithms.
1195+
1196+
However, once support for an old algorithm is turned off, clients that don't
1197+
support the new algorithm will only be able to install or update packages,
1198+
including the client itself, by disabling TUF verification. To allow clients to
1199+
transition without temporarily losing TUF security guarantees, we recommend
1200+
the following procedure.
1201+
1202+
1. Implement new algorithm in Warehouse.
1203+
1204+
2. Regenerate existing, unexpired TUF metadata to include hashes using both the
1205+
old and new algorithms. All new metadata going forward shall list both hash
1206+
algorithms.
1207+
Note, only TUF metadata that lists hash digests for target files or other
1208+
metadata needs to be renewed, that is *bin-n*, *snapshot* and *timestamp*.
1209+
Thus, only online keys are required to sign renewed metadata.
1210+
1211+
3. Announce transition on high-visibility channels, such as `packaging on
1212+
Python Discourse`__ and the `PyPI changes mailing list`__.
1213+
1214+
4. Give popular clients such as pip and bandersnatch the chance to adopt new
1215+
hash algorithm.
1216+
1217+
5. Give end-users the chance to update clients.
1218+
1219+
6. Get rough consensus to remove old hash algorithm from PyPI maintainers.
1220+
1221+
7. Remove Warehouse support for old algorithm and only support new algorithm.
1222+
1223+
__ https://discuss.python.org/c/packaging
1224+
__ https://mail.python.org/mailman3/lists/pypi-announce.python.org/
1225+
1226+
11861227
Appendix A: Repository Attacks Prevented by TUF
11871228
===============================================
11881229

0 commit comments

Comments
 (0)