7 ms·

Could someone explain why this is important? My uninformed feeling towards PEP 740 is 'who cares?'.

by marky1991 2y ago

rty32 2y ago
https://en.m.wikipedia.org/wiki/XZ_Utils_backdoor https://en.m.wikipedia.org/wiki/XZ_Utils_backdoor
- marky1991 2y ago
  But that involved one of the developers of said package committing malicious code and it being accepted and then deployed. How would this prevent that from happening? I thought this was about ensuring the code that developers pushed is what you end up downloading.
  - rty32 2y ago
    No, part of the malicious code is in test data file, and the modified m4 file is not in the git repo. The package signed and published by Jia Tan is not reproducible from the source and intentionally done that way. You might want to revisit the script of xz backdoor.
    - epcoa 2y ago
      An absolutely irrelevant detail here. While there was an additional flourish of obfuscation of questionable prudence, the attack was not at all dependent on that. It’s a library that justifies all kinds of seemingly innocuous test data. There were plenty of creative ways to smuggle in selective backdoors to the build without resorting to a compromised tar file. The main backdoor mechanism resided in test data in the git repo, the entire compromise could have.
hadlock 2y ago
I believe this is a system where a human/system builds a package and uploads and cryptographically signs it, verifying end to end that the code uploaded to github for widget-package 3.2.1 is the code you're downloading to your laptop for widget-package 3.2.1 and there's no chance it is modified/signed by a adversarial third party
- marky1991 2y ago
  That's my understanding also, but I still feel like 'who cares' about that attack scenario. Am I just insufficiently paranoid? Is this kind of attack really likely? (How is it done, other than evil people at pypi?)
  - OutOfHere 2y ago
    Yes, it is likely. It is done by evil intermediaries on hosts that are used to create and upload the package. It is possible for example if the package is created and uploaded on the developer laptop which is compromised. --- From the docs: > PyPI's support for digital attestations defines a strong and verifiable association between a file on PyPI and the source repository, workflow, and even the commit hash that produced and uploaded the file.
    - abotsis 2y ago
      It still doesn’t protect against rogue commits to packages by bad actors. Which, IMO, is the larger threat (and one that’s been actively exploited). So while a step in the right direction, it certainly doesn’t completely solve the supply chain risk.
      - MattPalmer1086 2y ago
        I'm not sure there is any way to completely solve supply chain risk. All you can do is raise the bar for a successful attack. Right now, we hardly have any controls at all.
    - mikepurvis 2y ago
      It’s honestly a bit nuts that in 2024 a system as foundational as PyPI just accepts totally arbitrary, locally built archives for its “packages”. I appreciate that it’s a community effort and compute isn’t free, but Launchpad did this correctly from the very beginning — dput your signed dsc and it will build and sign binary debs for you.
darkamaul 2y ago
Supply chain attacks can exploit gaps between source code and distributed packages. Today, if PyPI were to be compromised, attackers could serve malicious packages even if the source code is clean. Attestations provide cryptographic proof linking published packages to specific code states. This proof can be verified independently of PyPI - reducing exclusive trust in the package index. Worth noting, attestations aren't a complete defense against index compromises since an attacker could simply stop serving attestations (though this would raise alerts for users monitoring their dependencies' attestation status). Is this a silver bullet? No. If an attacker compromises a project's source repository, attestations won't help. However, it meaningfully reduces certain attack vectors and moves us towards being able to cryptographically verify the entire chain from source code to deployed package. (Disclaimer: I helped build this feature for PyPI)
- amelius 2y ago
  > Is this a silver bullet? No. If an attacker compromises a project's source repository, attestations won't help. But that's a huge attack surface.
  - MattPalmer1086 2y ago
    And one that needs a different solution. Update: That a control doesn't solve all problems is irrelevant. By that measure, we would have no controls at all.
    - amelius 2y ago
      > And one that needs a different solution. Does the community have any ideas about that?
      - MattPalmer1086 2y ago
        If you're asking how we can prevent people breaking in to a source code repository, the answer is mostly just the same as anything. Patch, apply principle of least privilege, make sure everyone uses strong authentication. Monitor the system. For SCM specific controls we could also require signed commits, apply branch protection and any other system specific controls, and enforce code reviews before commit.
