Re: Proposed spec for external packages
On Tue, Aug 4, 2015 at 5:00 AM, Yev Bronshteyn
Here is the spec for the proposed EternalPackage element. While I touch onYev:
I guess you meant External and not Eternal....
I provided a few comments to your proposed spec in the doc at
The gist of my feedback:
- SWID tags are a nice concept but look to me at best new and may be
emerging, and at worst an unknown quantity fraught with many issues:
- no open neutral registry (like a IANA);
- little or no known usage in the FOSS world and no known usage by
any Linux distro as far as I know;
- a de-jure standard backed primarily by commercial entities for
commercial licensing compliance, with a closed and pay-walled-garden
- little general adoption that I could find beyond a few commercial
vendors of asset management tools and a few (albeit large) commercial
software vendors like Microsoft;
- and yet another new standard on top of another standard: based on
the NIST discussion draft you provided the ambition of SWID tags seems
to be a rehash on top CPEs.
- Why limit the purpose to security? identification has a rather
- Why limit an external id to CPE and SWID tags? There are several
other sources of (rather widely used) globally unique ID:
- Linux distros package name/version
- other package managers name/version such as npm, rubygems, pypi, maven, etc
- repo or project names on hosting sites such as Github, Google Code
(RIP), Apache, Eclipse, Sourceforge and several others.
All these should be supported and are IMHO far better and more widely
used that SWID tags. Hence my suggestion for something more inclusive
An interesting question is how you map these to one another: for
instance what is the corresponding Debian package for a Fedora RPM?
What would be the common id for the upstream of these two packages?
What is the corresponding CPE if any?