In the spreadsheet, there is a column for a URL. Most of the ~100 rows have a link to a GitHub repository, with notable exceptions including the Linux kernel, golang, gnupg and git which have a pointer to the homepages (and sigstore, but I think that's an omission)
Does that mean that only the code in those repositories is in scope as critical? What happens if a project splits the "critical to trust" functionality across two or more repositories in the same organization?
For example, for ceph, it sounds like ceph/ceph is in scope, but ceph/ceph-ansible is not. Is that by design? Another example, one project under the powershell organization is powershell/openssh-portable. Is that in scope? And another one is puppetlabs/puppet, would puppetlabs/facter be in scope?
I'm sure there's been a discussion on this somewhere, the comments in the spreadsheet point to this question, and in some cases like Signal, apache and mysql, the links point to the entire organization. I think it would be helpful to have a 1:n relationship between named project and "components of interest", described for example via a normalized name/identifier for the "friendly" project name (1:) and purls for the SCM or other generic release pointers (:n)
In the spreadsheet, there is a column for a URL. Most of the ~100 rows have a link to a GitHub repository, with notable exceptions including the Linux kernel,
golang,gnupgandgitwhich have a pointer to the homepages (andsigstore, but I think that's an omission)Does that mean that only the code in those repositories is in scope as critical? What happens if a project splits the "critical to trust" functionality across two or more repositories in the same organization?
For example, for
ceph, it sounds likeceph/cephis in scope, butceph/ceph-ansibleis not. Is that by design? Another example, one project under thepowershellorganization ispowershell/openssh-portable. Is that in scope? And another one ispuppetlabs/puppet, wouldpuppetlabs/facterbe in scope?I'm sure there's been a discussion on this somewhere, the comments in the spreadsheet point to this question, and in some cases like Signal,
apacheandmysql, the links point to the entire organization. I think it would be helpful to have a 1:n relationship between named project and "components of interest", described for example via a normalized name/identifier for the "friendly" project name (1:) andpurls for the SCM or other generic release pointers (:n)