[PITCH] Support for binary dependencies

This summary is exactly why I think it's wrong to think of allowsBinary as a security feature and design it with that in mind. If you're going to audit every update to every part of your dependency graph then you'll be well aware of any added dependencies, because you'll have to audit them too. In the much more likely situation where you're not going to do that, whether the malware is in a binary or the source code is essentially irrelevant. You need to trust your dependencies for better reasons than the source being theoretically, but not practically, inspectable. Consider all the unintentionally introduced security issues that survive for years or decades in open source software.

2 Likes

I don't quite understand how moving the opt-in to a configuration file solves this in the general case. Each package needs to be able to work and be tested in isolation, so now the author has to add the new binary to the configuration file of every package in the chain. That seems like a very similar burden to me.

Sorry if I wasn't clear enough -- I don't mean that the whitelist should be global to the user's machine, I meant that the whitelist should apply to the entire dependency graph of a specific root package. The config file is stored at .swiftpm/config in your repository's root directory (again, see SE-0219).

Is that what you were concerned about? I can update my post to try and clarify.

It distributes the load better.

With the allowsBinary flag, for A => B => C => D => E where E adds a dependency on binary package F, E must add the flag, followed by D, followed by C, followed by B, finally followed by A.

With the whitelist approach, if E adds the dependency on binary package F and the new version of E is compatible with the version constraints in the package dependency graph, A can begin using it immediately, without B, C, D having to do anything. That's very valuable.

Think of it in terms of a dependency graph; this allows better "parallelization" of effort.

Ah right, that makes sense.

I think I would prefer the whitelist to be on a binary artifact vs. a package basis, though, since one package can have multiple binary targets. Maybe it could even be combined with my idea of using URL prefix matches for opt-ins, such that one can optionally trust all binaries coming from a certain domain.

Yes, I like that.

Do we want to require that the binary artifacts always come from a remote URL, though? What if a developer wants to store the binary artifact inside the binary package's repo and reference it using a relative path? Whitelisting becomes a little more complicated if that is possible.

Not quite sure, the current proposal requires it, but I was actually thinking it might be good to also allow referencing artifacts from the repository. I don't think anyone has brought it up as something they would like to see on the thread so far.

That clears it. Thanks!

If we do, it would make whitelisting more complicated since you'd need to tie that relative path to the package identity somehow.

@rballard and me discussed the opt-in part of this proposal and came to the following observations:

  • It is true that strictly speaking there is no difference between binary and source dependencies in terms of trust, as some folks on this thread also commented. This makes a per binary packages opt-in during development time less important
  • The difference between having zero vs. any binary dependencies is still significant, for example it will be harder to port the package to a new platform if there are any binary dependencies. Because of this, it would make sense to offer package authors a way to opt-out of binary packages wholesale in order to not add a transitive dependency on one accidentally. It warrants further discussion to figure out whether this is better suited to manifest API or a separate configuration option. There might also be a case to be made to make developers opt-in to binary packages once instead.
  • Increasing the visibility of binary packages being used is still a worthwhile problem to solve, but it can be tackled as a workflow feature by tools built on top off libSwiftPM and doesn't have to be part of this proposal.
2 Likes
Terms of Service

Privacy Policy

Cookie Policy