Why is this new PURL type needed?
Ansible collections are a widely-used packaging format for distributing Ansible content (modules, plugins, roles, playbooks). Collections can be installed from multiple sources:
- Ansible Galaxy (galaxy.ansible.com) - the default public repository
- Red Hat Automation Hub (console.redhat.com/api/automation-hub) - certified/supported collections
- Git repositories - direct installation from VCS
- URLs/tarballs - direct download
- System packages - RPM/deb distribution
Currently, there is no standard way to identify Ansible collections in SBOMs or vulnerability databases. A dedicated PURL type enables accurate identification across all installation sources.
What input do you have from the relevant package ecosystem/community?
- I am contributing a corresponding change to ansible-core that writes a
source.json metadata file during ansible-galaxy collection install, enabling scanners to generate correct PURLs. This PR will be submitted to https://github.com/ansible/ansible (I will update the issue to with the corresponding PR. )
- The design aligns with how Ansible collections are identified internally:
namespace.name format (e.g., cisco.aci, community.general)
What are the PURL component level definitions?
| Component |
Requirement |
Description |
| namespace |
Required |
Collection namespace (e.g., cisco in cisco.aci). Lowercased. |
| name |
Required |
Collection name (e.g., aci in cisco.aci). Lowercased. |
| version |
Optional |
Semantic version from galaxy.yml/MANIFEST.json |
Qualifiers
| Qualifier |
Description |
repository_url |
Alternative Galaxy-compatible server (Automation Hub, private Galaxy) |
vcs_url |
VCS URL for git-sourced collections (e.g., git+https://github.com/org/repo.git@tag) |
download_url |
Direct tarball URL for URL-sourced collections |
packaging |
Distribution method for system packages (rpm, deb) |
Examples
pkg:ansible/community/general@6.0.0
pkg:ansible/cisco/aci@2.13.0
pkg:ansible/redhat/rhel_system_roles@1.20.0?repository_url=console.redhat.com%2Fapi%2Fautomation-hub
pkg:ansible/myorg/mycollection@1.0.0?vcs_url=git%2Bhttps%3A%2F%2Fgithub.com%2Fmyorg%2Fmycollection.git%40v1.0.0
pkg:ansible/ansible/posix@1.5.4?packaging=rpm
Are there any open questions about this new PURL type?
-
Galaxy vs Automation Hub: Both use the same Galaxy API protocol, so the internal source type is "galaxy" for both. The repository_url qualifier distinguishes them. Is this approach acceptable?
-
Artifact identity: The same collection artifact (identical checksum) may exist on both Galaxy and Automation Hub. The PURL identifies the download source.
Why is this new PURL type needed?
Ansible collections are a widely-used packaging format for distributing Ansible content (modules, plugins, roles, playbooks). Collections can be installed from multiple sources:
Currently, there is no standard way to identify Ansible collections in SBOMs or vulnerability databases. A dedicated PURL type enables accurate identification across all installation sources.
What input do you have from the relevant package ecosystem/community?
source.jsonmetadata file duringansible-galaxy collection install, enabling scanners to generate correct PURLs. This PR will be submitted to https://github.com/ansible/ansible (I will update the issue to with the corresponding PR. )namespace.nameformat (e.g.,cisco.aci,community.general)What are the PURL component level definitions?
ciscoincisco.aci). Lowercased.aciincisco.aci). Lowercased.Qualifiers
repository_urlvcs_urlgit+https://github.com/org/repo.git@tag)download_urlpackagingrpm,deb)Examples
Are there any open questions about this new PURL type?
Galaxy vs Automation Hub: Both use the same Galaxy API protocol, so the internal source type is "galaxy" for both. The
repository_urlqualifier distinguishes them. Is this approach acceptable?Artifact identity: The same collection artifact (identical checksum) may exist on both Galaxy and Automation Hub. The PURL identifies the download source.