What Additional Repository Files are Required on PyPI?

In order for package managers like pip to download and verify distributions withTUF, a few extra files MUST be added to PyPI. These extra repository files arecalled TUF metadata, and they contain such information as which keys can be trusted,thecryptographic hashes of files, signatures, metadata version numbers, andthe date after which the metadata should be considered expired.

When a package manager wants to check for updates, it asks TUF to do the work.That is, a package manager never has to deal with this additional metadata orunderstand what’s going on underneath. If TUF reports back that there areupdates available, a package manager can then ask TUF to download these filesfrom PyPI. TUF downloads them and checks them against the TUF metadata that italso downloads from the repository. If the downloaded target files aretrustworthy, TUF then hands them over to the package manager.

TheDocument formats section of the TUF specification provides informationabout each type of required metadata and its expected content. The nextsection covers the different kinds of metadata RECOMMENDED for PyPI.

In addition, all target files SHOULD be available on disk at least two times.Once under their original filename, to provide backwards compatibility, andonce with their SHA-512 hash included in theirfilename. This is required to produceConsistent Snapshots.

Depending on the used file system different data deduplication mechanisms MAYbe employed to avoid storage increase from hard copies of target files.

Signing Metadata and Repository Management

The top-levelroot role signs for the keys of the top-leveltimestamp,snapshot,targets, androot roles. Thetimestamp role signs for everynew snapshot of the repository metadata. Thesnapshot role signs forroot,targets, and all delegated targets roles. The delegated targets rolebinsfurther delegates to thebin-n roles, which sign for all distribution filesbelonging to registered PyPI projects.

Figure 1 provides an overview of the roles available within PyPI, whichincludes the top-level roles and the roles delegated to bytargets. The figurealso indicates the types of keys used to sign each role, and which roles aretrusted to sign for files available on PyPI. The next two sections cover thedetails of signing repository files and the types of keys used for each role.

Figure 1: An overview of the role metadata available on PyPI.

The roles that change most frequently aretimestamp,snapshot and rolesdelegated to bybins (i.e.,bin-n). Thetimestamp andsnapshotmetadata MUST be updated wheneverroot,targets or delegated metadata areupdated. Observe, though, thatroot andtargets metadata are much lesslikely to be updated as often as delegated metadata. Similarly, thebins rolewill only be updated when abin-n role is added, updated, or removed. Therefore,timestamp,snapshot, andbin-n metadata will most likely be updated frequently (possibly everyminute) due to delegated metadata being updated frequently in order to supportcontinuous delivery of projects. Continuous delivery is a set of processesthat PyPI uses to produce snapshots that can safely coexist and be deletedindependent of other snapshots[18].

Every year, PyPI administrators SHOULD sign forroot andtargets role keys.Automation will continuously sign for a timestamped snapshot of all projects. ArepositoryMetadata API is available that can be used tomanage a TUFrepository.

In standard operation, thebin-n metadata will be updated and signed as newdistributions are uploaded to PyPI. However, there will also need to be aone-time online initialization mechanism to create and signbin-n metadata forall existing distributions that are part of the PyPI repository every time PyPIis re-initialized.

How to Establish Initial Trust in the PyPI Root Keys

Package managers like pip MUST ship theroot metadata file with theinstallation files that users initially download. This includes informationabout the keys trusted for all top-level roles (including the root keys themselves).Package managers must also bundle a TUF client library. Any new version ofrootmetadata that the TUF client library may download is verified against the root keysinitially bundled with the package manager. If a root key is compromised,but a threshold of keys are still secured, then PyPI administrators MUST push newroot metadata that revokes trust in the compromised keys. If a threshold of rootkeys are compromised, then theroot metadata MUST be updated out-of-band.(However, the threshold of root keys should be chosen so that this event is extremelyunlikely.) Package managers do not necessarily need to be updated immediately if rootkeys are revoked or added between new releases of the package manager, as the TUF updateprocess automatically handles cases where a threshold of previousroot keys signfor newroot keys (assuming no backwards-incompatibility in the TUF specificationused). So, for example, if a package manager was initially shipped with version 1 oftheroot metadata, and a threshold ofroot keys in version 1 signed version 2 oftheroot metadata, and a threshold ofroot keys in version 2 signed version 3 oftheroot metadata, then the package manager should be able to transparently updateits copy of the *root metadata from version 1 to 3 using its TUF client library.

