I'm trying not to hijack the thread too badly, but sure, a build server is a similar niche to the package index I mentioned above, and I can understand the concern in those edge cases. As for CI servers, I thought that testing was a major part of CI, so you're back in approximately the same situation with respect to trusting (or not trusting) the source of the package, regardless of whether the package manifest itself is executed.
The replies in this thread are worrying, to say the least. Baffled to see so many people dismissing the fact that parsing Swift PM manifests means allowing arbitrary code execution, regardless of whether it's in a sandbox.
Anyway, according to this document, Swift PM manifests only accept a subset of Swift. This puts my mind somewhat at ease. I'm surprised no one mentioned it (and if someone did, I must have overlooked it).
Edit: if this is not how SPM manifests are currently implemented, then I'm still worried.
2 Likes
Unfortunately that’s not how it works currently.
1 Like
Huh?
It would be a fun project to formalize a subset of Swift for use as a configuration language that's guaranteed to have no side effects and terminate, along the lines of Dhall (GitHub - dhall-lang/dhall-haskell: Maintainable configuration files), which would give you most of the benefits of a programmable configuration language without the risks of running arbitrary code.
11 Likes