Swift Package Registry Service - Security

[mattt]

@lukasa

Thanks for starting this new thread @mattt, I think it's definitely worth pressing on this issue to get something in really great shape. I'm also thrilled to see that Filippo and Katie have reached out to chat about what's going on in their own community: both Filippo and Katie are well qualified to talk about this issue and their opinions are extremely valuable.

I'm so glad to hear that, @lukasa. Thanks again for pushing me to reconsider what was, admittedly, a "color by numbers" decision on my part, adopting what I understood at the time to be a "best practice" (but turned out to be more of an anti-pattern).

Talking to Filippo and Katie and security folks in GitHub has definitely been a highlight of this project so far. I'm very thankful for their generosity and willingness to help solve these important problems of supply chain security.

@lukasa

The idea of using Git as the baseline for implementing the transparency log is also interesting and worth investigating. We should carefully consider the tradeoffs, and whether adding Git as a dependency here provides more value than it costs in complexity. For my part (with my cryptography engineer hat on) I'll say that I suspect using Git for this adds more complexity than we need, but I'm certainly open to being talked around on the matter.

What I like about Git is its ubiquity. Most Swift developers use Git everyday, and this familiarity imparts a kind of essential obviousness. Many of us know first-hand what happens when someone else force pushes to master / main to rewrite history. A custom solution may be better, both operationally and cryptographically, but it would have to build trust and consensus from scratch.

By way of analogy, it's like a magician walking into a Walmart and buying a sealed deck of cards before doing a card trick, or walking into a Walmart and purchasing a cheap laptop to be used in a cryptocurrency ceremony, or voting on a paper ballot instead of a machine (though this comparison would be quite uncharitable, given the proven insecurity of electronic voting, at least in America).

One last note about Git, because this isn't clear from my first post: For the purposes of the registry specification, any decision to use Git as a transparency log would be an implementation detail rather than a requirement. I'd want to abstract this through an API like how the Go checksum does with log tiles.

@lukasa

As for TUF, I know much less about TUF than I do about transparency logs. I'm vaguely aware of it from discussions with Donald Stufft about PyPI, which has been interested in TUF for a long time. However, I don't think they've made forward progress on it.

I do think that if we felt that a transparency log provided insufficient guarantees, we should investigate TUF as the next logical step in preference to PGP. I'll do some more reading on TUF and try to form a more educated opinion.

The complexity of TUF is my biggest concern. I know of at least a few language ecosystems, including RubyGems have struggled to implement it. Speaking personally, I'm still not 100% on what a deployment looks like in practice. So yeah, please share your notes as you look into TUF — it'd be great to get a better handle on everything.

---

@FiloSottile Thanks again for helping out with this! Your and Katie's reputation, and of the Go team, generally, bring immense confidence and excitement to this process.

@FiloSottile

A quick note about the trust model: transparent logs are not simply TOFU on the client side, like SSH is, but are TOFU ecosystem-wide, which is a much stronger property. When the transparent log operator first fetches a specific release, they trust whatever fetching mechanism they use (like an HTTPS endpoint); then, they permanently and uniquely include the checksum in the log and no one will need to trust the fetching mechanism again. (Instead, they rely on the append-only properties of the log, proven by the inclusion and consistency proofs, and verified by the auditors.)

Oh, interesting! That's indeed an important distinction.

Just to make sure I'm following correctly, would this property hold under Swift's slightly different model? Whereas Go (as I understand it) creates new releases the first time they're requested, our proposed system requires authors to publish releases to a registry before others can pull them in as dependencies. Here's the scenario I'd imagined:

• Mona publishes mona/LinkedList version 1.2.1 to GitHub.com
• The registry adds the checksum for mona/LinkedList 1.2.1 to its transparent log
• Alice is MitM'd by Mallory, who intercepts all HTTPS traffic to to Github.com — including package registry endpoints and the transparent log repository
• Alice installs mona/LinkedList the first time
• Mallory sends a forged package and checksum to Alice
• Alice commits the forged checksum in Package.resolved
• Bob pulls Alice's changes and tries to install mona/LinkedList, but gets a checksum mismatch error

If Mallory could also attack Carol and David in the same way, would we be able to claim that stronger stronger TOFU property? (Apologies if I'm missing something here. I'm sure I'll figure it out after rewatching Katie's talk you linked to)

@FiloSottile

A core difference between transparent logs and TUF is that the latter only delivers stronger security if it's deployed in "PEP 480" mode (the Secure Systems Lab article you linked does a good job explaining the difference), where individual software authors have to manage their own keys, which is a significant security and usability hurdle.

That does sound challenging. Are there any deployments of TUF that you'd point to as good examples of what to do? I was especially interested to see if anyone was taking the approach that article describes under "Getting the best of both worlds".