Thus, to repeat, the latest good copy ofroot metadata and a TUF client library MUSTbe included in any new version of pip shipped with CPython (via ensurepip). The TUFclient library inside the package manager then loads theroot metadata and downloadsthe rest of the roles, including updating theroot metadata if it has changed.Anoutline of the update process is available.

Minimum Security Model

There are two security models to consider when integrating TUF into PyPI. Theone proposed in this PEP is the minimum security model, which supportsverification of PyPI distributions signed with private cryptographickeys stored on PyPI. Distributions uploaded by developers are signed by PyPIand immediately available for download. A possible future extension to thisPEP, discussed inPEP 480, proposes the maximum security model and allowsa developer to sign for their project. Developer keys are not stored online:therefore, projects are safe from PyPI compromises.

The minimum security model requires no action from a developer and protectsagainst malicious CDNs[19] and public mirrors. To support continuousdelivery of uploaded distributions, PyPI signs for projects with an online key.This level of security prevents projects from being accidentally ordeliberately tampered with by a mirror or a CDN because neither willhave any of the keys required to sign for projects. However, it does notprotect projects from attackers who have compromised PyPI, since they canthen manipulate TUF metadata using the keys stored online.

This PEP proposes that thebin-n roles sign for all PyPI projects with onlinekeys. Thesebin-n roles MUST all be delegated by the upper-levelbins role,which is signed with an offline key, and in turn MUST be delegated by thetop-leveltargets role, which is also signed with an offline key.This means that when a package manager such as pip (i.e., using TUF) downloadsa distribution file from a project on PyPI, it will consult thetargets role aboutthe TUF metadata for that distribution file. If ultimately nobin-n rolesdelegated bytargets viabins specify the distribution file, then it isconsidered to be non-existent on PyPI.

Note, the reason whytargets does not directly delegate tobin-n, butinstead uses the intermediarybins role, is so that other delegations caneasily be added or removed, without affecting thebins-to-bin-n mapping.This is crucial for the implementation ofPEP 480.

Metadata Expiry Times

The metadata for theroot,targets, andbins roles SHOULD each expire inone year, because these metadata files are expected to change very rarely.

Thetimestamp,snapshot, andbin-n metadata SHOULD each expire in one daybecause a CDN or mirror SHOULD synchronize itself with PyPI every day.Furthermore, this generous time frame also takes into account client clocksthat are highly skewed or adrift.

Metadata Scalability

As the number of projects and distributions on a repository grows, TUF metadata will need togrow correspondingly. For example, consider thebins role. In August 2013,it was found that the size of thebins metadata was about 42MB if thebinsrole itself signed for about 220K PyPI targets (which are simple indices anddistributions). This PEP does not delve into the details, but TUF features aso-called“hashed bin delegation” scheme that splits a large targets metadata fileinto many small ones. This allows a TUF client updater to intelligentlydownload only a small number of TUF metadata files in order to update anyproject signed for by thebins role. For example, applying this scheme tothe previous repository resulted in pip downloading between 1.3KB and 111KB toinstall or upgrade a PyPI project via TUF.

Based on our findings as of the time this document was updated forimplementation (Nov 7 2019), summarized in Tables 2-3, PyPI SHOULDsplit all targets in thebins role by delegating them to 16,384bin-n roles (see C10 in Table 2). Eachbin-n role would signfor the PyPI targets whose SHA2-512 hashes fall into that bin(see Figure 1 andConsistent Snapshots). It was foundthat this number of bins would result in a 5-9% metadata overhead(relative to the average size of downloaded distribution files; see V13 andV15 in Table 3) for returning users, and a 69% overhead for newusers who are installing pip for the first time (see V17 in Table 3).

A few assumptions used in calculating these metadata overhead percentages:

1. We are ignoring root, timestamp, and top-level targets metadata.
2. pip will always be bundled with the latest good copy of metadata for allroles.

C8 was computed by querying the number of release files.C9 was derived by taking the average between a rough estimate of the averagesize of release filesdownloaded over the past 31 days (1,628,321 bytes),and the average size of releases files on disk (2,740,465 bytes).Ee Durbin helped to provide these numbers on November 7, 2019.

Table 2: A list of constants used to calculate metadata overhead.

Table 3: Estimated metadata overheads for new and returning users.

The interested reader may find an interactive version of the metadata overheadcalculatorhere:

