In the PEP 458 world, package authors are not required to do anything.

On Wed, Dec 31, 2014 at 11:54 AM, Paul Moore <> wrote:
On 31 December 2014 at 16:08, Vladimir Diaz <> wrote:
> Let me know exactly what needs to change in the PEPs to make everything
> explained above clearer.  For example, in PEP 458 we provide a
> link/reference (last paragraph of this subsection) to the Metadata document
> indicating the content of the JSON files, but should the illustration I've
> included in this reply also be added?

I don't know how generally useful this would be, and I can't even
promise I've got any useful comments to make, but I find the proposals
too full of concepts I don't really follow (as someone who isn't a
PyPI admin or a security specialist) to be able to get much from them.
Is there anywhere a document that simply explains, from the point of
view of a package author, what I would need to do that is different
from right now, in order to benefit from the proposal? (I assume the
benefits are "your users can be sure that they get the files you
uploaded, without tampering", and that's sufficient explanation of the
benefit side from my perspective).

For example, you say "PEP 480 authors sign for both their project's
index page and distribution(s)". Does that mean I need to add
something to the command line when I do " upload"? Can I still
set up an automated build process or will it now need manual entry of
some sort of passphrase in order to work?

I appreciate that the target audience for these PEPs is really PyPI
admins, at the moment, so maybe it's not the right time to look at
them from a project author perspective - if so, then feel free to
ignore these points for now :-)

Nick has stated that a PEP specifically intended for the project author perspective will be drafted after the "PyPI Admin" PEPs.  For now, I think Nick wants to focus on the bits (metadata) signed and published by PyPI (PEP 458).  In the PEP 458 model, package authors are not required to sign and upload metadata; they will upload distributions as it is currently done.

However, community feedback on PEP 480 (which supports signatures provided by project authors) is still appreciated.  Although we haven't finalized all of the details on how the third-party signing tools will change, we can still discuss the overall approach.  For example, should signing a distribution require only a secondary passphrase, akin to miniLock?  Should signing a distribution be optional?  A manual process?  We hope to reach a design that is suported by the majority of the Python community.

PEP 480 includes a section that discusses a potential approach to packages signed by package authors:

Let us know what you think.