I am planning for a 1.0.0 release of the "wheel" library. I would like to start using semver from this point onwards, which in the case of wheel means that its command line interface should be well defined and remain backwards compatible. As part of this effort, I've rewritten the documentation (currently in the "docs-update" branch on Github) to conform to the PyPA guidelines. Wheel also had some generated API documentation on ReadTheDocs, but as discussed privately with Daniel Holth and Nick Coghlan, wheel should not have a public API going forward so I've deleted that documentation.
I've also taken a hard look at wheel's features and would like to remove those which I consider to be either useless or harmful. I've added these tasks as issues on Github.
All the issues that I'd like to get resolved by 1.0.0 have been tagged with the proper milestone marker here: https://github.com/pypa/wheel/milestone/1
Feedback is very welcome!
ps. Daniel, if you're reading this, would you mind giving the new docs a once-over? Also, if you can suggest where to put the "story" page, I'll link it back to the main index file.
REQ: feedback re: "Remove or deprecate wheel signing features #196" https://github.com/pypa/wheel/issues/196
Is the current implementation incomplete without signature verification? According to the spec?
``` The spec includes this feature. So, even though this verify() function is incomplete, it would be wrong to just remove it without also removing it from the spec.
- https://www.python.org/dev/peps/pep-0427/#signed-wheel-files - https://www.python.org/dev/peps/pep-0491/#signed-wheel-files
I don't have the information needed to explain what completely implemented signatures are useful for. Does the spec explain this?
A wheel installer is not required to understand digital signatures but
MUST verify the hashes in RECORD against the extracted file contents. When the installer checks file hashes against RECORD, a separate signature checker only needs to establish that RECORD matches the signature. ```
On Sunday, October 29, 2017, Alex Grönholm alex.gronholm@nextday.fi wrote:
I am planning for a 1.0.0 release of the "wheel" library. I would like to start using semver from this point onwards, which in the case of wheel means that its command line interface should be well defined and remain backwards compatible. As part of this effort, I've rewritten the documentation (currently in the "docs-update" branch on Github) to conform to the PyPA guidelines. Wheel also had some generated API documentation on ReadTheDocs, but as discussed privately with Daniel Holth and Nick Coghlan, wheel should not have a public API going forward so I've deleted that documentation.
I've also taken a hard look at wheel's features and would like to remove those which I consider to be either useless or harmful. I've added these tasks as issues on Github.
All the issues that I'd like to get resolved by 1.0.0 have been tagged with the proper milestone marker here: https://github.com/pypa/wheel/ milestone/1
Feedback is very welcome!
ps. Daniel, if you're reading this, would you mind giving the new docs a once-over? Also, if you can suggest where to put the "story" page, I'll link it back to the main index file.
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 29 October 2017 at 21:01, Wes Turner wes.turner@gmail.com wrote:
REQ: feedback re: "Remove or deprecate wheel signing features #196" https://github.com/pypa/wheel/issues/196
Is the current implementation incomplete without signature verification? According to the spec?
I've never used or felt the need for this feature. I won't miss it. Paul
On 30 October 2017 at 18:43, Paul Moore p.f.moore@gmail.com wrote:
On 29 October 2017 at 21:01, Wes Turner wes.turner@gmail.com wrote:
REQ: feedback re: "Remove or deprecate wheel signing features #196" https://github.com/pypa/wheel/issues/196
Is the current implementation incomplete without signature verification? According to the spec?
I've never used or felt the need for this feature. I won't miss it.
In practice, most folks are relying on checking the archive hashes as their integrity check, rather than checking the individual file hashes in RECORD (and then signing the RECORD file), since that lets them completely avoid worrying about the problem of establishing trust in an initial set of public keys.
For folks that do want signatures on their build server -> deployment system connections (which is the problem this features aims to help with), they're currently more likely to use external GPG signatures (the way Linux distros and some container registries do) or a system like Notary/TUF (the way the Docker registry does), than they are a Python-specific format.
So I think it would be reasonable for the wheel project maintainers to say they don't want to be responsible for ensuring that their signing implementation provides meaningful security assurances, and deprecate and remove it. We'd then update PEP 427 with a note saying that the signing feature has been deprecated in the reference implementation, and may be removed from a future version of the specification.
Cheers, Nick.
On 2017-10-31 00:20:34 +1000 (+1000), Nick Coghlan wrote: [...]
For folks that do want signatures on their build server -> deployment system connections (which is the problem this features aims to help with), they're currently more likely to use external GPG signatures (the way Linux distros and some container registries do) or a system like Notary/TUF (the way the Docker registry does), than they are a Python-specific format.
[...]
Agreed. For the hundreds of projects we publish on PyPI we have our release automation generate detached OpenPGP signatures of sdsits and wheels, and serve those signatures from our own release info site since PyPI also seems to not want to support arbitrary signature uploads over the long term. This satisfies the requests we get from distribution package maintainers to provide proof of provenance for our release artifacts; our release managers and community infrastructure sysadmins sign the per-cycle release automation keys, and regularly participate in key signing with distro package maintainers in-person at conferences to establish a sufficient web of trust. I understand this is probably untenable for smaller projects, but at our scale it works fairly well (also easier to generalize beyond merely Python-based software).
I'll be honest, when designing our artifact signing automation I didn't even know the wheel spec suggested it should be a feature, but without having consistent integration in other tooling for signed sdists too it wouldn't have been much help to us anyway.
participants (5)
-
Alex Grönholm -
Jeremy Stanley -
Nick Coghlan -
Paul Moore -
Wes Turner