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

[Trishank Kuppusamy]

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 an attacker to compromise many users.
> The details are in the Diplomat
> 
>  paper, but the gist is that you can have some rarely used, offline keys
> that are stored by folks like Donald, etc. and a quorum of those trusted
> users would need to be malicious to cause substantial harm to users.
>
> However, you can have whatever trust / key distribution / storage model
> makes sense.  TUF doesn't force you to use some pre-ordained model.  It has
> flexibility to support a variety of workflows, including many with good
> security properties.
>
> Would [offline] package mirrors and the CDN still work for/with TUF keys?
>>
>
> Yes, this works just fine.  CDNs / mirrors do not change in any way.
>

+1

(I'm logging off work for today, but happy to discuss more tomorrow)
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Justin Cappos]

> 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

 paper, but the gist is that you can have some rarely used, offline keys
that are stored by folks like Donald, etc. and a quorum of those trusted
users would need to be malicious to cause substantial harm to users.

However, you can have whatever trust / key distribution / storage model
makes sense.  TUF doesn't force you to use some pre-ordained model.  It has
flexibility to support a variety of workflows, including many with good
security properties.

Would [offline] package mirrors and the CDN still work for/with TUF keys?
>

Yes, this works just fine.  CDNs / mirrors do not change in any way.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Wes Turner]

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 trust (TUF's
> "root metadata") with the software installation tool.  This single set of
> pre-shared metadata means you can securely obtain the rest of the
> software.  (I'm happy to go into more detail, but wanted to avoid this
> becoming a barrage of TUF details unless everyone is interested.)
>
> If you don't want to ship the metadata with the tool, you can also have it
> work in a trust-on-first-use model.  This is what Docker does in their
> deployment of TUF.
>

[Distutils] TUF, Warehouse, Pip, PyPA, ld-signatures, ed25519
https://mail.python.org/pipermail/distutils-sig/2018-March/032081.html

I split the thread. Thanks for the explanation.


>
> On Thu, Mar 22, 2018 at 4:40 PM, Wes Turner  wrote:
>
>>
>>
>> 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
>>> key systems. The idea was that it could provide more security in practice
>>> because the signatures could exist and be present with the archive, unlike
>>> gpg which provides loads of security in theory only. Unfortunately wheel
>>> signatures were never built up. I don't think anyone was tricked into
>>> believing the primitive provided security on its own.
>>>
>>
>> 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 -- due to solar flares -- in storage or
>> transit, but do not mitigate against malicious package modification to
>> packages in storage or transit.
>>
>> AFAIU, TUF (The Update Framework) has a mechanism for limiting which
>> signing keys are valid for which package? Are pre-shared keys then still
>> necessary, or do we then rely on a PKI where one compromised CA cert can
>> then forge any other cert?
>>
>> https://theupdateframework.github.io/
>>
>>
>>>
>>> On Thu, Mar 22, 2018 at 2:21 PM Nathaniel Smith ared
>>> wrote:
>>>
 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 blog post. I know updating PEPs isn't the most common thing, but
 it's the main documentation of the wheel format and it'll save confusion
 later.

 On Mar 22, 2018 10:57 AM, "Wes Turner"  wrote:

> 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.
>
> On Thursday, March 22, 2018, Nick Coghlan  wrote:
>
>> 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 removed from the PEP entirely.
>>>
>>
>> Cool, that's what I thought you meant, but I figured I should double
>> check since our discussion was a while ago now :)
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>>
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
> ___
 Distutils-SIG maillist  -  Distutils-SIG@python.org
 https://mail.python.org/mailman/listinfo/distutils-sig

>>>
>> ___
>> Distutils-SIG maillist  -  Distutils-SIG@python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Thomas Kluyver]

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 a foundation for security checks, I think CRC
checksums are insufficient - they are meant to detect random data
corruption, not a deliberate effort to make a malicious file.
You could simply use a cryptographic hash of the entire wheel zip file.
I guess the advantage of storing file hashes in RECORD is that they can
be checked against the installed code, not just the wheel package.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Wes Turner]

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 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
> because the signatures could exist and be present with the archive, unlike
> gpg which provides loads of security in theory only. Unfortunately wheel
> signatures were never built up. I don't think anyone was tricked into
> believing the primitive provided security on its own.
>
>
> 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 -- due to solar flares -- in storage or
> transit, but do not mitigate against malicious package modification to
> packages in storage or transit.
>
>
> 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?
>

