Instead of just allowing unsafe flags outright, could we have a parameter on the dependency, e.g. allowUnsafeFlags: true to opt in?
I do agree that some means for granular control are needed. The blanket removal of unsafeFlags restrictions makes arbitrary code execution via -B/--prefix even more dangerous, while the pitch doesn't seem to address this at all. Allowing unsafeFlags only on certain subset of trusted packages could be a viable approach.
I believe that's better addressed by sandboxing of the overall build.
On a related note, I'd like to point out one thing for which there is currently zero defense: depending on third party libraries which may inject code in your actual product using a static initializer or similar. I'm much more concerned about that versus executing arbitrary code during the build process.
Thus reinforcing my point about it being the developer's responsibility to review usage of their dependencies. That's the only true defense against these issues, without compromising the build system's ability to do its job by making it too limiting for real world configuration scenarios developers need to be able to express (hence this pitch).
How would such sandboxing be implemented on non-Darwin platforms?
Late feedback on the implementation details here: it looks like this currently disables the check retroactively for previously shipped tools-versions, but it seems like this should only happen for newer tools-versions to avoid backwards-compatibility issues?
Good point. This would cause packages with unsafe flags to fail to build when using older toolchains. Consumers of these packages do need to use 6.2 or greater. I'll take a look at that. Thanks!
Only enable unsafe flags if version 6.2 or newer. by dschaefer2 · Pull Request #8951 · swiftlang/swift-package-manager · GitHub puts the check back and guards it with a tools version of 6.2 or greater.
Also note that I've left in the scaffolding for unsafe flags checking in case we want to check for specific flags and mark the modules accordingly.