Repository navigation
Accept source-coordinate Swift PURLs in retention and denylist config #613
Description
Storage retention keys and denylist entries accept a Swift package as pkg:swift/{scope}/{name}, such as pkg:swift/apple/swift-nio, or as the stored form pkg:generic/swift-registry/{scope}.{name}, and refuse source coordinates such as pkg:swift/github.com/apple/swift-nio (swiftRetentionKey in internal/handler/swift.go, identify in internal/denylist/denylist.go, documented in docs/configuration.md).
Most Swift users reach a registry with .package(url:) dependencies and --replace-scm-with-registry, and which PURL they hold depends on the tool that produced it. SwiftPM 6.4's swift package generate-sbom (SE-0509) writes registry dependencies as pkg:swift/{scope}/{name} with no host. syft, Trivy, cdxgen, and SwiftPM itself for git dependencies write pkg:swift/github.com/apple/swift-nio, and GHSA keys Swift advisories as SwiftURL github.com/apple/swift-nio, so a denylist entry copied from an advisory is in the source form and is currently refused.
Both forms should be accepted. A source PURL can be mapped to its registry identity through the upstream's /identifiers?url= endpoint; Tuist returns apple.swift-nio for https://github.com/apple/swift-nio. The mapping can't be done offline, since Tuist lowercases identities and turns dots in repository names into underscores (groue.grdb_swift for github.com/groue/GRDB.swift).
#611 has the same question for proxy mirror input.
Activity
[-]Deprecate `pkg:swift/{scope}/{name}` for Swift registry identities in retention and denylist config[/-][+]Accept source-coordinate Swift PURLs in retention and denylist config[/+]simonchrz commentedon Oct 27, 2026
I'd like to take this as a follow-up to #611, reusing its
/identifierslookup (swiftIdentity,SwiftIdentityOf). Two questions before I start:Where should a source PURL be mapped?
pkg:swift/github.com/...entry through/identifiersand use the identity as today. Retention and denylist stay as they are, but startup needs the upstream.repositoryURLsagainst source entries. No lookup at startup, butrepositoryURLsis optional in the registry spec and doesn't help retention, which runs without a request.I'd go with (a) for both.
With (a), what should happen when an entry can't be resolved (upstream down, or no package for the URL)? For the denylist I'd refuse to start, since an entry that silently doesn't apply is a gap. For retention, a warning and retrying later seems enough.