AFAIU, there's no good way to do post-install hash verification like
`debsums` and `rpm -V` with zip CRCs (though it's probably possible if
there's a structured log of installed packages).


>
>
> AFAIU, TUF (The Update Framework) has a mechanism for limiting which
> signing keys are valid for which package? Are pre-shared keys then still
> necessary, or do we then rely on a PKI where one compromised CA cert can
> then forge any other cert?
>
> https://theupdateframework.github.io/
>
>
>
> On Thu, Mar 22, 2018 at 2:21 PM Nathaniel Smith ared wrote:
>
> 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 blog post. I know updating PEPs isn't the most common thing, but
> it's the main documentation of the wheel format and it'll save confusion
> later.
>
> On Mar 22, 2018 10:57 AM, "Wes Turner"  wrote:
>
> 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.
>
> On Thursday, March 22, 2018, Nick Coghlan  wrote:
>
> 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 removed from the PEP entirely.
>
>
> Cool, that's what I thought you meant, but I figured I should double check
> since our discussion was a while ago now :)
>
> Cheers,
> Nick.
>
> ___
> Distutils-SIG maillist  -  
> Distutils-SIG@python.orghttps://mail.python.org/mailman/listinfo/distutils-sig
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Wes Turner]

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. Backseat driving here; sorry:

Are there pypa/warehouse github issues for implementing the TUF trust root
support in warehouse; and client support in pip (or a module that pip and
other tools can use)?

Warehouse is already a SPOF.
That's a hefty responsibility that contributions should support.

Would [offline] package mirrors and the CDN still work for/with TUF keys?


ld-signatures has some normative language that could be useful.

ld-signatures uses URIs for signature suites (a canonicalization algorithm,
a message digest algorithm, and a signature algorithm) and JSONLD. That
should be pretty future proof in regards to the NIST post-quantum
algorithms call that's under review at this time.

Blockcerts builds upon ld-signatures.

There's a compact form of JSONLD.
JSON[LD] can also be serialized as BSON (and RDFHDT).

"Linked Data Signatures 1.0" (draft)
https://w3c-dvcg.github.io/ld-signatures/

"Ed25519 Signature 2018" (draft)
https://w3c-dvcg.github.io/lds-ed25519-2018/
- canonicalizationAlgorithm: https://w3id.org/security#URDNA2015
- digestAlgorithm: http://w3id.org/digests#sha512
- signatureAlgorithm: http://w3id.org/security#ed25519


https://theupdateframework.github.io/

https://github.com/theupdateframework/specification/blob/master/tuf-spec.md#the-update-framework-specification


On Thursday, March 22, 2018, Trishank Kuppusamy <
trishank.kuppus...@datadoghq.com> wrote:

