Mailman 3 January 2020 - devpi-dev

PEP 458: Secure transport independent download integrity for PyPI packages
by Sumana Harihareswara 12 Feb '20

12 Feb '20

Hi, devpi folks! I figure you might want to take a look at the PyPI security PEP currently being discussed, since I could imagine devpi wanting to also add TUF metadata handling for packages, and in case there are interoperability concerns/questions. https://discuss.python.org/t/pep-458-surviving-a-compromise-of-pypi/2648/ The PEP authors are revising the proposed summary, title, etc., per https://github.com/secure-systems-lab/peps/blob/c13384a4fac6822626abb7e09ab… : > Attacks on software repositories are common, even in organizations with very good security practices__. The resulting repository compromise allows an attacker to edit all files stored on the repository and sign these files using any keys stored on the repository (online keys). In many signing schemes (like TLS), this access allows the attacker to replace files on the repository and make it look like these files are coming from PyPI. Without a way to revoke and replace the trusted private key, it is very challenging to recover from a repository compromise. In addition to the dangers of repository compromise, software repositories are vulnerable to an attacker on the network (MITM) intercepting and changing files. These and other attacks on software repositories are detailed here__. This PEP aims to protect users of PyPI from compromises of the integrity, consistency and freshness properties of PyPI packages, and enhances compromise resilience, by mitigating key risk and providing mechanisms to recover from a compromise of PyPI or its signing keys. In addition to protecting direct users of PyPI, this PEP aims to provide similar protection for users of PyPI mirrors. > To provide compromise resilient protection of PyPI, this PEP proposes the use of The Update Framework [2]_ (TUF). ..... > This PEP describes changes to the PyPI infrastructure that are needed to ensure that users get valid packages from PyPI. ... > __ https://github.com/theupdateframework/pip/wiki/Attacks-on-software-reposito… > __ https://theupdateframework.github.io/security.html Discussion should probably be directed to the Discourse thread at discuss.python.org ; this is just a heads-up. -- Sumana Harihareswara Changeset Consulting sh(a)changeset.nyc

1 1

Clean the index after purging old versions
by Patrick Mézard 15 Jan '20

15 Jan '20

Hello, I have a devpi server where we have recently deleted a lot of old package versions, using devpi-client. The data directory now looks like: 7.6 GiB [##########] /.indices 956.5 MiB [# ] .sqlite 461.4 MiB [ ] /+files Is this expected? Is there any command to run to rebuild/purge the index? Thanks, -- Patrick Mézard

2 2

Strange errors: "While handling ... project does not exist"
by Nicholas Williams 08 Jan '20

08 Jan '20

We're starting to roll out our new Devpi installation to projects now that we've tested it extensively. We have one master and three mirrors. For the purposes of this email, the mirrors are load-balanced behind the domain name "devpi.example.com," and the master is available at " primary-devpi-server.example.com." We configured our Pipenv and Pip installations to use this index URL: https://devpi.example.com/org_name/stable/+simple/ That URL will use the mirrors. The "org_name/stable" index extends root/pypi and also includes our internal projects. Everything appears to be working on the client. No errors, installs are going off without a hitch. However, the Devpi server on the master machine (not the mirrors) logs a ton of errors like the following: [req78237] [Rtx14602] while handling https://primary-devpi-server.example.com/root/pypi/+simple/internal_project… : The project internal_project_name does not exist. What is the cause of these errors? Is this something that should concern us, or something that we can ignore? "internal_project_name" installs just fine, but for some reason yields those errors on the master server. Thanks, Nick

2 6