In the PEP 458 world, package authors are not required to do anything.
On Wed, Dec 31, 2014 at 11:54 AM, Paul Moore firstname.lastname@example.org wrote:
On 31 December 2014 at 16:08, Vladimir Diaz email@example.com 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 "setup.py 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 https://minilock.io/? 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: https://www.python.org/dev/peps/pep-0480/#automated-signing-solution
Let us know what you think.