> 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 -- due to solar flares -- in storage or
>> transit, but do not mitigate against malicious package modification to
>> packages in storage or transit.
>>
>> AFAIU, TUF (The Update Framework) has a mechanism for limiting which
>> signing keys are valid for which package? Are pre-shared keys then still
>> necessary, or do we then rely on a PKI where one compromised CA cert can
>> then forge any other cert?
>>
>
> Yes, you are right, the hashes need to be signed: otherwise you have
> integrity, but no authenticity.
>
> We wrote PEPs 458  and 480
>  to discuss how TUF might be
> deployed on PyPI / Warehouse. The PEPs go into details about public key
> distribution. The TLDR is that is that clients (i.e., pip) need to be
> shipped with one self-signed root metadata file, and the rest of the PKI is
> bootstrapped from there. PyPI would act as an authority that distributes,
> revokes, and replaces public keys for packages.
>
> More details on security vs usability also available in our Diplomat
> 
> paper.
>
> If the community is interested, we'd love to discuss how we could help
> make this happen.
>
> Thanks,
> Trishank
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[alex . gronholm]

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 TOFU model, but less security
> > than other imaginable public key systems. The idea was that it
> > could provide more security in practice because the signatures
> > could exist and be present with the archive, unlike gpg which
> > provides loads of security in theory only. Unfortunately wheel
> > signatures were never built up. I don't think anyone was tricked
> > into believing the primitive provided security on its own.
> 
> 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 -- due to solar flares -- in
> storage or transit, but do not mitigate against malicious package
> modification to packages in storage or transit.

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?
> AFAIU, TUF (The Update Framework) has a mechanism for limiting which
> signing keys are valid for which package? Are pre-shared keys then
> still  necessary, or do we then rely on a PKI where one compromised
> CA cert can then forge any other cert?
> https://theupdateframework.github.io/ 
> > On Thu, Mar 22, 2018 at 2:21 PM Nathaniel Smith ared
> > wrote:
> > > 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 blog post. I know updating PEPs isn't
> > > the most common thing, but it's the main documentation of the
> > > wheel format and it'll save confusion later.
> > > 
> > > On Mar 22, 2018 10:57 AM, "Wes Turner" 
> > > wrote:
> > > > 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.
> > > > 
> > > > On Thursday, March 22, 2018, Nick Coghlan 
> > > > wrote:
> > > > > 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 removed from the PEP
> > > > > > entirely.
> > > > > 
> > > > > Cool, that's what I thought you meant, but I figured I should
> > > > > double check since our discussion was a while ago now :)
> > > > > 
> > > > > Cheers,
> > > > > Nick.
> > > > > 
> > > > > ___
> > > > > Distutils-SIG maillist  -  Distutils-SIG@python.org
> > > > > https://mail.python.org/mailman/listinfo/distutils-sig___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Justin Cappos]

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 set of
pre-shared metadata means you can securely obtain the rest of the
software.  (I'm happy to go into more detail, but wanted to avoid this
becoming a barrage of TUF details unless everyone is interested.)

If you don't want to ship the metadata with the tool, you can also have it
work in a trust-on-first-use model.  This is what Docker does in their
deployment of TUF.

On Thu, Mar 22, 2018 at 4:40 PM, Wes Turner  wrote:

>
>
> 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
>> key systems. The idea was that it could provide more security in practice
>> because the signatures could exist and be present with the archive, unlike
>> gpg which provides loads of security in theory only. Unfortunately wheel
>> signatures were never built up. I don't think anyone was tricked into
>> believing the primitive provided security on its own.
>>
>
> 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 -- due to solar flares -- in storage or
> transit, but do not mitigate against malicious package modification to
> packages in storage or transit.
>
> AFAIU, TUF (The Update Framework) has a mechanism for limiting which
> signing keys are valid for which package? Are pre-shared keys then still
> necessary, or do we then rely on a PKI where one compromised CA cert can
> then forge any other cert?
>
> https://theupdateframework.github.io/
>
>
>>
>> On Thu, Mar 22, 2018 at 2:21 PM Nathaniel Smith ared
>> wrote:
>>
>>> 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 blog post. I know updating PEPs isn't the most common thing, but
>>> it's the main documentation of the wheel format and it'll save confusion
>>> later.
>>>
>>> On Mar 22, 2018 10:57 AM, "Wes Turner"  wrote:
>>>
 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.

 On Thursday, March 22, 2018, Nick Coghlan  wrote:

> 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 removed from the PEP entirely.
>>
>
> Cool, that's what I thought you meant, but I figured I should double
> check since our discussion was a while ago now :)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>

 ___
 Distutils-SIG maillist  -  Distutils-SIG@python.org
 https://mail.python.org/mailman/listinfo/distutils-sig

 ___