This number of bins SHOULD increase when the metadata overhead for returningusers exceeds 50%. Presently, this SHOULD happen when the number of targetsincrease at least 10x from over 2M to over 22M, at which point the metadataoverhead for returning and new users would be around 50-54% and 114%respectively, assuming that the number of bins stay fixed. If the number ofbins is increased, then the cost for all users would effectively be the costfor new users, because their cost would be dominated by the (once-in-a-while)cost of downloading the large number of delegations in thebins metadata.If the cost for new users should prove to be too much, primarily due to theoverhead of downloading thebins metadata, then this subject SHOULD berevisited before that happens.

Note that changes to the number of bins on the server are transparent to theclient. The package manager will be required to download a fresh set ofmetadata, as though it were a new user, but this operation will not require anyexplicit code logic or user interaction in order to do so.

It is possible to make TUF metadata more compact by representing it in a binaryformat, as opposed to the JSON text format. Nevertheless, a sufficiently largenumber of projects and distributions will introduce scalability challenges atsome point, and therefore thebins role will still need delegations (asoutlined in Figure 1) in order to address the problem. The JSON format is anopen and well-known standard for data interchange, which is already supported bythe TUF reference implementation, and therefore the recommended data format bythis PEP. However, due to the large number of delegations, compressedversions of all metadata SHOULD also be made available to clients via theexisting Warehouse mechanisms for HTTP compression. In addition, the JSONmetadata could be compressed before being sent to clients. The TUF referenceimplementation does not currently support downloading compressed JSON metadata,but this could be added to reduce the metadata size.

Number and Type Of Keys Recommended

Theroot role key is critical for security and should very rarely be used.It is primarily used for key revocation, and it is the locus of trust for allof PyPI. Theroot role signs for the keys that are authorized for each ofthe top-level roles (including its own). Keys belonging to theroot role areintended to be very well-protected and used with the least frequency of allkeys. It is RECOMMENDED that the PSF board determine the current set of trustedroot key holders, each of whom will own a (strong) root key.A majority of them can then constitute a quorum to revoke or endow trust in alltop-level keys. Alternatively, the system administrators of PyPI could begiven responsibility for signing for theroot role. Therefore, therootrole SHOULD require (t, n) keys, where n is the number of key holders determinedby the PSF board, and t > 1 (so that at least two members must sign therootrole).

Thetargets role will be used only to sign for the static delegation of alltargets to thebins role. Since these target delegations must be securedagainst attacks in the event of a compromise, the keys for thetargets roleMUST be offline and independent of other keys. For simplicity of keymanagement, without sacrificing security, it is RECOMMENDED that the keys ofthetargets role be permanently discarded as soon as they have been createdand used to sign for the role. Therefore, thetargets role SHOULD require(2, 2) keys. Again, this is because the keys are going to be permanentlydiscarded, and more offline keys will not help resist key recoveryattacks[20] unless the diversity of cryptographic algorithms is maintained.

For similar reasons, the keys for thebins role SHOULD be set up similar tothe keys for thetargets role.

In order to support continuous delivery, the keys for thetimestamp,snapshot, and allbin-n roles MUST be online. There is little benefit inrequiring all of these roles to use different online keys, since attackerswould presumably be able to compromise all of them if they compromise PyPI.Therefore, it is reasonable to use one online key for all of them.

Managing online keys

The online key shared by thetimestamp,snapshot, and allbin-n rolesMAY be stored, encrypted or not, on the Python infrastructure. For example,the key MAY be kept on a self-hosted key management service (e.g. HashicorpVault), or a third-party one (e.g. AWSKMS, Google CloudKMS, or AzureKeyVault).

Some of these key management services allow keys to be stored on HardwareSecurity Modules (HSMs) (e.g., HashicorpVault, AWSCloudHSM, GoogleCloudHSM, Azure KeyVault). This prevents attackers from exfiltratingthe online private key (albeit not from using it, although their actionsmay now be cryptographically auditable). However, this requires modifyingthe reference TUF implementation to support HSMs (WIP).

Regardless of where and how this online key is kept, its use SHOULD becarefully logged, monitored, and audited, ideally in such a manner thatattackers who compromise PyPI are unable to immediately turn off this logging,monitoring, and auditing.

Managing offline keys

As explained in the previous section, theroot,targets, andbins rolekeys MUST be offline for maximum security. These keys will be offline in thesense that their private keys MUST NOT be stored on PyPI, though some of themMAY be online in the private infrastructure of the project.

