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.
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 _ (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.
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?
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 "
We configured our Pipenv and Pip installations to use this index URL:
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
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.