1. 20
  1. 16

    Says a pseudonymous subscriber to Ars Technica:

    But everyone who says “check every library” has never actually tried to do it, or they work in a well financed company. Not everyone is coding in those situations.

    nixpkgs checks every library in the Python subsystem. Curiously, this is because Python’s got some systemic flaws:

    • PyPI doesn’t export enough metadata for nixpkgs contributors to automatically import package definitions, as with Haskell’s Stackage
    • Python packaging requires running a setup.py file, assuming wrongly that site-packages is global/unique/writeable, pip is invokable, or other violations of Nix’s sandbox; so nixpkgs contributors usually must hand-patch setup.py or avoid running it at all
    • pip and other tools support “extra” optional dependencies, but Nix does not; nixpkgs contributors usually must enumerate every Python dependency and explicitly configure flags to control extras
    • PEP 427 binary wheels aren’t independent of filesystem layout, so nixpkgs contributors usually must build Python packages from source and link them against Nix-packaged libraries
    1. 6

      This is a serious comment: I think you should try to submit a PEP that tackles these. I think a lot of package maintainers (myself included) would be very happy to follow a spec that makes packaging and distribution easier

      1. 4

        this is because Python’s got some systemic flaws

        All of these “systemic flaws” appear to boil down to “does not work the precise way Nix wants it to”.

      2. 3

        Rust has crev, which is trying to solve this in an interesting, decentralized way: https://github.com/crev-dev/cargo-crev

        I’m not aware of it being used outside of rust, but it should in theory be doable easy enough.

        1. 2

          There is pip-crev but it’s young

        2. 3

          Seems the disclosure could’ve been better: https://twitter.com/EWDurbin/status/1407338761114066946

          1. 5

            Eh. I think is a case where delaying public disclosure would not help anyone, so it’s not worth yelling at anybody over.

            There isn’t a specific vulnerability to patch here and the malware is already there.

            1. 2

              That’s not what I said though. There’s a difference between “disclosure”, preparing a completely fleshed out blog post, and maybe even putting a little effort into contacting the right people. Sure, maybe they wrote their blog post (and the ars article?) very quickly, but full disclosure 4h! after sending mail to the wrong address is a bit weird. Especially if you’re then trying to argue that you did contact the responsible party.

              1. 1

                Oh right. Sure, failing to bother to get the right email for pypi’s security team is embarrassingly poor.

          2. 2

            This is made especially dangerous as you could reasonably and easily bitsquat this domain.

            Then your package and instructions can be completely correct but a bitflip due to lack of ECC could cause you to download malicious packages.