Thank you for putting together this resource. For the past year, I've been working on a proposal to add a registry to Swift Package Manager, and I found the information in this project helpful as I considered how that should work.
I'm happy to report that the new registry interface promises to substantially improve the security and reliability story for Swift Package Manager (both immediately, and in follow-up proposals building on top of the original).
In the meantime, I wanted to contribute to this project by offering corrections or clarifications to some details in the current report:
Security Contacts and Process
To satisfy this requirement, the package manager must have a way to receive security information from the community and a process for handling such feedback. A published email such as security@, together with a mechanism to ensure that the feedback is captured and responded to would satisfy this requirement.
The majority of Swift packages (>99.9%) are hosted on GitHub. Some packages define a security policy on GitHub (for example, see @Flight-School/Money).
This is currently listed as No. If we follow the same criteria as we do for MFA, should this be updated to Optional with a comment?
Code Signing
It should be possible for developers to sign their code. When they do, the package manager should verify the signatures and provide a way for those to be distributed to consumers of the package.
This is currently listed as Yes (that is, it doesn't run code). Should this entry be updated to No or something else?
Integrity verification
Package manager provides a method for verifying the integrity of the downloaded package.
None - no integrity verification is done Partial - integrity verification is done using a weak method* Yes - Verification is done using a sufficiently secure method
Integrity verification is offered for binary artifacts, using SHA256. Conventional, source-based dependencies don't currently offer any integrity verification functionality.
This isn't currently listed for Swift Package Manager. Should this entry be set to No, Partial, or something else?
Thank you for putting together this resource. For the past year, I've been working on a proposal to add a registry to Swift Package Manager, and I found the information in this project helpful as I considered how that should work.
I'm happy to report that the new registry interface promises to substantially improve the security and reliability story for Swift Package Manager (both immediately, and in follow-up proposals building on top of the original).
In the meantime, I wanted to contribute to this project by offering corrections or clarifications to some details in the current report:
The majority of Swift packages (>99.9%) are hosted on GitHub. Some packages define a security policy on GitHub (for example, see @Flight-School/Money).
This is currently listed as No. If we follow the same criteria as we do for MFA, should this be updated to Optional with a comment?
Swift Package Manager has built-in support for code-signed binary artifacts.
This is currently listed as No. Should this be updated to Partial with a comment?
In fact, Swift Package Manager does evaluate package manifests. On macOS, it's run through a sandboxed process (
sandbox-exec) to mitigate the effects of arbitrary code execution (see https://github.com/apple/swift-package-manager/blob/4bef41f12f082d55a4cb979a489379bfcf69f0c7/Sources/PackageLoading/ManifestLoader.swift#L776).This is currently listed as Yes (that is, it doesn't run code). Should this entry be updated to No or something else?
Integrity verification is offered for binary artifacts, using SHA256. Conventional, source-based dependencies don't currently offer any integrity verification functionality.
This isn't currently listed for Swift Package Manager. Should this entry be set to No, Partial, or something else?