>>> Distutils-SIG maillist  -  Distutils-SIG@python.org
>>> https://mail.python.org/mailman/listinfo/distutils-sig
>>>
>>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Trishank Kuppusamy]

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 -- due to solar flares -- in storage or
> transit, but do not mitigate against malicious package modification to
> packages in storage or transit.
>
> AFAIU, TUF (The Update Framework) has a mechanism for limiting which
> signing keys are valid for which package? Are pre-shared keys then still
> necessary, or do we then rely on a PKI where one compromised CA cert can
> then forge any other cert?
>

Yes, you are right, the hashes need to be signed: otherwise you have
integrity, but no authenticity.

We wrote PEPs 458  and 480
 to discuss how TUF might be
deployed on PyPI / Warehouse. The PEPs go into details about public key
distribution. The TLDR is that is that clients (i.e., pip) need to be
shipped with one self-signed root metadata file, and the rest of the PKI is
bootstrapped from there. PyPI would act as an authority that distributes,
revokes, and replaces public keys for packages.

More details on security vs usability also available in our Diplomat

paper.

If the community is interested, we'd love to discuss how we could help make
this happen.

Thanks,
Trishank
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Wes Turner]

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
> key systems. The idea was that it could provide more security in practice
> because the signatures could exist and be present with the archive, unlike
> gpg which provides loads of security in theory only. Unfortunately wheel
> signatures were never built up. I don't think anyone was tricked into
> believing the primitive provided security on its own.
>

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 -- due to solar flares -- in storage or
transit, but do not mitigate against malicious package modification to
packages in storage or transit.

AFAIU, TUF (The Update Framework) has a mechanism for limiting which
signing keys are valid for which package? Are pre-shared keys then still
necessary, or do we then rely on a PKI where one compromised CA cert can
then forge any other cert?

https://theupdateframework.github.io/


>
> On Thu, Mar 22, 2018 at 2:21 PM Nathaniel Smith ared wrote:
>
>> 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 blog post. I know updating PEPs isn't the most common thing, but
>> it's the main documentation of the wheel format and it'll save confusion
>> later.
>>
>> On Mar 22, 2018 10:57 AM, "Wes Turner"  wrote:
>>
>>> 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.
>>>
>>> On Thursday, March 22, 2018, Nick Coghlan  wrote:
>>>
 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 removed from the PEP entirely.
>

 Cool, that's what I thought you meant, but I figured I should double
 check since our discussion was a while ago now :)

 Cheers,
 Nick.

 --
 Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia

>>>
>>> ___
>>> Distutils-SIG maillist  -  Distutils-SIG@python.org
>>> https://mail.python.org/mailman/listinfo/distutils-sig
>>>
>>> ___
>> Distutils-SIG maillist  -  Distutils-SIG@python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Daniel Holth]

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
because the signatures could exist and be present with the archive, unlike
gpg which provides loads of security in theory only. Unfortunately wheel
signatures were never built up. I don't think anyone was tricked into
believing the primitive provided security on its own.

On Thu, Mar 22, 2018 at 2:21 PM Nathaniel Smith  wrote:

> 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 blog post. I know updating PEPs isn't the most common thing, but
> it's the main documentation of the wheel format and it'll save confusion
> later.
>
> On Mar 22, 2018 10:57 AM, "Wes Turner"  wrote:
>
>> 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.
>>
>> On Thursday, March 22, 2018, Nick Coghlan  wrote:
>>
>>> 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 removed from the PEP entirely.

>>>
>>> Cool, that's what I thought you meant, but I figured I should double
>>> check since our discussion was a while ago now :)
>>>
>>> Cheers,
>>> Nick.
>>>
>>> --
>>> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>>>
>>
>> ___
>> Distutils-SIG maillist  -  Distutils-SIG@python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Nathaniel Smith]

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 blog post. I know updating PEPs isn't the most common thing, but
it's the main documentation of the wheel format and it'll save confusion
later.

On Mar 22, 2018 10:57 AM, "Wes Turner"  wrote:

