Removing wheel signing features from the wheel library
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.
If, as a result, there is a public outcry (which I sincerely doubt), I can always add it back to the next release.
On 22 March 2018 at 05:03, alex.gronholm@nextday.fi 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.
to, 2018-03-22 kello 21:44 +1000, Nick Coghlan kirjoitti:
On 22 March 2018 at 05:03, alex.gronholm@nextday.fi 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.
On 22 March 2018 at 22:35, alex.gronholm@nextday.fi 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.
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 ncoghlan@gmail.com wrote:
On 22 March 2018 at 22:35, alex.gronholm@nextday.fi 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 | ncoghlan@gmail.com | Brisbane, Australia
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 ncoghlan@gmail.com wrote:
On 22 March 2018 at 22:35, alex.gronholm@nextday.fi 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.
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" wes.turner@gmail.com 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 ncoghlan@gmail.com wrote:
On 22 March 2018 at 22:35, alex.gronholm@nextday.fi 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 | ncoghlan@gmail.com | Brisbane, Australia
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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 njs@pobox.com 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" wes.turner@gmail.com 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 ncoghlan@gmail.com wrote:
On 22 March 2018 at 22:35, alex.gronholm@nextday.fi 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 | ncoghlan@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
On Thursday, March 22, 2018, Daniel Holth dholth@gmail.com 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 njs@pobox.comared 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" wes.turner@gmail.com 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 ncoghlan@gmail.com wrote:
On 22 March 2018 at 22:35, alex.gronholm@nextday.fi 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 | ncoghlan@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
Hi Wes,
On Thu, Mar 22, 2018 at 4:40 PM, Wes Turner wes.turner@gmail.com 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 https://www.python.org/dev/peps/pep-0458/ and 480 https://www.python.org/dev/peps/pep-0480/ 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 https://www.usenix.org/conference/nsdi16/technical-sessions/presentation/kuppusamy paper.
If the community is interested, we'd love to discuss how we could help make this happen.
Thanks, Trishank
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 wes.turner@gmail.com wrote:
On Thursday, March 22, 2018, Daniel Holth dholth@gmail.com 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 njs@pobox.comared 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" wes.turner@gmail.com 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 ncoghlan@gmail.com wrote:
On 22 March 2018 at 22:35, alex.gronholm@nextday.fi 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 | ncoghlan@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
On Thursday, March 22, 2018, Justin Cappos jcappos@nyu.edu 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 wes.turner@gmail.com wrote:
On Thursday, March 22, 2018, Daniel Holth dholth@gmail.com 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 njs@pobox.comared 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" wes.turner@gmail.com 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 ncoghlan@gmail.com wrote:
On 22 March 2018 at 22:35, alex.gronholm@nextday.fi 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 | ncoghlan@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
to, 2018-03-22 kello 16:40 -0400, Wes Turner kirjoitti:
On Thursday, March 22, 2018, Daniel Holth dholth@gmail.com 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 njs@pobox.comared 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" wes.turner@gmail.com 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 ncoghlan@gmail.com wrote:
On 22 March 2018 at 22:35, alex.gronholm@nextday.fi 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
On Thursday, March 22, 2018, alex.gronholm@nextday.fi wrote:
to, 2018-03-22 kello 16:40 -0400, Wes Turner kirjoitti:
On Thursday, March 22, 2018, Daniel Holth dholth@gmail.com 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 njs@pobox.comared 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" wes.turner@gmail.com 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 ncoghlan@gmail.com wrote:
On 22 March 2018 at 22:35, alex.gronholm@nextday.fi 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
On Thu, Mar 22, 2018, at 9:25 PM, alex.gronholm@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.
to, 2018-03-22 kello 21:56 +0000, Thomas Kluyver kirjoitti:
On Thu, Mar 22, 2018, at 9:25 PM, alex.gronholm@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.
If someone wanted to make a malicious file, what's preventing them from modifying the RECORD to match the modified file when there is no cryptographic signing involved?
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
On Fri, Mar 23, 2018, at 6:56 AM, alex.gronholm@nextday.fi wrote:
If someone wanted to make a malicious file, what's preventing them from modifying the RECORD to match the modified file when there is no cryptographic signing involved?
Right: you need a way to verify RECORD on top of that. Like the signatures, or way to distribute hashes of RECORD files separately. The hashes in RECORD are a foundation for building security systems, not a security system in themselves. Thomas
participants (8)
-
alex.gronholm＠nextday.fi -
Daniel Holth -
Justin Cappos -
Nathaniel Smith -
Nick Coghlan -
Thomas Kluyver -
Trishank Kuppusamy -
Wes Turner