There SHOULD be an offline key ceremony to generate, backup, and store thesekeys in such a manner that the private keys can be read only by the Pythonadministrators when necessary (e.g., such as rotating the keys for thetop-level TUF roles). Thus, keys SHOULD be generated, preferably in a physicallocation where side-channelattacks are not a concern, using:

1. A trusted,airgapped computer with a true random numbergenerator, andwith nodata persisting after the ceremony
2. A trusted operating system
3. A trusted set of third-party packages (such as updated versions ofcryptographic libraries or the TUF reference implementation, where theversions provided by the trusted operating system are not recent enough)

In order to avoid the persistence of sensitive data (e.g., private keys) other thanon backup media after the ceremony, offline keys SHOULD be generatedencrypted using strong passwords, either on (in decreasing order of trust):private HSMs (e.g.,YubiHSM), cloud-based HSMs (e.g., those listed above),in volatile memory (e.g., RAM), or in nonvolatile memory(e.g., SSD or microSD). If keys must be generated on nonvolatile memory,then this memory MUST be irrecoverably destroyed after having securelybacked up the keys.

Passwords used to encrypt keys SHOULD be stored somewhere durable andtrustworthy to which only Python admins have access.

In order to minimizeOPSEC errors during the ceremony, scripts SHOULD bewritten, for execution on the trusted key-generation computer, to automatetedious steps of the ceremony, such as:

• Exporting tosneakernet all code and data (previous TUF metadata androotkeys) required to generate new keys and replace old ones
• Tightening the firewall, updating the entire operating system in order tofix security vulnerabilities, and airgapping the computer
• Exportingall new TUF metadata and keys to encrypted backup media.This backup provides a complete copy of the data required to restore the PyPITUF repository
• Exportingonly new TUF metadata and online keys to encrypted backup media.This backup provides all online data for import into the PyPI infrastructureand is useful, e.g., when the online data needs to be restored from a previousarchived state
• Printing and saving cryptographic hashes of new TUF metadata. This printed copyprovides an additional offline paper backup, which can be used as a comparisonin the case of a compromise

Note the one-time keys for thetargets andbins roles MAY be safelygenerated, used, and deleted during the offline key ceremony. Furthermore,theroot keys MAY not be generated during the offline key ceremony itself.Instead, a threshold t of n Python administrators, as discussed above, MAYindependently sign theroot metadataafter the offline key ceremony usedto generate all other keys.

Consistent Snapshots

To keep TUF metadata on PyPI consistent with the highly volatile target files,consistent snapshots SHOULD be used. Each consistent snapshot captures thestate of all known projects at a given time and MAY safely coexist with anyother snapshot, or be deleted independently, without affecting any othersnapshot.

To maintain consistent snapshots, all TUF metadata MUST, when written to disk,include a version number in their filename:

VERSION_NUMBER.ROLENAME.json,

where VERSION_NUMBER is an incrementing integer, and ROLENAME is one of thetop-level metadata roles –root,snapshot ortargets – or one ofthe delegated targets roles –bins orbin-n.

The only exception is thetimestamp metadata file, whose version would not be knownin advance when a client performs an update. Thetimestamp metadatalists theversion of thesnapshot metadata, which in turn lists the versions of thetargets and delegated targets metadata, all as part of a given consistentsnapshot.

In normal usage, version number overflow is unlikely to occur. An 8-byte integer,for instance, can be incremented once per millisecond and last almost 300 millionyears. If an attacker increases the version number arbitrarily, the repositorycan recover by revoking the compromised keys and resetting the version number asdescribed in the TUFspecification.

Thetargets or delegated targets metadata refer to the actual targetfiles, including their cryptographic hashes as specified above.Thus, to mark a target file as part of a consistent snapshot it MUST, whenwritten to disk, include its hash in its filename:

HASH.FILENAME

where HASH is thehex digest of the hash of the file contents andFILENAME is the original filename.

This means that there MAY be multiple copies of every target file, one for eachof the cryptographic hash functions specified above.

Assuming infinite disk space, strictly incrementing version numbers, and nohash collisions, a client may safely read from one snapshot while PyPIproduces another snapshot.

Clients, such as pip, that use the TUF protocol MUST be modified to downloadevery metadata and target file, except fortimestamp metadata. This is doneby including, in the file request, the version of the file (for metadata),or the cryptographic hash of the file (for target files) in the filename.

In this simple but effective manner, PyPI is able to capture a consistentsnapshot of all projects and the associated metadata at a given time. The nextsubsection provides implementation details of this idea.

