1. 3

  2. 4

    (My take on this: yes, a downloaded package gets to run its own Swift code as part of installation, and that could do bad stuff. But don’t most package managers have the same vulnerability? There’s usually some sort of Turing-complete script that gets to run, with privileges to access the filesystem and load code … a makefile, Rakefile, whatever. Swift code can directly access GUI frameworks on a Mac, but any sort of makefile can build and run a small native binary that can do the same.)

    1. 1

      Compare and contrast with systems like Nix which have sandboxed builds and do not allow unfettered access to the filesystem or network.

      1. 2

        Mac OS has pretty robust sandboxing too; maybe they’ll apply that to the Swift package manager.

      2. 1

        Indeed, packages are used for the code that is in them, it is supposed to run. If not on installation, then later.

        But it becomes a problem in a context where nobody checks packages before using them. There are many package managers where the central repositories accept anything from anyone and there are no sanity checks. Sometimes a particular incident is highlighted and shared on sites like this, but few seem to want to fix the broken system that allowed the incident to occur in the first place.

      3. 3

        On the other hand, the only purpose of the package manager is to download turing complete bit of code which you put into your application.

        If you don’t trust the package description, why would you trust the package?

        There’s a whole other discussion about how to trust packages and their security. But that’s going to need deep language and api changes. Until then, it’s a matter of completely trusting a package or not using it.

        1. 4

          There’s a slight difference. If I’m building an iOS app, the package itself will only ever execute in the context of the iOS sandbox. The package manager is however executing as my user in XCode.