Re: [Distutils] Removing wheel signing features from the wheel library

On 22 March 2018 at 05:03, wrote: > After spending quite some time thinking about this, I've decided to cut > out the wheel signature related features from the wheel codebase, > unless there is significant resistance among the readers of this > mailing list. For those

Re: [Distutils] Removing wheel signing features from the wheel library

to, 2018-03-22 kello 21:44 +1000, Nick Coghlan kirjoitti: > On 22 March 2018 at 05:03, wrote: > > After spending quite some time thinking about this, I've decided to > > cut > > out the wheel signature related features from the wheel codebase, > > unless there is

Re: [Distutils] Removing wheel signing features from the wheel library

On 22 March 2018 at 22:35, wrote: > I am not changing the format of RECORD, I'm simply removing the > cryptographic signing and verifying functionality, just the way you > described. Hash checking will stay. As we agreed earlier, those > features could be deprecated or

Re: [Distutils] PyPI support for linux_ppc64le

On Mon, Mar 19, 2018, at 12:37 PM, Thomas Kluyver wrote: > If we're happy with that, I can also look at changing the glibc > version thing, but that will probably involve a bit more actual > thought. ;-) I've opened another PR for this: https://github.com/python/peps/pull/597

Re: [Distutils] Removing wheel signing features from the wheel library

Even if no maintenance were required, it's still a feature that promises to provide security but doesn't. This kind of feature has negative value. I'd also suggest adding a small note to the PEP documenting that the signing feature didn't work out, and maybe linking to Donald's package signing

Re: [Distutils] Removing wheel signing features from the wheel library

What maintenance is required? Here's a link to the previous discussion of this issue: "Remove or deprecate wheel-signing features" https://github.com/pypa/wheel/issues/196 What has changed? There is still no method for specifying a keyring; whereas with GPG, all keys in the ring are trusted.

Re: [Distutils] Removing wheel signing features from the wheel library

to, 2018-03-22 kello 13:57 -0400, Wes Turner kirjoitti: > What maintenance is required? It's hard to say for sure, since that depends on what requirements come up in the future. One thing this certainly affects is the test suite which I plan to rewrite because I feel it is woefully inadequate.

Re: [Distutils] Removing wheel signing features from the wheel library

The feature was a building block that was intended to be used in much the same way that SHA package hashes are used, providing similar security to the ssh-style TOFU model, but less security than other imaginable public key systems. The idea was that it could provide more security in practice

Re: [Distutils] Removing wheel signing features from the wheel library

On Thursday, March 22, 2018, Daniel Holth wrote: > The feature was a building block that was intended to be used in much the > same way that SHA package hashes are used, providing similar security to > the ssh-style TOFU model, but less security than other imaginable public >

Re: [Distutils] Removing wheel signing features from the wheel library

Hi Wes, On Thu, Mar 22, 2018 at 4:40 PM, Wes Turner wrote: > > The hashes serve as file integrity check but provide no assurance that > they are what the author intended to distribute because there is no > cryptographic signature. > > File hashes help detect bit flips --

Re: [Distutils] Removing wheel signing features from the wheel library

You don't need a traditional CA for use with TUF or need to worry about a single PKI. TUF is built to be resilient to the compromise of single servers / keys. Typically you would ship the metadata about what keys to trust (TUF's "root metadata") with the software installation tool. This single

[Distutils] TUF, Warehouse, Pip, PyPA, ld-signatures, ed25519

TUF, Warehouse, Pip, PyPA, ld-signatures, ed "PEP 480 -- Surviving a Compromise of PyPI" https://www.python.org/dev/peps/pep-0458/ "PEP 480 -- Surviving a Compromise of PyPI: The Maximum Security Model" https://www.python.org/dev/peps/pep-0480/ I need to spend time reviewing these PEPs.

Re: [Distutils] Removing wheel signing features from the wheel library

On Thursday, March 22, 2018, wrote: > to, 2018-03-22 kello 16:40 -0400, Wes Turner kirjoitti: > > > > On Thursday, March 22, 2018, Daniel Holth wrote: > > The feature was a building block that was intended to be used in much the > same way that SHA

Re: [Distutils] Removing wheel signing features from the wheel library

On Thu, Mar 22, 2018, at 9:25 PM, alex.gronh...@nextday.fi wrote: > I've been wondering about something – zip files already contain CRC > based checksums for each the stored file. What benefit is there in > storing a RECORD file which basically duplicates this functionality? In terms of providing

Re: [Distutils] Removing wheel signing features from the wheel library

On Thursday, March 22, 2018, Justin Cappos wrote: > You don't need a traditional CA for use with TUF or need to worry about a > single PKI. TUF is built to be resilient to the compromise of single > servers / keys. > > Typically you would ship the metadata about what keys to

Re: [Distutils] Removing wheel signing features from the wheel library

to, 2018-03-22 kello 16:40 -0400, Wes Turner kirjoitti: > On Thursday, March 22, 2018, Daniel Holth wrote: > > The feature was a building block that was intended to be used in > > much the same way that SHA package hashes are used, providing > > similar security to the ssh-style

Re: [Distutils] TUF, Warehouse, Pip, PyPA, ld-signatures, ed25519

> Warehouse is already a SPOF. > That's a hefty responsibility that contributions should support. > Warehouse doesn't need to be a SPOF. A compromise of the Warehouse server (and all keys on it) need not allow an attacker to compromise many users. The details are in the Diplomat

Re: [Distutils] TUF, Warehouse, Pip, PyPA, ld-signatures, ed25519

On Thu, Mar 22, 2018 at 6:15 PM, Justin Cappos wrote: > > >> Warehouse is already a SPOF. >> That's a hefty responsibility that contributions should support. >> > > Warehouse doesn't need to be a SPOF. A compromise of the Warehouse server > (and all keys on it) need not allow

Re: [Distutils] TLS support policy & PyPI communications

Just as an FYI, as of this morning we’ve started doing brownouts of the deprecated TLS versions. For the first 10 minutes of each hour anyone attempting to access PyPI with TLSv1.0 or TLSv1.1 will get a 403 response with an informative error. As we get closer to the deadline I will be ramping