The developers of the Python Package Index (PyPI) repository have announced the implementation of a digital attestation mechanism for verifying the authenticity of published packages, replacing the previous verification using PGP signatures. A key distinction of attestation is that the publication of a package is certified not by the developer, but by a third party (the package catalog) after confirming the validity of the publication through an external OpenID Connect provider (for example, after verifying that the package being published corresponds to its associated repository on GitHub or GitLab).
The attestation system eliminates the shortcomings of the PGP signature verification mechanism, which was previously declared obsolete on PyPI. This decision was made due to issues with verifying the ownership of developers' public PGP keys used for validating digital signatures — of the 1,069 PGP keys used since 2020 for generating signatures on PyPI, 29% of public keys were missing from major public key servers, and 35% of keys could not be verified during the audit. servers Meanwhile, the confirmed 36% of PGP keys covered only 0.3% of all signed files.
In the new system, the signatures used to certify packages are generated using short-lived ephemeral keys, which are created based on credentials verified by OpenID Connect providers. At the time of generating the keys needed to create a digital signature, the developer identifies themselves through an OpenID provider that confirms their connection to the main project. The infrastructure for digital attestation is built using the Sigstore system and the in-toto Attestation Framework toolkit.
Among the advantages of certification is the lack of binding to permanent PGP keys — the loss or compromise of a private key undermines the trust in the signatures created based on it, while in certification, the signature is formed in connection with a token confirming the authority at the moment of package submission and the association of the package with the main repository containing the code. For example, when publishing a package prepared via GitHub Action, certification establishes a verifiable and confirmed link between the file hosted on PyPI, the repository, the workflow process, and the commit hash on which the package was created.
To track the authenticity of keys and identify potential compromises, a public centralized log is used for projects and PyPI itself, employing the structure of a 'Merkle Tree' to ensure integrity and protect against data tampering retrospectively, where each branch verifies all underlying branches and nodes through tree hashing.
Additionally, the detection of the malicious package 'fabrice' in the PyPI directory is worth noting. It disguised itself as the popular library 'fabric' through typosquatting (the assignment of similar names differing by individual characters, such as exampl instead of example, djangoo instead of django, pyhton instead of python, etc.), which has accumulated 201 million downloads (7 million last month). The malicious package went unnoticed since 2021 and has been downloaded over 37,000 times since then.
The 'fabrice' package replicated the core functionality of the original library and additionally included code to identify and send AWS access keys to external hosts, install a backdoor, and execute specific scripts. The activation of the malicious components occurred in both Linux and Windows. In Linux, files associated with the malicious activity were downloaded to the directory ~/.local/bin/vscode.
Source: opennet.ru