Note: This PEP does not prohibit using advanced file systems or tools toproduce consistent snapshots. There are two important reasons for proposing a simple solution in this PEP.First, the solution does not mandate that PyPIuse any particular file system or tool. Second, the generic file-system basedapproach allows mirrors to use extant file transfer tools, such as rsync, toefficiently transfer consistent snapshots from PyPI.

Producing Consistent Snapshots

When a new distribution file is uploaded to PyPI, PyPI MUST update theresponsiblebin-n metadata. Remember that all target files are sorted intobins by their filename hashes. PyPI MUST also updatesnapshot to account forthe updatedbin-n metadata, andtimestamp to account for the updatedsnapshot metadata. These updates SHOULD be handled by an automatedsnapshotprocess.

File uploads MAY be handled in parallel, however, consistent snapshots MUST beproduced in a strictly sequential manner. Furthermore, as long as distributionfiles are self-contained, a consistent snapshot MAY be produced for eachuploaded file. To do so upload processes place new distribution files into aconcurrency-safe FIFO queue and the snapshot process reads from that queue onefile at a time and performs the following tasks:

First, it adds the new file path to the relevantbin-n metadata, incrementsits version number, signs it with thebin-n role key, and writes it toVERSION_NUMBER.bin-N.json.

Then, it takes the most recentsnapshot metadata, updates itsbin-nmetadata version numbers, increments its own version number, signs it with thesnapshot role key, and writes it toVERSION_NUMBER.snapshot.json.

And finally, the snapshot process takes the most recenttimestamp metadata,updates itssnapshot metadata hash and version number, increments its ownversion number, sets a new expiration time, signs it with thetimestamp rolekey, and writes it totimestamp.json.

When updatingbin-n metadata for a consistent snapshot, the snapshot processSHOULD also include any new or updated hashes of simple index pages in therelevantbin-n metadata. Note that, simple index pages may be generateddynamically on API calls, so it is important that their output remains stablethroughout the validity of a consistent snapshot.

Since the snapshot process MUST generate consistent snapshots in a strictlysequential manner it constitutes a bottleneck. Fortunately, the operation ofsigning is fast enough that this may be done a thousand or more times persecond.

Moreover, PyPI MAY serve distribution files to clients before the correspondingconsistent snapshot metadata is generated. In that case the client softwareSHOULD inform the user that full TUF protection is not yet available but willbe shortly.

PyPI SHOULD use atransaction log to record upload processes and thesnapshot queue for auditing and to recover from errors after a server failure.

Cleaning up old metadata

To avoid running out of disk space due to the constant production of newconsistent snapshots, PyPI SHOULD regularly delete old consistent snapshots,i.e. metadata and target files that were obsoleted some reasonable time inthe past, such as 1 hour.

In order to preserve the latest consistent snapshot PyPI MAY use a“mark-and-sweep” algorithm. That is, walk from the root of the latestconsistent snapshot, i.e.timestamp oversnapshot overtargets anddelegated targets until the target files, marking all visited files, anddelete all unmarked files. The last few consistent snapshots may be preservedin a similar fashion.

Deleting a consistent snapshot will cause clients to see nothing except HTTP404 responses to any request for a file within that consistent snapshot.Clients SHOULD then retry their requests (as before) with the latest consistentsnapshot.

Note thatroot metadata, even though versioned, is not part of any consistentsnapshot. PyPI MUST NOT delete old versions ofroot metadata. This guaranteesthat clients can update to the latestroot role keys, no matter how outdatedtheir localroot metadata is.

In the Event of a Key Compromise

A key compromise means that a threshold of keys (belonging to the metadataroles on PyPI), as well as the PyPI infrastructure have been compromised andused to sign new metadata on PyPI.

If a threshold number oftimestamp,snapshot,targets,bins orbin-nkeys have been compromised, then PyPI MUST take the following steps:

1. Revoke thetimestamp,snapshot andtargets role keys fromtheroot role. This is done by replacing the compromisedtimestamp,snapshot andtargets keys with newly issued keys.
2. Revoke thebins keys from thetargets role by replacing their keys withnewly issued keys. Sign the newtargets role metadata and discard the newkeys (because, as explained earlier, this increases the security oftargets metadata).
3. All targets of thebin-n roles SHOULD be compared with the last knowngood consistent snapshot in which none of thetimestamp,snapshot,bins orbin-n keyswere known to have been compromised. Added, updated or deleted targets inthe compromised consistent snapshot that do not match the last known goodconsistent snapshot MAY be restored to their previous versions. Afterensuring the integrity of allbin-n targets, their keys should be renewedin thebins metadata.
4. Thebins andbin-n metadata MUST have their version numbers incremented,expiry times suitably extended, and signatures renewed.
5. A new timestamped consistent snapshot MUST be issued.