deleted 2y ago
[deleted]

Could someone explain why this is important? My uninformed feeling towards PEP 740 is 'who cares?'.

rty32 2y ago

https://en.m.wikipedia.org/wiki/XZ_Utils_backdoor https://en.m.wikipedia.org/wiki/XZ_Utils_backdoor

marky1991 2y ago
But that involved one of the developers of said package committing malicious code and it being accepted and then deployed. How would this prevent that from happening? I thought this was about ensuring the code that developers pushed is what you end up downloading.
- rty32 2y ago
  No, part of the malicious code is in test data file, and the modified m4 file is not in the git repo. The package signed and published by Jia Tan is not reproducible from the source and intentionally done that way. You might want to revisit the script of xz backdoor.
  - epcoa 2y ago
    An absolutely irrelevant detail here. While there was an additional flourish of obfuscation of questionable prudence, the attack was not at all dependent on that. It’s a library that justifies all kinds of seemingly innocuous test data. There were plenty of creative ways to smuggle in selective backdoors to the build without resorting to a compromised tar file. The main backdoor mechanism resided in test data in the git repo, the entire compromise could have.

hadlock 2y ago

I believe this is a system where a human/system builds a package and uploads and cryptographically signs it, verifying end to end that the code uploaded to github for widget-package 3.2.1 is the code you're downloading to your laptop for widget-package 3.2.1 and there's no chance it is modified/signed by a adversarial third party

marky1991 2y ago
That's my understanding also, but I still feel like 'who cares' about that attack scenario. Am I just insufficiently paranoid? Is this kind of attack really likely? (How is it done, other than evil people at pypi?)
- OutOfHere 2y ago
  Yes, it is likely. It is done by evil intermediaries on hosts that are used to create and upload the package. It is possible for example if the package is created and uploaded on the developer laptop which is compromised. --- From the docs: > PyPI's support for digital attestations defines a strong and verifiable association between a file on PyPI and the source repository, workflow, and even the commit hash that produced and uploaded the file.
  - abotsis 2y ago
    It still doesn’t protect against rogue commits to packages by bad actors. Which, IMO, is the larger threat (and one that’s been actively exploited). So while a step in the right direction, it certainly doesn’t completely solve the supply chain risk.
    - MattPalmer1086 2y ago
      I'm not sure there is any way to completely solve supply chain risk. All you can do is raise the bar for a successful attack. Right now, we hardly have any controls at all.
  - mikepurvis 2y ago
    It’s honestly a bit nuts that in 2024 a system as foundational as PyPI just accepts totally arbitrary, locally built archives for its “packages”. I appreciate that it’s a community effort and compute isn’t free, but Launchpad did this correctly from the very beginning — dput your signed dsc and it will build and sign binary debs for you.

darkamaul 2y ago

Supply chain attacks can exploit gaps between source code and distributed packages. Today, if PyPI were to be compromised, attackers could serve malicious packages even if the source code is clean. Attestations provide cryptographic proof linking published packages to specific code states. This proof can be verified independently of PyPI - reducing exclusive trust in the package index. Worth noting, attestations aren't a complete defense against index compromises since an attacker could simply stop serving attestations (though this would raise alerts for users monitoring their dependencies' attestation status). Is this a silver bullet? No. If an attacker compromises a project's source repository, attestations won't help. However, it meaningfully reduces certain attack vectors and moves us towards being able to cryptographically verify the entire chain from source code to deployed package. (Disclaimer: I helped build this feature for PyPI)

amelius 2y ago
> Is this a silver bullet? No. If an attacker compromises a project's source repository, attestations won't help. But that's a huge attack surface.
- MattPalmer1086 2y ago
  And one that needs a different solution. Update: That a control doesn't solve all problems is irrelevant. By that measure, we would have no controls at all.
  - amelius 2y ago
    > And one that needs a different solution. Does the community have any ideas about that?
    - MattPalmer1086 2y ago
      If you're asking how we can prevent people breaking in to a source code repository, the answer is mostly just the same as anything. Patch, apply principle of least privilege, make sure everyone uses strong authentication. Monitor the system. For SCM specific controls we could also require signed commits, apply branch protection and any other system specific controls, and enforce code reviews before commit.

deleted 2y ago

[deleted]