[Amendment] SE-0291: Package Collection Signing

Review for an amendment to SE-0291: Package Collections, begins now and runs through February 26, 2021.

The amendment was requested by the core team to reflect the security model for package collections as discusses in a recent discussion thread on the topic. The goal of the amendment is to provide transparency and document that security model.

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager or direct message in the Swift forums).

What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.

When reviewing a proposal, here are some questions to consider:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Thank you for helping improve the Swift programming language and ecosystem.

Tom Doron
Review Manager


This feels like we are only going to be using this while registries are not finalized yet and if that is the case then the proposal should state that. Otherwise if this is an alternative long term solution for registries then I feel this should be a new proposal that encompasses some form of root cert management (perhaps as part of Swift Package Manager) in at least one more platform that is able to understand OS shipped root certs (For example windows has a clear story for root certs)

The text says that signing is optional for the publishers and then goes on to say that a publisher can enforce signing onto consumers.

Is “signature stripping” an attack vector if the collection is served via TLS/SSL?

  1. Restrict what certificate can be used for signing - this defends against "signature replacement".

I am assuming root certificates here. Could the authors list one or two other certificate authorities or cloud providers that offer the requirements as Apple dev signing certificates?

The process will involve submitting a pull request to modify SwiftPM certificate pinning configuration.

An example here would be great.

Overall +1 for more security features.

Package collections and package registries serve different purposes as we try to explain in the proposal's Introduction section.

Signing is optional. However, if publishers opt to sign their collection and want to make sure that "not only the collection is signed, it's really signed by them", they can do that through certificate pinning configuration. It's a way for publishers to protect the contents they create.

The server where a collection is hosted can be hacked and TLS/SSL wouldn't help in this case.

Here we are talking about certificates used for signing, so they are actually leaf certificates. An example of a restriction would be requiring leaf certificate's subject user ID to match a specific value. It could also check for specific OID or certificate chain.

There will be documentation on this in the SwiftPM repo later, but the idea is that the configuration is a source file in SwiftPM where publishers define the restricting conditions (examples given above) for their signing certificates.

1 Like

I'm not surprised but still quite disappointed about ~/.swiftpm, especially as this comes from Apple itself. MacOS had a long tradition in fighting against dotfile-creep, so it's sad that we fall back to this hack. On the Mac, there is the well established ~/Library/, and even Linux nowadays has the XDG Base Directory Specification, so Swift won't be a good citizen on neither platform.

It's only a small detail, but passion for detail and courage to break with bad habits has once been part of Apples DNA :frowning:


@Tino that is a fair point, and it carries its own tradeoffs. Please consider spinning up a separate pitch/proposal focused on how Swift tooling should handle user-level configuration and cache locations, perhaps we can come up with a better solution across the various platforms we support.

1 Like

SE-0291 Package Collection Signing amendment has been accepted. If you'd like to continue discussing this, please do so in that thread.

Terms of Service

Privacy Policy

Cookie Policy