Following these steps would preemptively protect all of these roles, even ifonly one of them may have been compromised.

If a threshold number ofroot keys have been compromised, then PyPI MUST takethe above steps and also replace allroot keys in theroot role.

It is also RECOMMENDED that PyPI sufficiently document compromises withsecurity bulletins. These security bulletins will be most informative whenusers of pip-with-TUF are unable to install or update a project because thekeys for thetimestamp,snapshot orroot roles are no longer valid. Theycould then visit the PyPI web site to consult security bulletins that wouldhelp to explain why they are no longer able to install or update, and then takeaction accordingly. When a threshold number ofroot keys have not beenrevoked due to a compromise, then newroot metadata may be safely updatedbecause a threshold number of existingroot keys will be used to sign for theintegrity of the newroot metadata. TUF clients will be able to verify theintegrity of the newroot metadata with a threshold number of previouslyknownroot keys. This will be the common case. Otherwise, in the worstcase, in which a threshold number ofroot keys have been revoked due to acompromise, an end-user may choose to update newroot metadata without-of-band mechanisms.

Auditing Snapshots

If a malicious party compromises PyPI, they can sign arbitrary files with anyof the online keys. The roles with offline keys (i.e.,root,targets andbins)are still protected. To safely recover from a repository compromise, snapshotsshould be audited to ensure files are only restored to trusted versions.

When a repository compromise has been detected, the integrity of three types ofinformation must be validated:

1. If the online keys of the repository have been compromised, they can berevoked by having thetargets role sign new metadata delegating to a newkey.
2. If the role metadata on the repository has been changed, this would impactthe metadata that is signed by online keys. Any role information createdsince the last period should be discarded. As a result, developers of newprojects will need to re-register their projects.
3. If the target files themselves may have been tampered with, they can bevalidated using the stored hash information for target files that existedat the time of the last period.

In order to safely restore snapshots in the event of a compromise, PyPI SHOULDmaintain a small number of its own mirrors to copy PyPI snapshots according tosome schedule. The mirroring protocol can be used immediately for thispurpose. The mirrors must be secured and isolated such that they areresponsible only for mirroring PyPI. The mirrors can be checked against oneanother to detect accidental or malicious failures.

Another approach is to generate the cryptographic hash ofsnapshotperiodically and tweet it. Perhaps a user comes forward with the actualmetadata and the repository maintainers can verify the metadata file’s cryptographichash. Alternatively, PyPI may periodically archive its own versions ofsnapshot rather than rely on externally provided metadata. In this case,PyPI SHOULD take the cryptographic hash of every target file on therepository and store this data on an offline device. If any target filehash has changed, this indicates an attack.

As for attacks that serve different versions of metadata, or freeze a versionof a distribution at a specific version, they can be handled by TUF with techniqueslike implicit key revocation and metadata mismatch detection[2].

Hash Algorithm Transition Plan

If the algorithm used to hash target and metadata files becomes vulnerable, itSHOULD be replaced by a stronger hash algorithm.

The TUF metadata format allows to list digests from different hash algorithmsalongside each other, together with an algorithm identifier, so that clientscan seamlessly switch between algorithms.

However, once support for an old algorithm is turned off, clients that don’tsupport the new algorithm will only be able to install or update packages,including the client itself, by disabling TUF verification. To allow clients totransition without temporarily losing TUF security guarantees, we recommendthe following procedure.

1. Implement new algorithm in Warehouse.
2. Regenerate existing, unexpired TUF metadata to include hashes using both theold and new algorithms. All new metadata going forward shall list both hashalgorithms.Note, only TUF metadata that lists hash digests for target files or othermetadata needs to be renewed, that isbin-n,snapshot andtimestamp.Thus, only online keys are required to sign renewed metadata.
3. Announce transition on high-visibility channels, such aspackaging onPython Discourse and thePyPI changes mailing list.
4. Give popular clients such as pip and bandersnatch the chance to adopt newhash algorithm.
5. Give end-users the chance to update clients.
6. Get rough consensus to remove old hash algorithm from PyPI maintainers.
7. Remove Warehouse support for old algorithm and only support new algorithm.