> 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.
>
> On Thursday, March 22, 2018, Nick Coghlan  wrote:
>
>> 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 removed from the PEP entirely.
>>>
>>
>> Cool, that's what I thought you meant, but I figured I should double
>> check since our discussion was a while ago now :)
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>>
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[alex . gronholm]

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.
Removing mostly unused features helps reduce the effort required for
that. Ditto for the general code refactoring which I'm also planning on
doing.
> 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.
> 
> On Thursday, March 22, 2018, Nick Coghlan  wrote:
> > 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 removed from the PEP entirely.
> > 
> > Cool, that's what I thought you meant, but I figured I should
> > double check since our discussion was a while ago now :)
> > 
> > Cheers,
> > Nick.
> > ___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Wes Turner]

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.

On Thursday, March 22, 2018, Nick Coghlan  wrote:

> 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 removed from the PEP entirely.
>>
>
> Cool, that's what I thought you meant, but I figured I should double check
> since our discussion was a while ago now :)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PyPI support for linux_ppc64le

[Thomas Kluyver]

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
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Nick Coghlan]

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 removed from the PEP entirely.
>

Cool, that's what I thought you meant, but I figured I should double check
since our discussion was a while ago now :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[alex . gronholm]

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 significant resistance among the readers of this
> > mailing list. For those not involved in the previous discussion,
> > the
> > reasoning is that the codebase can be significantly simplified by
> > removing this rarely used feature whose practical value is
> > questionable
> > at best, given the lack of infrastructure for public key
> > distribution.
> 
> Clarifying the scope here: is this about removing the hashes from the
> RECORD file, or just about dropping the native support for injecting
> the RECORD.jws and/or RECORD.p7s file? I ask as both of those
> features are covered in the same section of PEP 427: https://www.pyth
> on.org/dev/peps/pep-0427/#signed-wheel-files
> 
> If it's just the latter, then I don't see any problem with that at
> all - the generated wheels will still be completely compliant with
> PEP 427, it's just that anyone that does want to sign RECORD will
> need to extract from the archive, sign it, then add the signature
> file back in.
> 
> Changing the format of RECORD would be a problem though, since it's a
> documented requirement that installers are expected to check those at
> installation time.
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 removed from the PEP entirely.
> 
> Cheers,
> Nick.
> 
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

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

[Nick Coghlan]

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 not involved in the previous discussion, the
> reasoning is that the codebase can be significantly simplified by
> removing this rarely used feature whose practical value is questionable
> at best, given the lack of infrastructure for public key distribution.
>

Clarifying the scope here: is this about removing the hashes from the
RECORD file, or just about dropping the native support for injecting the
RECORD.jws and/or RECORD.p7s file? I ask as both of those features are
covered in the same section of PEP 427:
https://www.python.org/dev/peps/pep-0427/#signed-wheel-files

If it's just the latter, then I don't see any problem with that at all -
the generated wheels will still be completely compliant with PEP 427, it's
just that anyone that does want to sign RECORD will need to extract from
the archive, sign it, then add the signature file back in.

Changing the format of RECORD would be a problem though, since it's a
documented requirement that installers are expected to check those at
installation time.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] TLS support policy & PyPI communications

[Donald Stufft]

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 up the amount of time the 
endpoint is down for the deprecated TLS versions. The ultimate goal being to 
have it be 100% unavailable prior to the final deadline (because we can give a 
good error messsge, once the dead line hits it will just be a crappy OpenSSL 
error). 

Sent from my iPhone

> On Mar 21, 2018, at 10:58 PM, Sumana Harihareswara  wrote:
> 
> PSF blogged last year
> https://pyfound.blogspot.com/2017/01/time-to-upgrade-your-python-tls-v12.html
> that
> 
>> The more crucial deadline comes June 30, 2018. On that date all remaining 
>> python.org sites, including PyPI, will no longer support TSL 1.0 and 1.1. 
>> Older Python versions that do not implement TLSv1.2 will be prohibited from 
>> accessing PyPI.
> 
> I asked Ernest W. Durbin III whether I ought to re-announce this to
> users in my PyPI announcements. He looked at our TLS trends/stats and
> told me we have a very very low proportion of traffic that will be
> affected when we shift over. Therefore, since it'll affect so few, I
> won't shout about TLS versions in my PyPI communications. Marking that
> here for the record.

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig