| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | AB | AC | AD | AE | AF | AG | AH | AI | AJ | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Priority | Title | Number | PURL Ecma Stnd. | PURL Core-Spec | PO input | status | see encoding gSheet | Notes | Action items | Issue comments | Links | Suggested next steps | Label(s) updated | Add new labels (outdated) | Change labels (outdated) | Type | Number | Links | State | Created At | Updated At | Author | Labels | Comments Count | Latest Comment | Latest Comment Author | ||||||||||
2 | 1high | What about packages on ftp? | #13 | no | 1) Add gnu type | - zvr closed this as completed on 2017-11-29. - pombredanne reopened on 2017-11-29 "to make sure we do not forget to add a gnu type". | https://github.com/package-url/purl-spec/issues/13 | - Keep this issue open. - Need to determine status and decide next steps. | yes | - PURL type definition - Proposed new type - gnu | Issue | 13 | https://github.com/package-url/purl-spec/issues/13 | open | 2017-11-28 17:56:09 | 2017-11-29 21:31:01 | zvr | 4 | 2017-11-29 21:30:58 | pombredanne | |||||||||||||||||
3 | zdone | What's the use of namespace? | #14 | no | closed | No further action required -- sschuberth closed this issue as completed on 2024-10-17. | - zvr and ashcrow disagreed on the utility of a namespace. - Summing up the discussion, pombredanne concluded namespace was useful and invited zvr to close the issue. zvr maintained his preference for a combined namespace-name and invited pombredanne to close the issue. Nobody has closed it and several other comments have trickled in, most recently 2019-04-16 (UTC). | https://github.com/package-url/purl-spec/issues/14 | Closed | no -- issue has been closed | - PURL namespace component | Issue | 14 | https://github.com/package-url/purl-spec/issues/14 | open | 2017-11-28 18:08:06 | 2019-04-16 02:14:10 | zvr | 12 | 2019-04-16 02:14:10 | jdillon | ||||||||||||||||
4 | zdone | Authorities and private registries | #15 | yes | yes | closed | JMH: added 'Ecma specification' label. 2024-11-07 JMH: pombredanne tried to tie this up on 2018-02-08 and asked the author if he had anything else before we closed this issue -- the author has not replied, but others raised questions of their own into 2019. With the passage of 5 years of silence, this seemed stale . . . until last week (2024-10-29), when Insidexa asked about the status of this private registries issue: "Any updates? We use private registries for npm, Gradle, and PyPI, and in the GitHub UI, we don't have links to custom libraries". [More comments since then.] Open since 2017-11-29 -- a good candidate for early attention and resolution. pombredanne closed this issue on 2025-06-26. | 1) This needs Philippe's attention. | - Extended discussion between jackfirth and pombredanne re purl syntax for private registries. - jackfirth: ". . . it's impossible to reliably define private namespaces, which severely limits the use of PURLs." - jackfirth also suggested "hav[ing] each package system define what its default authority is. A scheme registration should define what the default authority and port are anyway...." - pombredanne: this would lead to the reuse of purl components and "the purl non ambiguous definition falls apart flat IMHO: I can no longer distinguish what are the parts that are defining a package repo from the parts that identify and name a certain package because the Path mixes things from these two separate concerns." - Several other users added comments re challenges. | https://github.com/package-url/purl-spec/issues/15 | - No activity since 2019-04-15 comment but the issue appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL core specification - Authorities/private registries | Issue | 15 | https://github.com/package-url/purl-spec/issues/15 | open | 2017-11-29 08:12:54 | 2019-04-16 02:17:47 | jackfirth | 10 | 2019-04-16 02:17:47 | jdillon | ||||||||||||||
5 | 1high | We really really need a cool logo | #19 | no | adam: will brainstorm in november | 1) Discuss internally? Simple word-based or icon? | - Includes several examples from stevespringett and from others. Lots of cats. | https://github.com/package-url/purl-spec/issues/19 | - No activity since 2022-10-30 comment but the issue appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | already added | - PURL community | Issue | 19 | https://github.com/package-url/purl-spec/issues/19 | open | 2017-11-30 15:07:36 | 2022-10-30 15:05:28 | pombredanne | PURL community | 29 | 2022-10-30 15:05:28 | pombredanne | |||||||||||||||
6 | 1high | Document adopters and implementations | #30 | no | adam: will start in november | 1) Work with Adam to create section of wiki to list adopters | - The gist of the issue/discussion, from pombredanne: "We should have a page or doc of sorts that showcases adopters and users!" | https://github.com/package-url/purl-spec/issues/30 | - No activity since 2018-08-16 comment but the issue appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | already added | - PURL community | Issue | 30 | https://github.com/package-url/purl-spec/issues/30 | open | 2018-02-09 07:00:07 | 2020-04-01 17:12:03 | pombredanne | PURL community | 2 | 2018-08-16 17:55:21 | stevespringett | |||||||||||||||
7 | 1high | Update wiki when latest spec is merged | #32 | no | adam: will commit when submitted | 1) Update wiki with fixes, Ecma details, more 2) Create release checklist to include updating wiki when latest spec is merged | - The sole comment (when the issue was opened): "just a reminder". - The wiki (https://github.com/package-url/purl-spec/wiki) was last edited by pombredanne 2017-11-29. - The wiki has a one line entry with a link to an FAQ page last edited 2017-11-29 by pombredanne (https://github.com/package-url/purl-spec/wiki/FAQ). | https://github.com/package-url/purl-spec/issues/32 | - No comments or activity since pombredanne opened the issue on 2018-02-16 but based on the wiki the issue is unresolved. - Not clear how important the wiki issue -- need to determine status and decide next steps. | yes | - PURL community | - Consider removing or renaming the current "task" label. | Issue | 32 | https://github.com/package-url/purl-spec/issues/32 | open | 2018-02-16 23:01:09 | 2018-02-16 23:01:09 | pombredanne | task | 0 | N/A | N/A | ||||||||||||||
8 | zdone | separate type from provider | #33 | yes | yes | closed | JMH: added 'Ecma specification' label. 2024-11-07 JMH: This set of 20 or so comments ended in 2019. The wide-ranging discussion involved inter alia the difference between type and provider and the need to address both in a PURL. Some suggested repository_url was sufficient to address the author's concerns, but others (including the author) disagreed, and the underlying issue was not resolved. It seems repository_url might be our considered response to the author's question -- if so, what is the proper way to convey that to the author and others who added questions? If not, what is our position on the issues raised by the various participants? Open since 2018-03-12 -- a good candidate for early attention and resolution. pombredanne closed this issue on 2025-06-26. | 1) Consider whether the author's proposal is already handled through the repository_url qualifier and otherwise not in scope for PURL. | - Extensive discussion of adding an optional "provider" component to distinguish multiple providers of the same type. "type" = what, "provider" = where/how (or location/protocol). - pombredanne pointed out certain drawbacks to a "provider" component, suggesting the use of multiple purls as a better approach. - sschuberth and stevespringett: "repository_url" already satisfies the "provider" goal(s). - Others: origin is interesting but out of scope. | https://github.com/package-url/purl-spec/issues/33 | - No comment since 2019-10-01, though referenced in various commits as recently as 2023-02-08. Unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new component - PURL goals | Issue | 33 | https://github.com/package-url/purl-spec/issues/33 | open | 2018-03-12 15:56:19 | 2020-04-01 17:11:36 | jeffmcaffer | PURL core specification | 20 | 2019-10-02 00:32:49 | jeffmcaffer | |||||||||||||
9 | zdone | Clarifications | #35 | yes | yes | closed | yes | JMH: added 'Ecma specification' label. JMH: one of numerous encoding PRs and issues. See details in PR 150 and my summary of similar issues/PRs in issue 344. 2024-11-07 JMH: We offered to open a PR back in 2018 when the author declined to do so, but have not followed up. This issue raises encoding questions for a range of characters. Given the other encoding issues and PRs, would a rewrite of the core spec encoding section be the best place to start, after which we can respond to the issues and PRs and refer to the [draft?] encoding section language? If not, pombredanne might need to reduce to writing the numerous comments and refinements he mentioned in the issue. pombredanne closed this issue on 2025-06-26. | 1) confirm with Philippe whether we can implement | - Discussion between jgustie and pombredanne re how to construct and handle qualifiers. - pombredanne agreed 2018-04-02 to make changes but apparently the issue remains open. - Supplemented 2021-07-21 by a comment from mattt re lowercase transformation and string parsing. | https://github.com/package-url/purl-spec/issues/35 | - No comment since 2021-07-21. Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Component structure and parsing - PURL capitalization | Issue | 35 | https://github.com/package-url/purl-spec/issues/35 | open | 2018-03-23 14:12:18 | 2021-07-21 17:39:40 | jgustie | PURL core specification | 9 | 2021-07-21 17:39:40 | mattt | ||||||||||||
10 | 1high | Concerns with type-specific component value transformations | #38 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-08 JMH: This issue raises concerns about the need to make value translations that can vary from type to type and may be defined well after a particular implementation has been developed, raising significant maintenance/updating challenges. The discussion is detailed and does not reflect a resolution or specific proposal. | 1) Difficult to assess status, needs Philippe's review and input. | - Discussion of the complexities of component value transformations (e.g., "" or "-" or lowercase <==> UPPERCASE). - jdillon asserts that such transformations should not be part of the PURL spec. - stevespringett: make PURL lowercase by convention, no case transformations, transformation required only when not transforming characters "would violate the URI specification." - sarnesjo: the spec (namespace and name must be lowercased) is inconsistent with Go tooling (e.g., Go module names are case-sensitive). | https://github.com/package-url/purl-spec/issues/38 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Component value transformations - PURL capitalization | Issue | 38 | https://github.com/package-url/purl-spec/issues/38 | open | 2018-04-06 22:49:33 | 2024-06-13 12:49:38 | jdillon | PURL core specification | 5 | 2024-06-13 12:49:37 | matt-phylum | ||||||||||||||
11 | zdone | Percent encoding spec and : and / | #39 | yes | yes | closed | yes | JMH: added 'Ecma specification' label. JMH: one of numerous encoding PRs and issues. See details in PR 150 and my summary of similar issues/PRs in issue 344. 2024-11-08 JMH: concerns encoding of ":" and "/". stevespringett also noted that some tests in the test suite do not correctly encode the PURLs. Others have also added detailed comments, sometimes at odds with fellow commenters' viewpoints. Needs a collective approach with all the other encoding issues and PRs. pomberdanne closed this on 2025-06-26. | 1) Difficult to assess status, needs Philippe's review and input. | - jdillon seeks clarification re when ':' and '/' should/should not be encoded. - stevespringett notes errors in the test suite that violate the spec, seeks clarifcation re "the canonicalized purl". - pombredanne proposes updating the test suite and requiring "the bare absolute minimum encoding that would be needed such that Package URLs stay non ambiguous and are the most readable in the majority of the cases." | https://github.com/package-url/purl-spec/issues/39 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL encoding | Issue | 39 | https://github.com/package-url/purl-spec/issues/39 | open | 2018-04-06 23:00:51 | 2024-08-20 19:50:10 | jdillon | PURL core specification | 13 | 2024-08-20 19:50:10 | jdalton | ||||||||||||
12 | 1high | Propose 1.0 Milestone | #50 | yes | no | JMH: added 'Ecma specification' label. 2024-11-08 JMH: This issue is already being handled through our ongoing review process. | 1) Resolved - we have calls for Ecma standardization 2) Option to start PURL community calls to solicit more feedback | - stevespringett proposes scheduled calls to address the numerous open PRs and unanswered issue questions that need to be resolved before the 1.0 release. - Opened 2018-09-05, this issue has been inactive since the last comment (2020-04-01). | https://github.com/package-url/purl-spec/issues/50 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL spec release schedule | Issue | 50 | https://github.com/package-url/purl-spec/issues/50 | open | 2018-09-05 20:39:27 | 2020-04-01 20:05:40 | stevespringett | PURL core specification | 6 | 2020-04-01 20:05:40 | brianf | ||||||||||||||
13 | 1high | qualifiers sorting | #51 | yes | yes | good candidate for early attention and resolution | JMH: added 'Ecma specification' label. 2024-11-08 JMH: on 2019-11-26 pombredanne invited the author jdillon to open a PR memorializing the result of their discussion. jdillon has not yet replied. I suggest we ping him and ask if he still wants to open a PR, and if no reasonably prompt response, we can close this issue with an invitation to reopen if he wants to pursue. This was opened on 2019-01-11 and might be a good candidate for pombredanne's early resolution. | 1) Is this ready to be closed because the author's question has been adequately answered, or does this require a clarification via PR? | - jdillon: the spec seems to require that qualifiers be sorted. - pombredanne: qualifiers do not need to be ordered and the "qualifier strings" are the entire key/value pair -- later corrected to agree with jdillon that the sorted key alone is enough "to ensure normality". - This issue appeared to be ready for a PR as of 2019-11-26 when pombredanne invited jdillon to open a PR. | https://github.com/package-url/purl-spec/issues/51 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL qualifiers component | Issue | 51 | https://github.com/package-url/purl-spec/issues/51 | open | 2019-01-12 03:26:37 | 2020-04-01 16:40:45 | jdillon | PURL core specification | 6 | 2019-11-26 22:08:25 | pombredanne | |||||||||||||
14 | zdone | clarify handling of "+" (plus) sign and blanks (spaces) | #58 | yes | yes | closed | yes | JMH: added 'Ecma specification' label. JMH: one of numerous encoding PRs and issues. See details in PR 150 and my summary of similar issues/PRs in issue 344. 2024-11-08 JMH: concerns encoding of "+" and " " -- another example calling out for a revised encoding section. pombredanne closed this issue on 2025-06-26. | 1) Difficult to assess status, needs Philippe's review and input. | - Discussion re whether "+" and " " need to be encoded and if so when (e.g., only in qualifiers vs. everywhere else). - Different views re whether the PURL goal is readability or interoperability. - tommyknows raised the issue of QueryEscape vs. PathEscape and the role of the "@" character. | https://github.com/package-url/purl-spec/issues/58 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL encoding - PURL goals | Issue | 58 | https://github.com/package-url/purl-spec/issues/58 | open | 2019-04-09 08:15:54 | 2023-07-17 11:53:31 | gernot-h | PURL core specification | 4 | 2023-07-17 11:53:31 | tommyknows | ||||||||||||
15 | 1high | Reasons for github, bitbucket and generic types? | #59 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-08 JMH: no activity since May 2019. The discussion involved numerous comments from many commenters re many types beyond those mentioned in the issue title. Some commenters want to delete the three mentioned, others to keep a few, still others to leave them as is. No resolution is evident in the comments. BTW, should this issue be broken into a separate new issue for each challenged type and not considered part of the core spec portion of this 1.0 spec goal? | 1) Need Philippe to assess status and next steps particularly in light of his extensive comments. | - jdillon: github, bitbucket and generic types are non-type specific, "do not actually express what the package is and . . . are an anti-pattern. . . . [T]hese are perversions of the intended nature of this specification and should be removed." - stevespringett: "I'm good with removing 'github' and 'bitbucket', but I'm on the fence about 'generic'. We may want to leave that in the spec as a fall-back." - grv87: "gitlab and sourceforge" - pombredanne: The overall rationale: a need for things that are important and not in a package registry. github, gitlab or bitbucket package types are not meant to be VCS URLs. "VCS URLs are strictly focused on how to access and collect files over some version control system using a certain transport." - A flurry of comments in early May 2021, no comments since then. | https://github.com/package-url/purl-spec/issues/59 | - Appears unresolved -- keep this issue open. Or is the issue resolved in favor of taking no action -- keeping the various types discussed -- and thus this issue should be closed? - Need to determine status and decide next steps. | yes | - PURL goals | Issue | 59 | https://github.com/package-url/purl-spec/issues/59 | open | 2019-04-16 01:15:58 | 2021-05-07 17:33:38 | jdillon | PURL type definition | 16 | 2021-05-07 17:33:38 | MarkLodato | ||||||||||||||
16 | 1high | How are golang sub-modules supposed to be expressed by purl? | #63 | no | golang-related | 2024-11-18 JMH: This is one of a group of golang-related issues and PRs that perhaps can be handled together, as suggested in issue #346. | 1) Requires Philippe's input and perhaps could be efficiently addressed with the other Go issues/PRs. | - andrewstein: difficult to know correct way to express Golang PURLs, e.g., what values should be treated as namespace vs. name vs. subpath. Encoding questions also exist. - Many comments from bradcupit, sschuberth, jdillon, pombredanne and others, lively discussion through 2023-04-25; no comments since then. | https://github.com/package-url/purl-spec/issues/63 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | already added | - PURL type definition - go | Issue | 63 | https://github.com/package-url/purl-spec/issues/63 | open | 2019-08-01 21:16:05 | 2023-04-25 07:53:02 | andrewstein | PURL type definition | 26 | 2023-04-25 07:53:02 | sschuberth | ||||||||||||||
17 | zdone | Version range | #66 | yes | closed | JMH: added 'Ecma specification' label. pombredanne closed on 2024-11-06 as having been merged in VERSION-RANGE-SPEC.rst. | 1) Need Philippe to assess status and next steps particularly in light of his extensive comments and the importance of a vers spec. Note that Philippe wrote on 2022-02-01 "Unless there are objections I will likely merge it this week." | - iamwillbar asked whether PURL could and should support version ranges. - Additional discussion followed re versioning schemes, ranges vs. explicit enumerations, display, encoding, readability, computability, locking and lockfiles. - Detailed comment by jbmaillet re the large number of maintained versions involved in, e.g., the Linux kernel, the equally large number of potentially relevant CVEs, and the resulting practical impossibility of providing a complete enumerated list -- "computable version range[s] are hard, but they are a MUST." - On 2022-01-26 tschmidtb51 asked pombredanne re the status of VERSION-RANGE-SPEC.rst. pombredanne replied 2022-02-01 that he's likely to merge it "this week." - There are comments 2023-10-13 and 2024-06-12 asking about the status, but no reply and no evidence any code was merged. | https://github.com/package-url/purl-spec/issues/66 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Version ranges | Issue | 66 | https://github.com/package-url/purl-spec/issues/66 | open | 2019-10-16 18:15:53 | 2024-06-12 16:26:19 | iamwillbar | 29 | 2024-06-12 16:26:18 | fproulx-boostsecurity | |||||||||||||||
18 | 1high | Go is called Go, not Golang | #67 | no | golang-related | 2024-11-18 JMH: This is one of a group of golang-related issues and PRs that perhaps can be handled together, as suggested in issue #346. | 1) Assess whether we're ready to proceed with replacing golang with go (or alternatively introducing go as an "alias" type) as a type. | - Differing views on "golang" vs. "go". robpike (Go creator) says the name should be "go". - Discussion re deprecating "golang" in favor of "go" vs. allowing aliases. - Last comment was 2019-11-25. Current status not reflected. | https://github.com/package-url/purl-spec/issues/67 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type - go | Issue | 67 | https://github.com/package-url/purl-spec/issues/67 | open | 2019-10-23 23:40:24 | 2020-04-01 16:34:28 | robpike | PURL type definition | 8 | 2019-11-25 21:44:34 | robpike | ||||||||||||||
19 | zdone | Inconsistency in the description of the checksum qualifier. | #73 | yes | yes | closed | yes | JMH: added 'Ecma specification' label. JMH: one of numerous encoding PRs and issues. See details in PR 150 and my summary of similar issues/PRs in issue 344. 2024-11-08 JMH: raises the question of encoding ":" in qualifiers and other components. pombredanne closed this issue on 2025-07-01. | 1) Can we consider all the encoding issues/PRs together and come to a decision/agreement on what is encoded and what is not encoded? See also PR 184 (encoding of "/" in qualifier value). The spec says the value must be percent encoded and does not mention ":" or "/", suggesting that they, too, must be encoded. | - andrewstein: seeks clarification re how a checksum qualifier should be encoded, including a ":' inside the checksum string itself. - matt-phylum: asserts on 2023-08-01 that the spec makes clear that such a ":" need not be encoded but encoding variations are expected and even an encoded internal ":" would be valid. - No further comments or indication of the status. | https://github.com/package-url/purl-spec/issues/73 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL encoding - PURL qualifiers component | Issue | 73 | https://github.com/package-url/purl-spec/issues/73 | open | 2020-02-11 23:09:59 | 2023-08-01 15:53:19 | andrewstein | 3 | 2023-08-01 15:53:19 | matt-phylum | |||||||||||||
20 | 1high | Add hackage packages in purls-spec | #80 | no | 1) Need to decide whether to approve work on a hackage type and determine who can/will take the lead. | - No description provided, no comments, nothing that reflects the status. | https://github.com/package-url/purl-spec/issues/80 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type - hackage | Issue | 80 | https://github.com/package-url/purl-spec/issues/80 | open | 2020-04-02 09:33:20 | 2020-04-02 09:33:20 | TG1999 | 0 | N/A | N/A | |||||||||||||||||
21 | 1high | nitpicking: repository_url is usually not an URL | #81 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-08 JMH: needs pombredanne's response. | 1) Consider thanking the author, providing a final simple explanation, and closing this old issue. | - scolytus: repository_url examples are not full URLs. - No comments, nothing to reflect the status. | https://github.com/package-url/purl-spec/issues/81 | - Need to determine status and decide next steps. - Given the passage of time and broad use of the repository_url qualifier, some sort of polite thank you might be in order, followed by closing the issue. | yes | - PURL qualifiers component | Issue | 81 | https://github.com/package-url/purl-spec/issues/81 | open | 2020-04-14 15:04:31 | 2020-04-14 15:04:31 | scolytus | 0 | N/A | N/A | |||||||||||||||
22 | 1high | Wildcards in purl? | #84 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-08 JMH: This issue proposed using wildcards in a PURL version component to represent ranges. pombredanne's 2024-09-27 merger of https://github.com/package-url/purl-spec/pull/139 (which he mentioned to the author when the PR was still a w-i-p) seems to adequately address the author's proposal. Consider closing this issue as addressed by the vers spec, with a comment that questions and proposals re version ranges should be added as new issues focused on the vers spec definition in https://github.com/package-url/purl-spec/blob/master/VERSION-RANGE-SPEC.rst. | 1) Need Philippe to assess status and next steps particularly in light of his extensive comments and the importance of a vers spec. | - copernico asked, in essence, for the ability to use wildcards for version ranges. - stevespringett: no plans to support this, but acknowledged the need for ranges and wildcards, invites a proposal. - pombredanne: a universal definition is not possible; "[t]o add them to purl, we could either have a partly universal/partly type-specific approach or be entirely package type-specific." Proposed a new qualifier for version range syntax. - Discussion of proper range notation. - pombredanne: after some experimentation, described a detailed proposal for version specifiers and version ranges. - coderpatros raised several concerns re syntax and encoding. Nobody has responded to these points. - 2021-11-30 pombredanne directed copernico's attention to https://github.com/package-url/purl-spec/pull/139 -- Add mostly universal version range spec draft. That PR is still open. - No further comments. | https://github.com/package-url/purl-spec/issues/84 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Version ranges - PURL encoding | - Consider removing or renaming the existing "question" label. | Issue | 84 | https://github.com/package-url/purl-spec/issues/84 | open | 2020-05-07 13:16:36 | 2021-11-30 15:17:03 | copernico | question | 12 | 2021-11-30 15:17:02 | pombredanne | |||||||||||||
23 | 1high | Thoughts on including a git commit qualifier for git forge resources | #88 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-08 JMH: Note that this is actually a type-specific issue -- I added the "Ecma specification" label because of iamwillbar's mention of an "oci"-type PR (123 -- merged) that includes a "tag" qualifier based on a concept similar to that discussed in this issue 88. Should I remove the "Ecma specification" label and defer this issue to the type-specific stage that will follow our core spec work? | 1) Need to Philippe to assess whether this is ready to adopt the approach iamwillbar proposes, as Philippe's comment suggests. | - athos-ribeiro noted that the version for github resources allows a commit or tag but asserts that a tag's meaning can change over time and suggests that when a tag is used, the spec also should allow a qualifier in the form of ...NAME@TAG?commit=HASH. - iamwillbar: proposed several variations to describe several different scenarios. - github:package-url/purl-spec@master - github:package-url/purl-spec@a1b2c3?ref=master - github:package-url/purl-spec@master?commit=a1b2c3 - pombredanne on 2021-10-11: I agree with you. IMHO either way works. - No comments or other activity since then. | https://github.com/package-url/purl-spec/issues/88 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL version component - PURL qualifiers component | Issue | 88 | https://github.com/package-url/purl-spec/issues/88 | open | 2020-07-24 09:03:18 | 2021-10-11 08:27:17 | athos-ribeiro | 2 | 2021-10-11 08:27:16 | pombredanne | |||||||||||||||
24 | zdone | Clarification on how to refer to platform-specific pypi packages | #90 | no | closed | 2024-11-22 JMH: pombredanne closed this as completed in #170 on 2024-11-21. | 1) This issue and the related PR 170 appear to be ready to move forward with a new pypi 'filename' qualifier but stevespringett asks in the PR whether it should be for all types not just pypi. | - petergardfjall proposed using qualifiers to reflect the Python version used, the extras/options selected as part of the download, the targeted OS and so on. - 2021-07-09 rootLUG: this would be very useful, proposes additional specifiers (qualifiers keys), offered to "draft up a pull request with those changes." - 2021-07-09 rootLUG: notes that from reviewing the purl spec there are few qualifiers valid for all package types "such as download_url, file_name, and checksum, . . . I guess this solves half of the issue." - No further comments but "MarkLodato linked a pull request on May 27, 2022 that will close this issue -- Add filename qualifier to pypi. #170" (https://github.com/package-url/purl-spec/pull/170) | https://github.com/package-url/purl-spec/issues/90 | - Appears unresolved since the associated PR remains open and unresolved (https://github.com/package-url/purl-spec/pull/170) -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL type definition - PURL qualifiers component | Issue | 90 | https://github.com/package-url/purl-spec/issues/90 | open | 2020-08-24 06:10:05 | 2021-07-09 12:59:13 | petergardfjall | 2 | 2021-07-09 12:59:13 | RootLUG | |||||||||||||||
25 | 1high | Expected PURL for Conan - specifically namespace field | #94 | no | 1) stevespringett wrote on 2020-10-08 that "[t]he type definition for conan hasn't been defined yet", but there currently is, and it has an entry describing the namespace component that seems to be the focus of the issue's author -- is this ready to so advise the author and then close the issue? ("namespace: The vendor of the package." -- added 2022-07-18) | - steve-thousand : There are at least 2 major repos for Conan and other attributes that could be included -- what is the correct namespace? - stevespringett: "The type definition for conan hasn't been defined yet. The namespace isn't confined to a single label. It can have '/'. So it's possible a namespace could include the user and channel separated by a '/' followed by the name of the component." - 2020-10-30 steve-thousand: Update: "Short answer is: repository probably should not be part of the conan PURL." - No comments or activity since then. | https://github.com/package-url/purl-spec/issues/94 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL namespace component | Issue | 94 | https://github.com/package-url/purl-spec/issues/94 | open | 2020-10-08 15:31:51 | 2020-10-31 16:22:25 | steve-thousand | PURL type definition | 2 | 2020-10-31 16:22:24 | steve-thousand | ||||||||||||||||
26 | 1high | Add CIPD as a PURL type | #114 | no | 1) Should the go-ahead be given to the author? If so, what else is involved/required from our end re creation of the spec? | - 2021-08-20 jupenur proposes adding CIPD as a new type. "Chromium uses the Chrome Infrastructure Package Deployment (CIPD) registry for some dependencies." - No further comments or activity. | https://github.com/package-url/purl-spec/issues/114 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type - CIPD | Issue | 114 | https://github.com/package-url/purl-spec/issues/114 | open | 2021-08-20 12:35:54 | 2021-08-20 12:57:47 | jupenur | 1 | 2021-08-20 12:57:47 | jupenur | |||||||||||||||||
27 | 1high | Add F-Droid as a PURL type | #120 | no | 1) Should the go-ahead be given to the author? If so, what else is involved/required from our end re creation of the spec? | - armijnhemel: add a PURL type for F-Droid. - 2022-12-06 pombredanne: "This PR is adding fdroid support in the purldb at aboutcode-org/purldb#10 and becomes a good way to specify the fdroid purl type" with link [updated]: https://github.com/aboutcode-org/purldb/pull/10 - That PR was merged the same day. No further comments or activity. However, F-Droid is not listed among the known or candidate PURL types. (https://github.com/package-url/purl-spec/blob/version-range-spec/PURL-TYPES.rst) | https://github.com/package-url/purl-spec/issues/120 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type - F-Droid | Issue | 120 | https://github.com/package-url/purl-spec/issues/120 | open | 2021-08-27 14:18:23 | 2022-12-06 10:56:11 | armijnhemel | 3 | 2022-12-06 10:56:11 | pombredanne | |||||||||||||||||
28 | 1high | Register purl pkg: scheme @ IANA | #124 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-11 JMH: From my comment in the feedback column for PR 141: "JMH: It appears that the initial IANA review noted that a section on security consideration is required. The comments from late 2021/early 2022 reflect some discussion but no security section yet added." | 1) Both issue 124 and PR 141 involve drafting and submitting an IANA registration for the "pkg" scheme. The draft in the PR was added on 2021-12-13. While the PR has been inactive since 2022-02-17, elear offered in May 2024 to help move this process forward: "@pombredanne just ping me in email and we can set something up.". We should follow-up with elear and ask about, or suggest, next steps. | - 2021-09-16 pombredanne: will begin process of registration with the IANA (Internet Assigned Numbers Authority). - 2021-12-16 whiskeysierra: "The IANA URI review highlights that it's not a URL, but a URI" - 2021-12-16 pombredanne to whiskeysierra: can you provide a cite? - 2022-08-24 iamwillbar: "is there anything I can do to help get this registration submitted?" - 2024-05-14 sjn: "Apologies for waking this issue from it's coma, but are there any movements on this and #141? :-)" (The open PR for the registration draft: https://github.com/package-url/purl-spec/pull/141) - 2024-05-14 elear: we got hung up on "Security Considerations" and "Character set interpretation". - 2024-05-15 elear: "I just chatted with Ted Hardie who did the initial review. He'd be willing to help us get across the line. @pombredanne just ping me in email and we can set something up." - No further comments or activity. | https://github.com/package-url/purl-spec/issues/124 | - Appears unresolved and the associated PR (https://github.com/package-url/purl-spec/pull/141) remains open, no activity since 2022-02-17 -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL spec IANA registration | Issue | 124 | https://github.com/package-url/purl-spec/issues/124 | open | 2021-09-16 16:20:34 | 2024-05-15 14:56:35 | pombredanne | 14 | 2024-05-15 14:56:34 | elear | |||||||||||||||
29 | zdone | Namespaces for Taxonomy ... rich namespaces to separate source and build origins | #129 | yes | no | closed | JMH: added 'Ecma specification' label. 2024-11-11 JMH: I just replied with this comment to the author @hartsock: Hi @hartsock . Thank you for opening this issue. I'm working on helping to bring our issues and PRs up-to-date and see that @iamwillbar and @pombredanne appear to have answered the questions you raised. If that's the case, can you please close this issue? And if not, please advise what remains to be addressed. Thanks! 2024-11-12 JMH: The author hartsock closed this issue 129 as completed earlier today. | 1) Consider sending a comment to hartsock suggesting he close the issue if he has no additional questions. | - hartsock (VMWare): proposed expanding the use of namespace to include such topics as the location of the source code from which a binary is built. - iamwillbar: outside the scope of purl. "This type of mapping is best done using SBOM formats - such as CycloneDX and SPDX" - 2021-10-11 pombredanne: provided hartsock with a detailed explanation of options to achieve the RPM recompilation and info-tracking workflow he described when he opened the issue. "The important thing here to keep in mind... purl are just identifiers and locators, not a "database" of all facts and relationships about a package and its origin and more. ... [P]lease feel free to close." - No further comments or activity. | https://github.com/package-url/purl-spec/issues/129 | - Close the issue as resolved -- or we could first post a short polite ping and if no response withon 7 days close the issue. | yes | - PURL namespace component | Issue | 129 | https://github.com/package-url/purl-spec/issues/129 | open | 2021-10-08 19:24:46 | 2021-10-11 09:00:59 | hartsock | 2 | 2021-10-11 09:00:59 | pombredanne | ||||||||||||||
30 | 1high | Letter case for npm packages | #136 | no | must be lowercased | 1) Can we provide clarity on lowercase or not for the npm 'name' component? The spec has the quotes wrong and is missing the term "package"; and several comments suggest mixed casing should be permitted. | - scanossmining: reported an apparent conflict between the purl requirement (as he understood the spec) that npm names be lowercase and the fact that some npmjs.com hosted packages include uppercase letters in the name. - stevespringett: lowercase is preferred but not mandatory for an npm, and we need to make that clear in the spec. - scanossmining reported a typo in the npm portion of the spec (https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#npm) and pombredanne invited him to fix and open a PR. - 2021-11-18 iamwillbar: noted that the npm documentation requires all lowercase letters in the names of "new" packages, and thus the purl spec needs to support mixed case. - 2023-11-15 wesleytodd: complained that "you are going to have a really tough time trying to get adoption in the JS ecosystem because you chose to break from the existing well understood and widely deployed formats. Honestly looking at the work in this repo, it looks like y'all skipped the step of asking folks who work on the JS package managers what they think." - No further comments or activity. | https://github.com/package-url/purl-spec/issues/136 | - Appears unresolved but it's not clear that this issue should remain open. - Need to determine status and decide next steps. | yes | - PURL capitalization | Issue | 136 | https://github.com/package-url/purl-spec/issues/136 | open | 2021-11-03 11:30:49 | 2023-11-15 16:32:18 | scanossmining | PURL type definition | 5 | 2023-11-15 16:32:18 | wesleytodd | |||||||||||||||
31 | 1high | Add CPE as a PURL type | #138 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-11 JMH: There was a flurry of comments in December 2021 and another comment in June 2023. Several of these floated the idea of adding "cpe" as a qualifier key with a value equal to an assigned CPE. The last commenter (andrewpollock) included a link to some Grype code that seems to be using "cpes" as such a qualifier. See https://github.com/anchore/grype/blob/dfa540f727454da3172bc0cc5b5bc36a925bbd04/grype/pkg/purl_provider.go#L45 (and the key "cpes" is referred to on line 25 in the definition of the variable "cpesQualifierKey"). This strikes me as a sound idea -- what do you think, pombredanne, and how should we proceed? | 1) Are we able to provide a response that adequately addresses this proposal by describing an alternative way CPEs are intended to work with a PURL? Or should cpe be a new type? | - 2021-11-26 sschuberth proposed CPE as a new type "so we could specify a defined way how to map CPEs to PURLs." - pombredanne: a mapping would be best. - 2021-12-21 sschuberth: agrees, "But could we define a standard query parameter [he was referring to qualifiers] called "cpe" that, if present, contains the CPE?" - 2023-06-11 andrewpollock: mentioned an anchore/grype use case re using "cpes" as a qualifier. - No comments or activity since then. | https://github.com/package-url/purl-spec/issues/138 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type - CPE | Issue | 138 | https://github.com/package-url/purl-spec/issues/138 | open | 2021-11-26 14:33:55 | 2023-06-12 06:04:32 | sschuberth | 6 | 2023-06-12 06:04:32 | sschuberth | |||||||||||||||
32 | 1high | Is protocol in repository_url unsupported? | #140 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-11 JMH: per my Action items entry -- Can we provide the author with repository_url examples that include the schemes he refers to? | 1) Can we provide the author with repository_url examples that include the schemes he refers to? | - 2021-12-08 JLLeitschuh: working on "an implementation of an extractor for Gradle", looking for examples and details re the use of repository_url "that include the scheme". - No comments or activity since then. | https://github.com/package-url/purl-spec/issues/140 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL qualifiers component | Issue | 140 | https://github.com/package-url/purl-spec/issues/140 | open | 2021-12-08 23:50:48 | 2021-12-08 23:50:48 | JLLeitschuh | 0 | N/A | N/A | |||||||||||||||
33 | 1high | Add support for `snapshot` as a qualifier for deb purls | #143 | no | 1) Consider giving the author the go-ahead to add 'snapshot' as a qualifier for 'deb' PURLs. | - 2021-12-14 samj1912: proposed 'snapshot' as a qualifier (w/a link: https://snapshot.debian.org/). - pombredanne: snapshots are specific to deb. - 2021-12-25 bureado: "I fundamentally disagree that snapshotted/timestamped packages are a concept exclusive to the Debian ecosystem." Added a link 2022-01-03. - No comments or activity since then. | https://github.com/package-url/purl-spec/issues/143 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL qualifiers component | Issue | 143 | https://github.com/package-url/purl-spec/issues/143 | open | 2021-12-14 11:59:52 | 2022-01-04 00:17:39 | samj1912 | 6 | 2022-01-04 00:17:39 | bureado | |||||||||||||||||
34 | 1high | Add guix and nix as package types | #149 | no | 1) There seems to be no reason to delay starting the process of adding guix and nix as new types. Exactly what would be involved? | - 2022-01-31 pombredanne proposed adding guix and nix as new types. - 2023-05-08 raboof added a link. - No comments or activity since then. | https://github.com/package-url/purl-spec/issues/149 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type - guix - nix | Issue | 149 | https://github.com/package-url/purl-spec/issues/149 | open | 2022-01-31 09:56:28 | 2023-05-08 07:23:11 | pombredanne | 1 | 2023-05-08 07:23:11 | raboof | |||||||||||||||||
35 | 2medium | About Epoch in RPM and DEB Package Versioning | #151 | no | JMH awaiting reply from author/others | 2024-11-19 JMH: I added a comment for the author: Hello @masahiro331 . Thank you for opening this issue. I see that you opened a related PR on 2022-02-19 and closed it on 2023-03-30. #153 (comment) Does that mean this issue is ready to be closed as well? | 1) PR 153 seemed to address this issue (don't use qualifier for rpm epoch, use version like deb does -- pombredanne agreed) but was closed apparently without merging. Closed issue 69 includes contrary views from pombredanne and stevespringett. Is there now a consensus on how to handle the underlying issue of epochs in rpm types? Current spec: epoch (optional for RPMs) is a qualifier as it's not required for unique identification, but when the epoch exists we strongly encourage using it. | - 2022-02-11 masahiro331: rpm includes epoch in qualifiers but should instead include in version as deb does. - 2022-02-17 pombredanne: good catch. "Would you be willing to propose a patch?" - 2022-02-19 masahiro opened PR #153. - 2022-11-30 dralley commented in PR 153 that an earlier issue #39 had noted a weakness in the approach taken in PR 153. - 2023-03-20 masahiro331 closed PR 153 w/o comment. | https://github.com/package-url/purl-spec/issues/151 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL type definition - PURL version component - PURL qualifiers component | Issue | 151 | https://github.com/package-url/purl-spec/issues/151 | open | 2022-02-11 16:03:02 | 2022-02-17 16:07:40 | masahiro331 | 1 | 2022-02-17 16:07:40 | pombredanne | |||||||||||||||
36 | 2medium | Add OmniBOR (previously GitBOM) namespace identifier as a PURL Type | #154 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-11 JMH: pombredanne: what is your view and how should we proceed? | 1) Is it time to give the go-ahead to draft the spec for a gitoid type? | - 2022-03-01 jeff-schutt proposed a new type for GitBOM. (His example: "pkg:gitoid:blob:sha1:261eeb9e9f8b2b4b0d119366dda99c6fd7d35c6") - 2022-03-01 stevespringett: your example does not comply with the spec. - 2022-07-15 jeff-schutt: several comments with sample approaches. - 2022-07-15 stevespringett: he thinks this could work: pkg:gitoid/<git object type>/<hash value>. - 2022-08-25: iamwillbar proposed an alteration to stevespringett's proposal, who replied "Yes. Reasonable @iamwillbar" - 2022-10-12 jeff-schutt: discussed with the GitBOM community -- we agree including adding the hash algorithm as a prefix to the name. - 2023-01-17 stevespringett: "Is it still referred to as gitoid now that the project changed their name to OmniBOR?" - 2023-01-24 jeff-schutt: yes. - No further comments or activity. | https://github.com/package-url/purl-spec/issues/154 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL core specification - Proposed new type - gitoid | Issue | 154 | https://github.com/package-url/purl-spec/issues/154 | open | 2022-03-01 20:15:50 | 2023-01-24 20:26:48 | jeff-schutt | 13 | 2023-01-24 20:26:48 | jeff-schutt | |||||||||||||||
37 | 2medium | OCI type: is version required? | #157 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-11 JMH: As of today the "oci" type still purports to make the "version" component required. https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#oci "The version . . . is required to uniquely identify the artifact." This contradicts the core spec, which provides: "version: the version of the package. Optional." I assume a type cannot make an optional component into a required component. Is that an accurate statement? (I think I already raised this question in another issue or PR, will see if I can find that ref for cross-referencing. Ah yes -- see PR 245 re the proposed "vcpkg" type.) | 1) There is slightly conflicting language between the spec page ("version: the version of the package. Optional.") and the type page's oci section ("The version is the sha256:hex_encoded_lowercase_digest of the artifact and is required to uniquely identify the artifact."). Would the oci entry still be adequate if we were to suggest that the author open a PR that deletes the passage "and is required to uniquely identify the artifact"? Or some other minor modification? | - 2022-03-17 MarkLodato: was confused whether version is required for the OCI type. - 2024-06-19 itaysk: the spec clearly states that version is optional. - No further comments or activity. | https://github.com/package-url/purl-spec/issues/157 | - Consider closing the issue with a comment confirming that version is optional for all PURL types. | yes | - PURL version component | Issue | 157 | https://github.com/package-url/purl-spec/issues/157 | open | 2022-03-17 14:15:52 | 2024-06-19 09:02:10 | MarkLodato | 1 | 2024-06-19 09:02:09 | itaysk | |||||||||||||||
38 | 2medium | how to generate the fork repo's purl? | #158 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-11 JMH: the question is difficult to understand so what follows is a guess re what the author was actually asking. Perhaps the author is asking whether a forked repo uses the same PURL as used in the origin repo but could (or must?) use a different repository_url value). That strikes me as a reasonable approach, assuming no changes have been made to the underlying code aside from assigning a new/different "Tag*" value. Or maybe could/must use a different subpath value to reflect the Tag value? | 1) I think the question is: Does a forked repo, with no code changes, use the same PURL as the origin except that it would have a different repository_url value? | - 2022-03-23 Jocluby created this issue with a comment that is difficult to understand. - No comments or activity since then. | https://github.com/package-url/purl-spec/issues/158 | - Do we want to advise the author that his question is not clear and ask him/her to restate the gist of his question? Or just close as stale? | yes | - PURL version component | Issue | 158 | https://github.com/package-url/purl-spec/issues/158 | open | 2022-03-23 07:59:29 | 2022-03-23 07:59:29 | Jocluby | 0 | N/A | N/A | |||||||||||||||
39 | 2medium | Add `gitdescribe` as prefix to version scheme in vers | #162 | no | 1) Needs Philippe's review and input. | - 2022-04-08 tschmidtb51: requested thoughts on his suggestion "Being able to add gitdescribe as a prefix (or suffix) to a known version scheme should just override how to compare pre-release version." - No further comments or activity. | https://github.com/package-url/purl-spec/issues/162 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL version component | Issue | 162 | https://github.com/package-url/purl-spec/issues/162 | open | 2022-04-08 13:56:26 | 2022-04-08 13:56:26 | tschmidtb51 | 0 | N/A | N/A | |||||||||||||||||
40 | 2medium | add `intdot` as version scheme | #166 | no | 1) Needs Philippe's review and input. | - 2022-04-27 tschmidt proposed a new version scheme named intdot and pinged pombredanne -- "This will cover 80% of the currently used version schemes that do not follow one of the well-known version-schemes." - 2023-06-29 tschmidt pinged pombredanne: "What would be the process to get this included?" - He also mentioned this issue in PR 139 on 2023-11-09 (where he also mentioned issues re "datetime", "string", "libversion" and "unknown" version schemes). | https://github.com/package-url/purl-spec/issues/166 | - I understand that this issue will ultimately belong to univers but will be addressed initially in the PURL spec process. - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL/univers version scheme | Issue | 166 | https://github.com/package-url/purl-spec/issues/166 | open | 2022-04-27 20:30:38 | 2023-06-30 06:45:42 | tschmidtb51 | 1 | 2023-06-30 06:45:41 | tschmidtb51 | |||||||||||||||||
41 | 2medium | Add "IsKnownType" to purl client libraries | #167 | yes | yes | JMH: added 'Ecma specification' label. | 1) Needs Philippe's review and input. | - 2022-05-02 brphelps proposed adding functionality to "allow a consumer to validate if the purl is a "known" type or not", offered to open a PR. - No comments or subsequent activity. | https://github.com/package-url/purl-spec/issues/167 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL validation | Issue | 167 | https://github.com/package-url/purl-spec/issues/167 | open | 2022-05-02 18:59:35 | 2022-05-02 18:59:35 | brphelps | 0 | N/A | N/A | |||||||||||||||
42 | 2medium | "pacman" should be listed instead of "arch" under "Other candidate types to define" | #185 | no | 1) Needs Philippe's review and input. Perhaps a simple reply to the author would be sufficient to move things forward if that turns out to be desirable. | - 2022-07-18 bronze51 recommends "that "arch" in the "Other candidate types to define" list is replaced with "pacman". - No comments or subsequent activity. | https://github.com/package-url/purl-spec/issues/185 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type - pacman | Issue | 185 | https://github.com/package-url/purl-spec/issues/185 | open | 2022-07-18 13:44:58 | 2022-08-25 14:39:17 | bronze51 | 1 | 2022-08-25 14:39:17 | Foxboron | |||||||||||||||||
43 | 2medium | common qualifiers | #186 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-11 JMH: This proposal for core spec-defined common qualifiers sounds like a good idea -- but don't we do something like that already with "Known qualifiers key/value pairs"? See https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rst#known-qualifiers-keyvalue-pairs Toward the top of the core spec file (PURL-SPECIFICATION.rst) we also refer (some what ambigously perhaps) to the need to check the relevant type spec for additional "qualifiers" rules -- "qualifiers: extra qualifying data for a package such as an OS, architecture, a distro, etc. Optional and type-specific." | 1) Needs Philippe's review and input. | - 2022-07-29 jlb-bb: we should ID "common [non-type-specific] qualifier keys and values such as OS, architecture, GUI framework." - 2022-08-24 iamwillbar: "these aren't truly common", proposed "a best practice of using 'common keys'" - No further comments or activity. | https://github.com/package-url/purl-spec/issues/186 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL qualifiers component | Issue | 186 | https://github.com/package-url/purl-spec/issues/186 | open | 2022-07-29 17:45:15 | 2022-08-24 19:49:14 | jlb-bb | 1 | 2022-08-24 19:49:13 | iamwillbar | |||||||||||||||
44 | 2medium | Governance | #190 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-11 JMH: This could use a reply by pombredanne to oliverchang's question: "Thanks for thinking of me! Which invite exactly is this?" Not sure any other comments need a reply atm although some sort of comment from pombredanne re the status of the core-spec/backlog work might be appreciated by members of the community. | 1) How do we want to respond to or otherwise use this governance-related issue? | - 2022-08-24 iamwillbar: noted that "there is a desire for governance of the project to be more clearly defined", offered to "pull together the files and create pull requests that the current org owners can review." - pombredanne: antitrust and trademarks might be premature at this stage. - torgo (Snyk) and pombredanne discussed the suitability of the current project license. - jlb-bb: "Has it been considered to move PURL under an OWASP or LF umbrella?" - stevespringett: "the contents of all repos in the purl GitHub org meet all the criteria for an OWASP project, if that's something the group wants to do." - pombredanne: not opposed, but what are the benefits? jlb-bb, torgo and others discussed possible pros and cons. - 2022-10-03 iamwillbar: let's focus on governance for now. - 2023-01-04 iamwillbar: will draft PR with proposed governance documents. Various comments in March, May and October 2023 but no record of a PR. - 2024-04-19 jhutchings1: at the recent LF Open Source Summit people complained about all the open PRs and lack of action. - 2024-04-24 stevespringett: reported on status including Ecma TC54-TG2; "TG2 will prepare PURL itself and VERS for standardization, as well as to maintain PURL types." | https://github.com/package-url/purl-spec/issues/190 | - Keep this issue open. - Need to decide next steps. | yes | - PURL governance - Ecma | Issue | 190 | https://github.com/package-url/purl-spec/issues/190 | open | 2022-08-24 21:14:00 | 2024-04-25 03:29:47 | iamwillbar | 22 | 2024-04-25 03:29:46 | stevespringett | |||||||||||||||
45 | zdone | missing namespace in the examples of rpm section from PURL-TYPES.rst | #195 | yes | yes | closed | JMH: added 'Ecma specification' label. 2024-11-11 JMH: I responded today (https://github.com/package-url/purl-spec/issues/195#issuecomment-2469039115 -- the URLs I included are not shown below): Hello @sify21 . The namespace component is optional. See: - The core-spec provides that namespace is optional -- "namespace: some name prefix such as a Maven groupid, a Docker image owner, a GitHub user or organization. Optional and type-specific." - The rpm type spec includes two examples, the second with no namespace (and both of which use the distro qualifier to identify fedora-25): pkg:rpm/fedora/curl@7.50.3-1.fc25?arch=i386&distro=fedora-25 pkg:rpm/centerim@4.22.10-1.el6?arch=i686&epoch=1&distro=fedora-25 If this ^ is inaccurate or incomplete, please chime in here so we can update the core spec as needed. 2024-11-19 JMH: Added a comment for the author: @sify21 Thanks for opening this issue. If my response above answers your question, please feel free to close this issue. 2024-11-21 JMH: sify21 closed this issue. | 1) A simple reply should be sufficient: namespace is optional and the rpm spec provides additional guidance ("The namespace is the vendor such as Fedora or OpenSUSE. It is not case sensitive and must be lowercased."). Note that the rpm spec also includes a fedora example that appears to have been added to the spec prior to the date the issue was opened. | - 2022-10-08 sify21: "I guess namespace fedora is missing here, or is namespace optional?" - No comments. | https://github.com/package-url/purl-spec/issues/195 | - We should reply, confirm namespace is optional, and close this issue. | yes | - PURL namespace component | Issue | 195 | https://github.com/package-url/purl-spec/issues/195 | open | 2022-10-08 09:13:22 | 2022-10-08 09:14:10 | sify21 | 0 | N/A | N/A | ||||||||||||||
46 | 2medium | Known purl types for Machine Learning packages | #197 | no | 1) Two of the four proposed new ML types (huggingface and mlflow) have been added to the list of "Known purl types", leaving "AWS Sagemaker" and "GCP Vertex AI" to be addressed. Do we want to invite the author to draft specs for those (both are model registries)? | - 2022-10-17 maitre-matt: wants to discuss new types used by machine learning package managers. - 2022-11-03 robomotic: how does this overlap with traditional SBOMs? - maitre-matt provided some links. | https://github.com/package-url/purl-spec/issues/197 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type | Issue | 197 | https://github.com/package-url/purl-spec/issues/197 | open | 2022-10-17 13:28:35 | 2022-11-03 18:52:44 | maitre-matt | 2 | 2022-11-03 18:52:44 | maitre-matt | |||||||||||||||||
47 | zdone | Creating a `pkg:content` URI for consistent blob hash representation | #200 | yes | no | closed and moved to a discussion | JMH: added 'Ecma specification' label. 2024-11-11 JMH: I see that on 2024-10-30 pombredanne closed and converted this issue into a discussion. See https://github.com/package-url/purl-spec/discussions/335 | 1) Qualifiers seem to be the correct solution to the author's question. Is bureado's suggestion re the checksum qualifier the recommended approach? Or perhaps some other qualifier? | - 2022-11-02 lumjjb: how can we include content blob hashes in a PURL? - 2023-01-20 bureado: maybe a checksum qualifier? - No further comments. | https://github.com/package-url/purl-spec/issues/200 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. - See also https://github.com/package-url/purl-spec/issues/154 re adding a hash algorithm as a prefix to the name component. | yes | - PURL core specification - PURL qualifiers component | Issue | 200 | https://github.com/package-url/purl-spec/issues/200 | open | 2022-11-02 20:37:52 | 2023-01-20 15:32:48 | lumjjb | 1 | 2023-01-20 15:32:48 | bureado | ||||||||||||||
48 | 3low | Reserve LabVIEW-related package formats vip / nipkg | #202 | no | 1) The PR (318) needs review including addressing matt-phylum's PR questions. | - 2022-11-09 samsharp99: add nipkg and vip as PURL types. Added details the next day. - 2023-01-04 iamwillbar: can you submit a PR? - 2024-08-07 samsharp99: he has submitted a PR. (See https://github.com/package-url/purl-spec/pull/318) | https://github.com/package-url/purl-spec/issues/202 | - Keep this issue open and move forward with review of the PR (where there are already several unanswered questions from matt-phylum). | yes | - Proposed new type - nipkg - vip | Issue | 202 | https://github.com/package-url/purl-spec/issues/202 | open | 2022-11-09 15:24:52 | 2024-08-07 08:34:02 | samsharp99 | 3 | 2024-08-07 08:34:01 | samsharp99 | |||||||||||||||||
49 | 3low | Drop the notion of namespace from PackageURL | #204 | yes | yes | encoding-related | yes | JMH: added 'Ecma specification' label. JMH: one of numerous encoding PRs and issues. See details in PR 150 and my summary of similar issues/PRs in issue 344. 2024-11-11 JMH: Please see my "Action items" comment. I understand that "namespace" will remain a component -- is that correct? It appears that, in any event, the core spec needs to be updated to address the namespace slash encoding issue. matt-phylum's correction of iamwillbar's comment is fully supported in the core spec: - Under "Rules for each purl component": "The optional namespace contains zero or more segments, separated by slash '/' . . . Each namespace segment must be a percent-encoded string [para] When percent-decoded, a segment: . . . must not contain a '/'". - Under "Character encoding": "the '/' used as type/namespace/name and subpath segments separator does not need to and must NOT be percent-encoded. It is unambiguous [sic] unencoded everywhere". | 1) Assuming we intend to keep the namespace component this issue should be closed after replying to TG1999 (the author). Note, however, that the use of slashes and encoding in a namespace appears to be a live issue, including most recently in the context of golang/go PURLs (which is also the example type TG1999 provided) with percent-encode slashes in what I understand is a Go name, a portion of which could be misinterpreted as a namespace. | - 2022-11-28 TG1999: multiples slashes in a namespace make parsing and storing difficult -- drop namespace as a component and add the namespace value to the name itself. - 2023-01-04 iamwillbar: a namespace component is beneficial, and a slash in a namespace should be URL-encoded in any event. - 2023-04-18 matt-phylum: spec says namespace should not be URL-encoded. [As of 2024-09-13 the spec says "Each namespace segment must be a percent-encoded string" and when percent-decoded a segment must not be empty or contain a "/".] | https://github.com/package-url/purl-spec/issues/204 | - If clarification is needed, we should add it. - TG1999's point needs to be addressed. | yes | - PURL namespace component | Issue | 204 | https://github.com/package-url/purl-spec/issues/204 | open | 2022-11-28 17:01:53 | 2023-04-18 19:25:56 | TG1999 | 2 | 2023-04-18 19:25:56 | matt-phylum | |||||||||||||
50 | 3low | pkgsrc support | #212 | no | 1) Should we invite the author to draft a pkgsrc spec? | - 2023-01-04 0-wiz-0: requested PURL support for pkgsrc as type or namespace, whichever is applicable. - No comments or other activity. | https://github.com/package-url/purl-spec/issues/212 | - Keep this issue open. - Decide next steps. | yes | - Proposed new type - PURL namespace component - pkgsrc | Issue | 212 | https://github.com/package-url/purl-spec/issues/212 | open | 2023-01-04 09:50:07 | 2023-01-04 09:50:07 | 0-wiz-0 | 0 | N/A | N/A | |||||||||||||||||
51 | zdone | Using a non-default repository with cargo | #215 | no | closed | 2024-11-19 JMH: I added a comment for the author: Hello @ctron . Thank you for opening this issue. If @bureado 's reply above addresses your question, please feel free to close this issue. 2024-11-20 JMH: ctron replied and closed the issue as completed. | 1) bureado's reply suggesting repository_url as the solution to the author's question looks correct -- if yes, we should reply accordingly to the author and close this issue. | - 2023-01-09 ctron: what should one do if not using the default cargo repo? - bureado asked whether the repository_url qualifier would suffice; ctron 2023-01-22 : "I guess so." - No further comments or activity. | https://github.com/package-url/purl-spec/issues/215 | - This appears resolved -- keep open, determine the status and close or decide next steps. | yes | - PURL qualifiers component | Issue | 215 | https://github.com/package-url/purl-spec/issues/215 | open | 2023-01-09 11:57:06 | 2023-01-23 07:31:13 | ctron | 2 | 2023-01-23 07:31:13 | ctron | |||||||||||||||
52 | 3low | Add support for Microsoft's cross-platform C and C++ package manager, `vcpkg` | #217 | no | 1) Should we invite the author to draft a vcpkg spec? | - 2023-02-11 AnthonyMastrean: add vcpkg as a type. - No comments but the issue history reflects that it has been referred to frequently in other issues, commits and PRs. | https://github.com/package-url/purl-spec/issues/217 | - Keep this issue open. - Decide next steps. | yes | - Proposed new type - vcpkg | Issue | 217 | https://github.com/package-url/purl-spec/issues/217 | open | 2023-02-11 16:14:36 | 2023-07-31 18:42:00 | AnthonyMastrean | PURL type definition | 0 | N/A | N/A | ||||||||||||||||
53 | 3low | Contradicting namespace case requirement for apk | #219 | no | JMH awaiting reply from author/others AND must be lowercased | 2024-11-19 JMH: Added comment: If it's accurate to say "It must be lowercased", why not just say that? I might be missing something, but atm it's not clear what `It is not case sensitive and` adds to the rule/spec other than the possibility of confusion. That phrasing is using many times, as well as the occasional `It is case insensitive and must be lowercased . . . .` as with the huggingface type. [https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#huggingface] | 1) The phrase "It is not case sensitive and must be lowercased." seems a bit self-contradictory, appears 12 times in the list of Known purl types, and needs to be clarified. (See also PR 301 addressing issue 226.) How about a simple "It must be lowercased"? If yes, invite the author to create a PR to do that and when done close the issue and PR. | - 2023-02-11 rnjudge: what are the casing rules for the apk namespace? The problematic language: "It is not case sensitive and must be lowercased." - 2023-02-11 Foxboron: "I just read it as "should be normalized"." rnjudge: It's still confusing. - No further comments or activity. | https://github.com/package-url/purl-spec/issues/219 | - Keep this issue open. - Decide next steps, e.g., reply and provide definitive answer -- it seems self-contradictory. | yes | - PURL namespace component - PURL capitalization | Issue | 219 | https://github.com/package-url/purl-spec/issues/219 | open | 2023-02-28 23:16:06 | 2023-02-28 23:24:38 | rnjudge | 2 | 2023-02-28 23:24:38 | rnjudge | |||||||||||||||
54 | zdone | Missing lengths for purl parts / and purl as a whole | #221 | yes | yes | closed and moved to a discussion | JMH: added 'Ecma specification' label. 2024-11-11 JMH: Need to address this issue 221 and issue 289 together -- both ask about max PURL length. In 289 pombredanne suggested a recommended max length of "something like 1000 ish or 2000 ish or powers of 2" and asked the author prabhu what he thought. No response yet. And there's been no response at all to issue 221. pombredanne closed this issue on 2025-06-26 and moved the topic to a discussion. See https://github.com/package-url/purl-spec/discussions/493. | 1) We can coordinate our response/resolution to this issue and issue 289. No one has responded yet to the author of this issue 221. Note that in response to prabhu's question when he opened issue 289, Philippe replied "If these articles are right, then we should likely come with a sensible recommend max, something like 1000 ish or 2000 ish or powers of 2." and asked prahbu for his recommendation. prabhu has not yet replied, and perhaps a gentle reminder to prabhu seeking his recommendation would be best for issue 289. | - 2023-03-10 xSeagullx: wants to know the max length of a PURL "which is quite important, for example if you need that purl to be stored in relational databases." - 2024-09-02 marob mentioned this in new issue 289. No subsequent comments or activity. | https://github.com/package-url/purl-spec/issues/221 | - Keep this issue open. - Decide next steps, e.g., reply and advise (assuming this is accurate) that PURL has no length limit though your storage environment might. | yes | - PURL max length | Issue | 221 | https://github.com/package-url/purl-spec/issues/221 | open | 2023-03-10 12:07:19 | 2023-03-10 12:07:19 | xSeagullx | 0 | N/A | N/A | ||||||||||||||
55 | 3low | Support for "virtual packages" / dependencies on interfaces? | #222 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-11 JMH: What is our view on this proposed "virtual package" type? Nobody has responded to the author's opening comment, which involves a proposed new type (not clear that it provides enough info to serve as a locator) , a proposed new scheme (out of scope for PURL), and https://peps.python.org/pep-0725/ ("Specifying external dependencies in pyproject.toml"). In his own repo (https://github.com/rgommers/peps/issues/3#issuecomment-1680944719) he reported the status of this purl-spec issue 222 like this: Also under Open Issues in the draft PEP, and no response on the purl-spec issue so far. PURL seems solid, but not well-maintained unfortunately. | 1) What is our view on this proposed "virtual package" type? | - 2023-03-23 rgommers: lengthy background description -- looking to understand how to express "abstract" dependencies like "a C compiler". He suggests an "abstract" PURL type, or pehaps a new scheme. - He also has a discussion of this issue at https://github.com/rgommers/peps/issues/3 - 2023-08-19 rgommers: added a link to the PEP that includes "this virtual package concept " and politely asked for any views a PURL maintainer might have. - No further comments or activity. | https://github.com/package-url/purl-spec/issues/222 | - Keep this issue open. - Decide next steps. - Maybe define a new qualifier? The value must be percent-encoded, which can handle a space, and while a key may not contain spaces, there is no such prohibition for a value. | yes | - Proposed new type - PURL qualifiers component - abstract | Issue | 222 | https://github.com/package-url/purl-spec/issues/222 | open | 2023-03-23 20:02:00 | 2023-08-19 10:37:14 | rgommers | 1 | 2023-08-19 10:37:14 | rgommers | |||||||||||||||
56 | 3low | Change the purl type "pypi" because it is a registered trademark of pypi.org | #225 | yes | yes | good candidate for early attention and resolution | JMH: added 'Ecma specification' label. 2024-11-11 JMH: Isn't this hypothetical question of trademark law entirely out-of-scope in a discussion of the PURL spec? If yes, a reply to that effect should be made by pombredanne. Might be a good candidate for easy resolution by pombredanne. | 1) How do we want to respond? | - 2023-03-31 alowayed: rename the "pypi" type to, e.g., "python" due to trademark concerns. - stevespringett: this would apply to others like "maven" but "Being a registered trademark in and of itself should not be cause to change the name of a purl type." - This seemes to have satisfied alowayed, who asked whether he should keep the issue open. - No reply to his question, though 2023-10-26 pradyunsg provided a link to the Python Foundation trademark policy. - No further comments. | https://github.com/package-url/purl-spec/issues/225 | - https://www.python.org/psf/trademarks/ provides that "'Python' is a registered trademark of the PSF" but does not mention "pypi". https://www.python.org/psf/trademarks-faq/ says use of the pypi logo might be OK to refer to the availability of a package on PyPi, which arguably is analogous to the use in a type component. - Keep this issue open and decide next steps. | yes | - PURL type definition | Issue | 225 | https://github.com/package-url/purl-spec/issues/225 | open | 2023-03-31 18:03:27 | 2023-10-26 07:11:57 | alowayed | 3 | 2023-10-26 07:11:57 | pradyunsg | ||||||||||||||
57 | 3low | NuGet package names should not be case sensitive | #226 | no | must be lowercased | 1) Does matt-phylum's 2024-04-12 PR 301 resolve this issue? If yes, in light of issue 219, we'd need to clarify this sentence: "It is not case sensitive and must be lowercased." | - 2023-03-31 matt-phylum: nuget names should not be case-sensitive but the test suite treats them as such. - stevespringett asked about non-Microsoft implementations of nuget and noted that "even if the package name is case insensitive, the purl subpath will be case sensitive" per MS documentation. What do the APIs require? - matt-phylum: V3 rules imply all names must be case-insensitive; gave historical info and concluded "it's safe to say that the names have always been case insensitive." - 2023-09-04 prabhu: lowercasing in the SBOM broke some tools so cdxgen takes a hybrid approach. - Further discusion between prabhu and matt-phylum, leading to matt-phylum opening PR 301 on 2024-04-12 to close the issue. That PR remains open. | https://github.com/package-url/purl-spec/issues/226 | - This issue appears to be resolved via matt-phylum's 2024-04-12 still-open PR 301. - Decide on next steps. | yes | - PURL name component - PURL capitalization | Issue | 226 | https://github.com/package-url/purl-spec/issues/226 | open | 2023-03-31 20:05:49 | 2023-09-05 13:38:09 | matt-phylum | 6 | 2023-09-05 13:38:08 | prabhu | ||||||||||||||||
58 | 2medium | PURL spec clarification about .dll files | #230 | yes | yes | good candidate for early attention and resolution | JMH: added 'Ecma specification' label. 2024-11-11 JMH: please see my "Action items" entry ==> | 1) Is it correct to think of a .dll as a file, not a package, and thus not covered by PURL, as prabhu's reply suggests? If so we can inform the author and suggest that he close the issue if he has no other PURL-related questions. But note these examples from the maven spec (https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#maven) that seem to identify a .dll file: pkg:maven/net.sf.jacob-projec/jacob@1.14.3?classifier=x86&type=dll pkg:maven/net.sf.jacob-projec/jacob@1.14.3?classifier=x64&type=dll | - 2023-05-24 ozblumen: looking for guidance re how PURL handles NuGet .dll files, which are not always unique to a particular package. - 2023-09-07 prabhu: "The letter p in purl stands for "package," whereas dll is a file." Offered info re how CycloneDX would handle this in an SBOM. - No further comments or activity. | https://github.com/package-url/purl-spec/issues/230 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL type definition | Issue | 230 | https://github.com/package-url/purl-spec/issues/230 | open | 2023-05-24 11:39:31 | 2023-09-07 11:12:47 | ozblumen | 1 | 2023-09-07 11:12:47 | prabhu | ||||||||||||||
59 | 3low | RPM Namespace is Ambiguous, Need Clarity | #239 | no | 1) This issue requires an experienced vetting re the question about vendors in an RPM namespace and includes a separate community member's request to provide examples of RedHat packages and a request involving RedHat's recent release of PURL guidelines (https://redhatproductsecurity.github.io/security-data-guidelines/purl/) that apparently raise more questions than they answer. | - 2023-06-27 dariush-griffin: the rpm type's namespace definition is unclear re meaning of "vendor". - 2023-12-11 ben-spiller: there are all sorts of interpretations applied in the wild, gives examples. - 2024-08-16 eskultety: the new public PURL guidelines still don't "provide clarity on how to infer the namespace value", seeks community cooperation to resolve. - No further comments. | https://github.com/package-url/purl-spec/issues/239 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL namespace component | Issue | 239 | https://github.com/package-url/purl-spec/issues/239 | open | 2023-06-27 16:45:00 | 2024-08-16 15:17:48 | dariush-griffin | 2 | 2024-08-16 15:17:48 | eskultety | |||||||||||||||||
60 | 2medium | Add Buildroot as a purl type | #240 | no | 1) Consider asking the author (who supports the project CyloneDX - Buildroot) to prepare a draft spec for a Buildroot type including type name (perhaps 'buildroot'). | - 2023-07-09 ptdropper: "The purl-spec has a place holder for buildroot and the time has come to add support." Offered to help if he could. "We need a type field to work with buildroot as a formal element of the specification." - No comments or other activity. | https://github.com/package-url/purl-spec/issues/240 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type - Buildroot | Issue | 240 | https://github.com/package-url/purl-spec/issues/240 | open | 2023-07-09 17:56:01 | 2023-08-31 17:59:07 | ptdropper | 0 | N/A | N/A | |||||||||||||||||
61 | 1high | Documentation around using PURLs as unique identifiers | #242 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-11 JMH: See also my "Action items" comment ==> See also issue 257 re pombredanne's comments that a PURL is not a unique identifier. In this issue 242, the author begins with an observation that "it is currently unclear what folks can do to help eliminate ambiguity", and ends his last comment with this request for guidance: It can be difficult to understand when given a purl let's just say something like the following as a contrived example: pkg:deb/foo and pkg:deb/foo@1.0 -- Based on the spec today it appears to be ecosystem dependent on how the first one should be interpreted. Is pkg:deb/foo mean latest without @1.0? . . . It can be difficult to discern and some basic guidelines even if it is ecosystem dependent would be helpful. 2024-11-12 JMH: the requests for guidance/best practices could also be addressed during the core-spec update process. | 1) This issue includes several detailed comments by Philippe emphasizing that a PURL is not a unique identifier. | - 2023-07-18 mlieberman85: notes there is confusion re what is required "to ensure that a PURL can only be resolved to a specific unique package"; suggests creating "documentation around best practices for using PURL for the identifier use case." - Comments from several others with info including examples of different PURLs that purportedly refer to the same package. - bureado asserts some of the examples are not the same package. - 2023-11-04 pombredanne: a PURL is not intended to and cannot guarantee it's a unique identifier. - There are additional comments expressing a desire for a unique identifier, other comments re unique identifiers, plus pombredanne replies. Last comment: 2023-11-20. | https://github.com/package-url/purl-spec/issues/242 | - This might be resolved but not clear -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL core specification | Issue | 242 | https://github.com/package-url/purl-spec/issues/242 | open | 2023-07-18 19:05:13 | 2023-11-20 22:25:33 | mlieberman85 | 16 | 2023-11-20 22:25:32 | mlieberman85 | |||||||||||||||
62 | 3low | purl.fyi: Convert all purl to URLs seamlessly | #244 | no | 1) Once Ayan suggested that the issue belongs in the packageurl-python repo, Hritik opened an issue there, but requests this issue be kept open to attract information he needs for his purl.fyi project. What is our view on such a use of an otherwise unrelated issue? | - 2023-07-31 Hritik14 announced https://purl.fyi. "The support for purls is not heavy and depends directly on purl2url.py . . . . Please list all the scattered code you can find for converting a purl to a URL here." - AyanSinhaMahapatra suggested moving this to the -python repo, Hritik did so 2023-08-01 but left this issue open in purl-spec "in case anyone finds non-pythonic way of converting purl to url". - Last comment was 2023-11-01 andrewpollock: "This is pretty cool." | https://github.com/package-url/purl-spec/issues/244 | - This looks resolved but not 100% clear -- keep this issue open for the moment. BTW, it seems much more like an announcement of a different though related and interesting utility than a PURL issue. Is there a better way of facilitating Hritik's project? - Need to determine status and decide next steps. | yes | - PURL community | Issue | 244 | https://github.com/package-url/purl-spec/issues/244 | open | 2023-07-31 16:32:00 | 2023-11-02 05:22:26 | Hritik14 | 3 | 2023-11-02 05:22:26 | andrewpollock | |||||||||||||||||
63 | 2medium | Standard hash algorithm names? | #246 | yes | yes | good candidate for early attention and resolution | JMH: added 'Ecma specification' label. 2024-11-12 JMH: please see my "Action items" entry ==> | 1) matt-phylum provided a list in response to Philippe's question. Perhaps the next step is for Philippe to reply. The question is: what should be in a list of approved names for standard hash algorithms used with a checksum qualifier? | - 2023-08-01 matt-phylum: "It would be helpful to have a list of standard hash algorithms with their correct keys." - 2024-03-04 pombredanne: what do you recommend? matt-phylum provided a list the same date. | https://github.com/package-url/purl-spec/issues/246 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. - See also https://github.com/package-url/purl-spec/issues/154 re adding a hash algorithm as a prefix to the name component. | yes | - PURL type definition | Issue | 246 | https://github.com/package-url/purl-spec/issues/246 | open | 2023-08-01 16:24:51 | 2024-03-18 15:39:23 | matt-phylum | 3 | 2024-03-18 15:39:22 | matt-phylum | ||||||||||||||
64 | 1high | `distro` qualifier should be standardized | #247 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-12 JMH: the clarification called for by this issue would occur primarily on a type-by-type basis, but query whether the core spec can be updated to provide some additional guidance as well. Or should this be addressed solely at the PURL type level? | 1) Is this issue ready for a reply inviting the author (and/or perhaps others) to draft a distro qualifier spec, with examples, for each ecosystem? Note that oliverchang has also posed a follow-up question for Philippe. | - 2023-08-01 another-rex: we need to design a format for the 'distro' qualifier for each ecosystem. - 2023-09-04 prabhu: cdxgen team has a custom definition of distro and distro_name - 2024-02-12 oliverchang: pinged pombredanne: should we "tighten down . . . the exact definition of how the distro qualifier is meant to be encoded?" - No further comments. | https://github.com/package-url/purl-spec/issues/247 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL qualifiers component | Issue | 247 | https://github.com/package-url/purl-spec/issues/247 | open | 2023-08-02 01:51:39 | 2024-02-12 09:16:47 | another-rex | 2 | 2024-02-12 09:16:46 | oliverchang | |||||||||||||||
65 | 2medium | Is there a name for the scheme:type/namespace/name section? | #249 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-12 JMH: please see my "Action items" entry ==> | 1) Is this a question about how each implementation handles PURL or partial-PURL inputs rather than a purl-spec issue? (This is also reminiscent of the purlcli 'versions' command.) | - 2023-09-28 lcarva: "I want users to input a partial purl in order to find the different available versions." What is the name for this section of the PURL? - 2023-09-28 stevespringett: This section "doesn't have a name per se. Many systems that do this, simply accept any purl string, parse it, and use only the portions they need for a given operation." - lcarva: accepting a complete purl is likely to cause confusion but documentation can deal with that. - 2023-10-30 prabhu: "either accept a complete PURL or don't." Incomplete PURLs can break workflows. - No further comments. | https://github.com/package-url/purl-spec/issues/249 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL core specification | Issue | 249 | https://github.com/package-url/purl-spec/issues/249 | open | 2023-09-28 17:38:23 | 2023-10-30 16:21:52 | lcarva | 3 | 2023-10-30 16:21:51 | prabhu | |||||||||||||||
66 | 1high | Support for specifying alias as part of purl | #251 | yes | yes | good candidate for early attention and resolution | JMH: added 'Ecma specification' label. 2024-11-12 JMH: please see my "Action items" entry ==> | 1) What is our view on prabhu's suggestion for an 'alias' qualifier to be used when a package's namespace and/or name are changed? | - 2023-10-05 prabhu: proposes use of qualifiers component to add alias(es) info for renamed scoped (@) npm packages. - No comments. | https://github.com/package-url/purl-spec/issues/251 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL qualifiers component - PURL namespace component | Issue | 251 | https://github.com/package-url/purl-spec/issues/251 | open | 2023-10-05 12:56:20 | 2023-10-05 12:56:20 | prabhu | 0 | N/A | N/A | ||||||||||||||
67 | 1high | Proposal: Support for BOM-Link | #252 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-12 JMH: please see my "Action items" entry ==> | 1) What is our view on prabhu's detailed proposal for a 'bomlink' qualifier linking a PURL to a BOM? | - 2023-10-05 prabhu: highly-detailed proposal: use qualifiers to provide "a link between a purl and a bom document" - No comments. | https://github.com/package-url/purl-spec/issues/252 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL qualifiers component | Issue | 252 | https://github.com/package-url/purl-spec/issues/252 | open | 2023-10-05 14:51:03 | 2023-10-05 14:58:08 | prabhu | 0 | N/A | N/A | |||||||||||||||
68 | 2medium | Proposal: `brew` type | #254 | no | 1) Is the related PR 281 opened 2023-12-04 poised for a final review and approval? | - 2023-10-19 woodruffw: add type for Homebrew - colindean: use qualifiers "to set the tap URL and name" (referring to the 'tap' syntax for external sources) - SMillerDev: provided comments - woodruffw to pombredanne, stevespringett: what else is needed? Ready to start a PR. - stevespringett: how should this type handle different platforms, e.g., MacOS and Linux? - Numerous comments re homebrew details - 2023-11-16 woodruffw: working on a PR - 2023-12-04 woodruffw: opened PR 281. - Extensive comments on the PR including from pombredanne. MikeMcQuaid approved PR 2024-02-05 followed by many more comments. woodruff posted in PR 2024-09-07: this PR has been ready for final review/merge since June. | https://github.com/package-url/purl-spec/issues/254 | - PR needs a final review and merge -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type - brew | Issue | 254 | https://github.com/package-url/purl-spec/issues/254 | open | 2023-10-19 18:40:28 | 2023-12-04 23:16:34 | woodruffw | PURL type definition | 12 | 2023-12-04 23:16:33 | woodruffw | ||||||||||||||||
69 | 1high | Support for Windows purl type | #255 | no | 1) There seems to be agreement on the need for some sort of Windows type, but disagreement on whether to use one of several different existing types or create a new type ('winget' has support from several commenters). Is 'winget' the answer? If so, we could invite the relevant backers to draft a detailed spec. See also issue 327 (question re support for Microsoft or Apple as PURL types -- includes PURL examples for Apple App Store). | - 2023-10-24 rhdesmond: add a Windows type, e.g., 'win'. - stevespringett: 'windows' would be too generic but support for Microsoft Store would be welcome. - alowayed: "Not the store, but for Windows exe files/packages." - prabhu: "Perhaps use swid with purl instead of reinventing another id?" - bureado: use 'generic'; "WinGet, Chocolatey, Store, etc. ... could be distinct types." More comments from prabhu, bureado and matt-phylum. - Nothing since 2023-11-30 detailed comment from matt-phylum. | https://github.com/package-url/purl-spec/issues/255 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type - winget | Issue | 255 | https://github.com/package-url/purl-spec/issues/255 | open | 2023-10-24 04:21:11 | 2023-11-30 16:01:51 | rhdesmond | PURL type definition | 10 | 2023-11-30 16:01:50 | matt-phylum | ||||||||||||||||
70 | 1high | What is a package? | #257 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-11 JMH: See also my "Action items" comment ==> As pombredanne noted in issue 242, a PURL is not intended to and cannot guarantee it's a unique identifier. 2024-11-12 JMH: as oej suggests in his comment, the request for guidance/best practices could/should be addressed during the core-spec update process. | 1) This is an issue with wide-ranging comments that seems to boil down to the question of when two PURLs "match" one another. The comments don't always define what they mean by "match", and as Philippe has written at some length in issue 242, a PURL is not a unique identifier. Perhaps we should consider a reply to that effect, with an invitation to the author to close the issue. | - 2023-10-25 big-guy: multiple questions re what is or is not a package, touches on numerous PURL components and more abstract issues, e.g., when are two PURLs the same package? - bureado, prabhu, pombredanne responded to various points raised. - Last comment: bureado 2023-11-09. | https://github.com/package-url/purl-spec/issues/257 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL core specification - PURL version component - PURL qualifiers component - PURL subpath component | Issue | 257 | https://github.com/package-url/purl-spec/issues/257 | open | 2023-10-25 19:57:15 | 2023-11-09 23:02:25 | big-guy | 12 | 2023-11-09 23:02:25 | bureado | |||||||||||||||
71 | 2medium | add `datetime` as version scheme | #263 | no | 1) What is our view on tschmidtb51's proposal? prabhu has replied that datetime should not be used as a version. The author says sometimes cloud environments use datetime as a version -- perhaps we could ask for examples. | - 2023-11-09 tschmidtb51: add a 'datetime' version scheme - 2024-03-21 prabhu: datetime should never be used for versions; what is wrong with semver? | https://github.com/package-url/purl-spec/issues/263 | - This issue will ultimately belong to univers but will be addressed initially in the PURL spec process. - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL/univers version scheme | Issue | 263 | https://github.com/package-url/purl-spec/issues/263 | open | 2023-11-09 10:16:26 | 2024-03-21 09:03:28 | tschmidtb51 | 1 | 2024-03-21 09:03:27 | prabhu | |||||||||||||||||
72 | zdone | add `semver` as version scheme | #264 | no | closed | JMH: pombredanne closed this as completed on 2025-05-28. | 1) Is it sufficient to direct the author's attention to the existing semvers version scheme in use? See https://github.com/aboutcode-org/univers/blob/main/src/univers/versions.py#L183 | - 2023-11-09 tschmidtb51: add a 'semver' version scheme | https://github.com/package-url/purl-spec/issues/264 | - This issue will ultimately belong to univers but will be addressed initially in the PURL spec process. - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL/univers version scheme | Issue | 264 | https://github.com/package-url/purl-spec/issues/264 | open | 2023-11-09 10:21:23 | 2023-11-09 10:21:23 | tschmidtb51 | 0 | N/A | N/A | |||||||||||||||
73 | 2medium | add `string` as version scheme | #265 | no | 1) What is our view on the author's 'string' proposal? | - 2023-11-09 tschmidtb51: add a 'string' (or 'lexicographic' or something similar) version scheme | https://github.com/package-url/purl-spec/issues/265 | - This issue will ultimately belong to univers but will be addressed initially in the PURL spec process. - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL/univers version scheme | Issue | 265 | https://github.com/package-url/purl-spec/issues/265 | open | 2023-11-09 10:26:45 | 2023-11-09 10:28:28 | tschmidtb51 | 0 | N/A | N/A | |||||||||||||||||
74 | 2medium | add `libversion` as version scheme | #266 | no | 1) What is our view on the author's 'libversion' proposal? | - 2023-11-09 tschmidtb51: add a 'libversion' version scheme | https://github.com/package-url/purl-spec/issues/266 | - This issue will ultimately belong to univers but will be addressed initially in the PURL spec process. - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL/univers version scheme | Issue | 266 | https://github.com/package-url/purl-spec/issues/266 | open | 2023-11-09 10:29:25 | 2023-11-09 10:29:25 | tschmidtb51 | 0 | N/A | N/A | |||||||||||||||||
75 | 2medium | mention `all` and `none` as version schemes | #267 | no | 1) What is our view on the author's 'all' and 'none' proposal? | - 2023-11-09 tschmidtb51: add 'all' and 'none' version schemes | https://github.com/package-url/purl-spec/issues/267 | - This issue will ultimately belong to univers but will be addressed initially in the PURL spec process. - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL/univers version scheme | Issue | 267 | https://github.com/package-url/purl-spec/issues/267 | open | 2023-11-09 10:37:20 | 2023-11-09 10:37:20 | tschmidtb51 | 0 | N/A | N/A | |||||||||||||||||
76 | 2medium | Add a reserved private namespace `x-` for version schemes | #268 | no | 1) What is our view on the author's private namespace proposal? This is reminiscent of the SPDX prefix used to name certain externally-defined licenses, e.g., LicenseRef-[some entity/identifier]-abrms. | - 2023-11-09 tschmidtb51: add a reserved private namespace 'x-' version scheme -- "Anyone can choose the version scheme name after the prefix x- freely." | https://github.com/package-url/purl-spec/issues/268 | - This issue will ultimately belong to univers but will be addressed initially in the PURL spec process. - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL/univers version scheme | Issue | 268 | https://github.com/package-url/purl-spec/issues/268 | open | 2023-11-09 10:54:46 | 2023-11-09 11:08:34 | tschmidtb51 | 1 | 2023-11-09 11:08:34 | tschmidtb51 | |||||||||||||||||
77 | 2medium | Support for Eclipse p2 types | #271 | no | 1) Note that p2 is already a "Candidate" type, and that the author opened PR 272 for his proposal. Given the 17 comments in the PR, it's unclear whether the current draft spec has addressed all of the comments. Consider asking the author whether that is the case and if so, perhaps PR 272 can be approved, merged and closed along with issue 271. | - 2023-11-15 ptziegler: add p2 types "so that support for those types could be handled by e.g. CycloneDX, when generating an SBOM." | https://github.com/package-url/purl-spec/issues/271 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type - p2 | Issue | 271 | https://github.com/package-url/purl-spec/issues/271 | open | 2023-11-15 14:57:49 | 2023-11-15 14:57:49 | ptziegler | 0 | N/A | N/A | |||||||||||||||||
78 | 3low | Model format for huggingface | #275 | no | 1) The 'distro' qualifier proposed by the author is already included in the specs for five "Known purl types'. Consider approving the proposal and inviting the author to create a PR. | - 2023-11-22 kakumara: there is no way to differentiate different formats/architectures in the purl type for huggingface -- add an extra qualifier | https://github.com/package-url/purl-spec/issues/275 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL qualifiers component - PURL type definition | Issue | 275 | https://github.com/package-url/purl-spec/issues/275 | open | 2023-11-22 11:46:15 | 2023-11-22 11:46:15 | kakumara | 0 | N/A | N/A | |||||||||||||||||
79 | 2medium | Additional qualifiers for oci type | #278 | no | 1) The initial discussion stalled out the day the issue was opened. Consider asking the author whether he thinks his proposal needs more input or is ready for a PR and, if the latter, inviting him to open a PR. | - 2023-11-30 prabhu: proposes several new qualifiers for the oci type - matt-phylum had questions about several proposed qualifiers and prabhu replied | https://github.com/package-url/purl-spec/issues/278 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL qualifiers component | Issue | 278 | https://github.com/package-url/purl-spec/issues/278 | open | 2023-11-30 18:06:36 | 2023-11-30 20:41:23 | prabhu | 2 | 2023-11-30 20:41:23 | prabhu | |||||||||||||||||
80 | zdone | Is "PURL" (all caps) considered an incorrect abbreviation? | #280 | yes | no | closed | JMH: added 'Ecma specification' label. 2024-11-12 JMH: I just posted this comment in the issue: Hi @joeattardi . I'm pleased to note that on 2024-10-11, Ecma TC54-TG2 approved the use of `Package-URL` and `PURL`. See https://github.com/Ecma-TC54/tg2/blob/main/meetings/2024-10-11.md If this answers the question you raised, please feel free to close this issue -- and if not, please advise what remains to be addressed. Thank you! [JMH update] @joeattardi replied almost immediately with this comment and closed his issue: @johnmhoran Thanks, that looks like a definitive answer to my question - PURL is OK! | 1) Once the 2024-10-11 minutes are published, add a comment that TC54-TG2 has approved Package-URL and PURL as the standardized naming convention. 2) Then close this as completed. | - 2023-12-04 joeattardi: what is the rule for PURL's casing? Several other comments with the same question. - 2024-07-17 pombredanne: "IMHO we should not be pedantic about case: you can use any way you like, PURL is not case sensitive. I like to use PURL, all uppercase when I mention it in writings. But when using it in code for a variable or field name, I use purl all lowercase. YMMV." | https://github.com/package-url/purl-spec/issues/280 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL capitalization | Issue | 280 | https://github.com/package-url/purl-spec/issues/280 | open | 2023-12-04 20:29:30 | 2024-07-17 22:00:54 | joeattardi | 4 | 2024-07-17 22:00:52 | pombredanne | ||||||||||||||
81 | 2medium | missing purl type for local swift packages | #283 | no | 1) What does the author mean by "local swift packages"? There is a 'swift' "Known purl type" but it does not list any qualifiers -- is the author asking for a qualifier to be added to the spec that could be used for a local package? Is 'repository_url' appropriate for this? Or perhaps we need for information. For example, the spec for 'composer' includes this: "Note: private, local packages may have no name. In this case you cannot create a purl for these." | - 2023-12-13 ilendemli: add a PURL type for swift | https://github.com/package-url/purl-spec/issues/283 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type - swift | Issue | 283 | https://github.com/package-url/purl-spec/issues/283 | open | 2023-12-13 17:01:21 | 2023-12-13 17:01:21 | ilendemli | 0 | N/A | N/A | |||||||||||||||||
82 | 2medium | Clarify whether the `type` should be required to be a "known" type or whether it can be an arbitrary field | #286 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-12 JMH: This does seem out of scope for PURL (except for some sort of brief mention), and instead is a matter to be raised with the relevant PURL implementation(s). If you agree, how would you like to respond to the author, and do you have any specific language in mind for the documentation you mentioned (presumably part of the core spec update)? | 1) Given Philippe's 2024-03-08 comment, is this ready for the documentation he mentions? In some respects the problem described seems related to GitHub's implementation rather than the PURL spec itself. | - 2024-01-15 jamietanna: GitHub's support for PURL 'type' fields looks for "known" types. "For instance, if we use packageurl-go, the pURL pkg:mix/req@~%3E%200.3 parses correctly" - matt-phylum: your example uses a version requirement, not a version number. - jamietanna: you are correct, my mistake. I guess I need to use known types if possible. Is GitHub within its rights to choose what types to support? - matt-phylum and pombredanne added their views on how unknown/new types should be processed; pombredanne 2024-03-08: "Let's document this. I think there is no reason to reject new types with the caveat that they may be harmless unless properly documented in the types spec doc." | https://github.com/package-url/purl-spec/issues/286 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL type definition | Issue | 286 | https://github.com/package-url/purl-spec/issues/286 | open | 2024-01-15 11:48:50 | 2024-03-08 15:02:30 | jamietanna | 4 | 2024-03-08 15:02:29 | pombredanne | |||||||||||||||
83 | 2medium | Support for vscode type | #287 | no | 1) We need to respond to the author's last question: "What is the process to get a type definition going?" Note that this question followed Philippe's comment asking the author if he could draft a type definition. Using the existing "Known" types seems an obvious first step to drafting the type spec he proposes -- are there one or two of those we'd want to recommend as models for him to adapt to his proposal? | - 2024-01-30 prabhu: add a Visual Studio Code type - 2024-03-08 pombredanne: looks fine, asked prabhu to draft a type definition - 2024-06-10 prabhu: "what about vsx similar to open-vsx?" - 2024-09-07 prabhu: "vscode is constantly in the news these days. What is the process to get a type definition going?" | https://github.com/package-url/purl-spec/issues/287 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type - vsx | Issue | 287 | https://github.com/package-url/purl-spec/issues/287 | open | 2024-01-30 21:43:06 | 2024-09-07 14:27:42 | prabhu | 3 | 2024-09-07 14:27:40 | prabhu | |||||||||||||||||
84 | zdone | Clarify the formal requirement on max length | #289 | yes | yes | closed | JMH: added 'Ecma specification' label. 2024-11-11 JMH: Need to address this issue 289 and issue 221 together -- both ask about max PURL length. In 289 pombredanne suggested a recommended max length of "something like 1000 ish or 2000 ish or powers of 2" and asked the author prabhu what he thought. No response yet. And there's been no response at all to issue 221. pombredanne closed this issue on 2025-06-26. | 1) We can coordinate our response/resolution to this issue and issue 221. (No one has yet responded to the author of issue 221.) Note that in response to prabhu's question when he opened this issue 289, Philippe replied "If these articles are right, then we should likely come with a sensible recommend max, something like 1000 ish or 2000 ish or powers of 2." and asked prahbu for his recommendation. prabhu has not yet replied. Perhaps a gentle reminder to prabhu seeking his recommendation would be best. | - 2024-02-05 prabhu: "We recently learned that a platform has a limit of 255 characters on the length of a purl. Please formally clarify any requirement on max length (even if it is unlimited). Include more compliance tests for length." - 2024-03-08 pombredanne: PURL spec has no specified max length; practical lengths come from tools; perhaps we should draft a "sensible recommend max, something like 1000 ish or 2000 ish or powers of 2." Asked what the author recommends. - Only additional comment: marob added a link to issue 221. | https://github.com/package-url/purl-spec/issues/289 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. - See also open issue 221. | yes | - PURL max length | Issue | 289 | https://github.com/package-url/purl-spec/issues/289 | open | 2024-02-06 07:55:24 | 2024-09-02 15:15:32 | prabhu | 2 | 2024-09-02 15:15:31 | marob | ||||||||||||||
85 | 2medium | [gem] clarify the platform qualifier for rubygems | #292 | no | 1) In response to prabhu's question when he opened this issue, Philippe asked prahbu for his recommendation. prabhu has not yet replied -- consider a friendly reminder to prabhu seeking his recommendation. | - 2024-02-12 prabhu: clarify the default platform for rubygems - 2024-03-08 pombredanne: what do you recommend? - 2024-03-08 andrew: distinguished 'platform' from 'ruby_version' field in the rubygems API. | https://github.com/package-url/purl-spec/issues/292 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL type definition - PURL qualifiers component | Issue | 292 | https://github.com/package-url/purl-spec/issues/292 | open | 2024-02-12 11:59:42 | 2024-03-08 15:37:45 | prabhu | 2 | 2024-03-08 15:37:43 | andrew | |||||||||||||||||
86 | 2medium | Should we support a leading v in golang packages? | #294 | no | golang-related | 2024-11-18 JMH: This is one of a group of golang-related issues and PRs that perhaps can be handled together, as suggested in issue #346. | 1) This simple initial question re a 'v' prefix evolved into a series of questions/comments re the PURL spec for go. And there are other issues on various go components. Perhaps we should ID and tackle all of them together. (It's possible that not all issues that discuss 'go' or 'golang' (some initial caps, too) have a 'go' label atm, and some of these might discuss go only in passing.) | - 2024-03-08 TG1999: should we add a 'v' prefix to Go version values? - matt-phylum: 'v' is part of the version - pombredanne: this is a mess; inclined to accept with 'v' but we need to agree on and document a canonical approach and tools will have to handle resulting issues. - matt-phylum and prabhu discuss in details other problems with the Go spec, agree it needs work and note that some examples are now invalid. - 2024-03-21 matt-phylum: "#204 might be the way to go. Combine the namespace and name into one value at the PURL level, don't encode slashes¹, and leave it up to the package type how to interpret it." | https://github.com/package-url/purl-spec/issues/294 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. - matt-phylum seems to say that some Go packages have slashes in the name. Query whether this is captured in the code. It seems that packageurl-python __init__.py defines a name as having no '/'. | yes | - PURL type definition - PURL version component - PURL subpath component - PURL name component - PURL namespace component - go | Issue | 294 | https://github.com/package-url/purl-spec/issues/294 | open | 2024-03-08 09:45:19 | 2024-03-21 19:04:55 | TG1999 | 8 | 2024-03-21 19:04:53 | matt-phylum | |||||||||||||||
87 | 2medium | Proposal: `github-release` type | #299 | no | 1) steiza from GitHub has provided a detailed proposal for a 'github-release' type. Are we ready to accept his offer to "write up a more formal pull request"? | - 2024-04-01 steiza (GitHub staff): provided a detailed proposal for a 'github-release' type. GH is improving GitHub Releases including adding immutability that is "externally auditable by publishing an in-toto release attestation, which includes a purl." BTW he asserts that "git tags are mutable." | https://github.com/package-url/purl-spec/issues/299 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type - github-release | Issue | 299 | https://github.com/package-url/purl-spec/issues/299 | open | 2024-04-01 19:15:32 | 2024-04-19 17:00:54 | steiza | 1 | 2024-04-19 17:00:53 | jhutchings1 | |||||||||||||||||
88 | 2medium | [Proposal] deno, jsr, and esm.sh | #302 | no | 1) Is this ready for a request to the author prabhu to draft specs for each proposed type, or do the various points raised by matt-phylum need further clarification/resolution? A set of draft specs might be best suited to move this issue forward. | - 2024-04-29 prabhu: proposed new types for 'deno', 'jsr', 'esmsh' and 'unpkg'. - matt-phylum questioned whether these are actually different types. matt-phylum and prabhu engaged in an extended discussion with matt-phylum challenging numerous aspects of prabhu's proposal. Last comment: 2024-04-30 matt-phylum. | https://github.com/package-url/purl-spec/issues/302 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type - deno - jsr - esmsh - unpkg | Issue | 302 | https://github.com/package-url/purl-spec/issues/302 | open | 2024-04-29 21:47:32 | 2024-04-30 15:44:06 | prabhu | 9 | 2024-04-30 15:44:05 | matt-phylum | |||||||||||||||||
89 | 2medium | Default maven repository | #303 | no | 1) How do we want to handle this reported change in the default repository for maven? What if the author of an existing maven PURL intended to point to the prior default repo in effect when he or she created the PURL? Manual correction of all such PURLs? How are such authors notified of the spec change? prabhu suggests "purl doesn't have to assume any default repository and [the spec could] allow tools to always form the full values including the repository url." | - 2024-05-02 prabhu: the spec's default repo for maven differs from the "Remote Repository reported by maven"; seeks confirmation that to reach this repo its URL must be added to a PURL's 'repository_url' qualifier. | https://github.com/package-url/purl-spec/issues/303 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL type definition - PURL qualifiers component | Issue | 303 | https://github.com/package-url/purl-spec/issues/303 | open | 2024-05-02 23:36:29 | 2024-05-03 21:25:47 | prabhu | 2 | 2024-05-03 21:25:46 | prabhu | |||||||||||||||||
90 | 2medium | Define package types for ASF projects (Apache Software Foundation) | #305 | no | 1) Where does this proposal stand given stevespringett's comment inter alia that most Apache projects are already covered by PURL-supported package ecosystems? | - 2024-06-14 pombredanne: proposed a new type for Apache Software Foundation "projects", perhaps using 'asf' rather than 'apache'. - 2024-06-14 brianf: what is the use case? A "project" is not a "package". - 2024-07-07 stevespringett: most Apache projects already have type support (citing https://projects.apache.org/projects.html?language); adding 'asf' would cause confusion. | https://github.com/package-url/purl-spec/issues/305 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type - asf | Issue | 305 | https://github.com/package-url/purl-spec/issues/305 | open | 2024-06-14 13:27:57 | 2024-07-08 04:04:00 | pombredanne | 3 | 2024-07-08 04:03:59 | stevespringett | |||||||||||||||||
91 | 2medium | Debian Repository URL Format should be clarified | #306 | no | 1) Since the 'deb' type has no default repository, which (if any) of the other qualifiers (or sets of qualifiers) proposed by the various commenters would best resolve the issue? | - 2024-06-17 captn3m0: need to clarify the repository_url for Debian packages. - 2024-06-17 matt-phylum: "There is already a qualifier for the architecture, which has a special value "source" for indicating that it's a source package instead of a binary package. But it looks like the qualifiers for release (stable) and repository (main or contrib or non-free) is missing." - Further discussion re details, other qualifiers. | https://github.com/package-url/purl-spec/issues/306 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL type definition - PURL qualifiers component | Issue | 306 | https://github.com/package-url/purl-spec/issues/306 | open | 2024-06-17 04:16:07 | 2024-06-17 13:25:32 | captn3m0 | 4 | 2024-06-17 13:25:31 | captn3m0 | |||||||||||||||||
92 | 3low | Namespace clarification for third-party Debian/Ubuntu Package | #307 | no | 1) Can this be resolved by adopting t-8ch's suggestion to use the 'Origin' field when available for the deb namespace component? Namespace is optional so an empty 'Origin' field would not violate the spec. | - 2024-06-17 captn3m0: 'deb' namespace definition does not address third-party Debian or Ubuntu packages. - t-8ch says Debian reposcontain an optional "Origin" field that can be used. captn3m0: what if the field is empty? t-8ch: "No idea. Either make it optional or empty." | https://github.com/package-url/purl-spec/issues/307 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL type definition - PURL namespace component | Issue | 307 | https://github.com/package-url/purl-spec/issues/307 | open | 2024-06-17 04:47:42 | 2024-07-02 08:47:29 | captn3m0 | 3 | 2024-07-02 08:47:28 | t-8ch | |||||||||||||||||
93 | 1high | [PURL-TYPE: golang] fix type spec regarding path segments | #308 | yes | yes | golang-related AND must be lowercased | JMH: added 'Ecma specification' label. 2024-11-12 JMH: Please see my "Action items" comment ==> How would you like to handle this detailed golang-specific query that also involves aspects of the core spec? Note that there are a number of other golang issues, and a number of other issues re uppercase/lowercase -- both are relatively common topics in the open issues/PRs. 2024-11-18 JMH: This is one of a group of golang-related issues and PRs that perhaps can be handled together, as suggested in issue #346. | 1) This issue and the detailed and wide-ranging comments raise a number of go-related issues re the current 'golang' spec as well as some broader issues (e.g., changing the core PURL spec). The author jkowalleck expressed the view that the comments miss the focused point of the issue he raised re the current 'golang' type. Consider asking the author for as succinct a statement as possible of the issue he has raised. | - 2024-06-24 jkowalleck: the golang spec requires namespace and name to be lowercase, but Go module names are case sensitive (see https://github.com/google/deps.dev/issues/93) and this conflict causes problems. Proposed (1) allowing case sensitivity or (2) namespace must be empty and name must be encoded (a breaking change). - matt-phylum, prabhu and jkowalleck discussed -- and disagreed on -- other approaches including distinct package types. | https://github.com/package-url/purl-spec/issues/308 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL type definition - PURL namespace component - PURL name component - PURL capitalization - go | Issue | 308 | https://github.com/package-url/purl-spec/issues/308 | open | 2024-06-24 08:56:40 | 2024-07-04 17:30:33 | jkowalleck | 15 | 2024-07-04 17:30:33 | jkowalleck | ||||||||||||||
94 | 1high | Proposal: Solution for Purl Type Definitions | #310 | yes | yes | JMH: added 'Ecma specification' label. 2024-11-12 JMH: Please see my "Action items" comment ==> What can we do to assist stevespringett? | Philippe replied on 2024-10-27 to stevespringett's most recent comment. Is there anything else we can do in the near term to assist? | - 2024-06-24 stevespringett: replace ambiguous textual 'type' definitions with more reliable machine-readable definitions -- proposes defining PURL types in a 'JSON Schema' with one file per type, aggregated into a single distributable. - matt-phylum: "Is this talking about a JSON schema (a schema that is JSON) or JSON Schema (https://json-schema.org/) (a specific meta schema for specifying JSON objects)?" - stevespringett: "I want to develop a JSON Schema that defines how to define a purl." Working on a PoC. | https://github.com/package-url/purl-spec/issues/310 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL validation | Issue | 310 | https://github.com/package-url/purl-spec/issues/310 | open | 2024-06-24 17:30:13 | 2024-06-24 21:35:33 | stevespringett | PURL type definition | 2 | 2024-06-24 21:35:32 | stevespringett | ||||||||||||||
95 | 2medium | [vers] how to deal with problematic symbols such as brackets | #313 | no | 1) Can we provide prabhu with guidance re "version specifiers with problematic symbols such as brackets"? | - 2024-07-15 prabhu: the 'vers' spec needs clarification re how to handle version specifiers with problematic characters like brackets. | https://github.com/package-url/purl-spec/issues/313 | - Appears unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL/univers version scheme - Version ranges | Issue | 313 | https://github.com/package-url/purl-spec/issues/313 | open | 2024-07-15 18:07:45 | 2024-07-15 18:07:45 | prabhu | 0 | N/A | N/A | |||||||||||||||||
96 | zdone | Make a versioned release and have pkg:package-url/purl-spec@1.0.0 | #319 | no | closed | 1) What do we want to do with this issue from bact asking for a v1.0 release of a PURL spec? jkowalleck closed this issue on 2024-10-21 and tagged it 'Closed as not planned'. Keep it closed? | - 2024-08-07 bact: please release a versioned Package URL spec. - 2024-10-21 jkowalleck closed this issue and tagged it 'Closed as not planned'. | https://github.com/package-url/purl-spec/issues/319 | - Unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL spec release schedule | Issue | 319 | https://github.com/package-url/purl-spec/issues/319 | open | 2024-08-07 09:57:20 | 2024-08-07 09:57:20 | bact | 0 | N/A | N/A | ||||||||||||||||
97 | zdone | The CPAN urls with :: doesn't pass syntax check in Python lib | #324 | no | closed | 2024-11-14 JMH: closed this issue after merging related PR 325 based on jkowalleck's approval. | 1) The issue concerns the Python implementation of the cpan spec. matt-phylum proposed a test and noted many other implementations fail that test. giterlizzi opened PR 325 with a set of 6 tests, not including matt-phylum's test. Shouldn't this issue be converted -- or supplemented -- by an issue opened in each of the implementation repos? (See issue 165 opened by oej in packageurl-python on 2024-08-27. | - 2024-08-27 oej: packageurl-python fails to validate 'pkg:cpan/LWP::UserAgent', which contradicts the CPAN spec. - 2024-08-27 sjn: the CPAN spec is correct -- Modules MAY contain :: as namespace delimiter, while Distributions MUST NOT contain :: in it's [sic] name - 2024-08-27 (1) matt-phylum suggested we add a new test to the suite, (2) giterlizzi noted several proposed tests are included with PR 325 and (3) oej opened package-url/packageurl-python#165 (Valid CPAN package URLs fail validation). | https://github.com/package-url/purl-spec/issues/324 | - Unresolved -- keep this issue open. - Need to determine status and decide next steps. - Note that __init__.py seems to prohibit the inclusion of user:pass@host:port in namespace but OK in name. Is this a disagreement between PURL security concerns vs. CPAN spec? | yes | - PURL type definition - PURL validation | Issue | 324 | https://github.com/package-url/purl-spec/issues/324 | open | 2024-08-27 19:03:05 | 2024-08-28 06:21:50 | oej | 4 | 2024-08-28 06:21:49 | oej | |||||||||||||||
98 | zdone | Google Git PURL type | #326 | no | closed | 1) Do we want to add a comment re jkowalleck's example PURL that responds to the author's inquiry? Note: Philippe closed and converted to a discussion on 2024-10-30. | - 2024-08-28 jsdratm: what is the correct PURL type for https://chromium.googlesource.com/libyuv/libyuv/? | https://github.com/package-url/purl-spec/issues/326 | - Unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - PURL type definition | Issue | 326 | https://github.com/package-url/purl-spec/issues/326 | open | 2024-08-28 19:01:41 | 2024-08-28 19:01:41 | jsdratm | 0 | N/A | N/A | ||||||||||||||||
99 | 2medium | App Stores | #327 | no | 1) The author asked about types for Microsoft and Apple App Stores, provided several examples for Apple App Store and suggested a need for 5 Apple App Store types. What is our view on his proposal and examples? Do we want to invite him to prepare detailed draft specs for all Apple and Microsoft App Store types he has in mind? See also issue 255 (proposal for Windows PURL type). | - 2024-09-08 tonylturner: any plans "to support App Stores such as Microsoft or Apple as PURL types?" - stevespringett: no reason not to but we'd need (and do not have) specific details. | https://github.com/package-url/purl-spec/issues/327 | - Unresolved -- keep this issue open. - Need to determine status and decide next steps. | yes | - Proposed new type - appstore-apple | Issue | 327 | https://github.com/package-url/purl-spec/issues/327 | open | 2024-09-08 01:21:54 | 2024-09-08 01:21:54 | tonylturner | 0 | N/A | N/A | |||||||||||||||||
100 | 2medium | Improve VERS spec | #328 | no | 1) This is a list of pointers and has no current associated action items. | #328 pombredanne opened on 2024-09-27 | https://github.com/package-url/purl-spec/issues/328 | 328 | https://github.com/package-url/purl-spec/issues/328 |