Re: Proposed spec for external packages

Sai Uday Shankar Korlimarla

Hi Philippe, HI Yev 

Philippe, You are right about SWID.
Yev, I may be biased over using CPEs and not using SWIDs. Here are my points on SWID.

1. SWID looks nice to have for software asset management and identification. CPEs can do just the same job.

2. SWID are not available in the open. I know that I currently can identify a minimum of 1902702 products by CPEs.

Instance: cpe:/a:google:chrome:43.0.2357.134 has CVE CVE-2015-5605. It is easy to perform cross-linked correlation from many sources as you pointed out. Here the below URL gives us "openSUSE-2015-513.nasl"

So we have "openSUSE-2015-513.nasl" "CVE-2015-5605"  and "cpe:/a:google:chrome:43.0.2357.134" all talking about one single product google chrome version 43.

I don't see how SWIDs will be able to help do this.

3. If I consume SWID, unless I tie the SWID to a CPE, I will not be able to move forward and gain vulnerability information. I could just stick with CPEs then.

4. Trusting a standard without paying $400 is going to be a bit difficult. Open standards are way better. I think it is easier to live with duplicates in CPE dictionary and still be able to accurately get CVE information using cross-linked information as philippe point out.

5. While ISO, Microsoft and Symantec may sound fancy, the real question is on how open is this tag information. If SWID is an open-tagging scheme, it would definitely be worth considering.

6. Anyone can read a CPE and know what it is and do not need a digital signature for integrity for that, i.e. CPEs are open and readable. SWIDs will contain information that is not consumable immediately. Either SWIDs are flawed or is duplication. As philippe points out, if SWIDs would be re-hash over CPE, it would definitely be worth consuming/exploring.

I may be wrong in my opinions but am open for learning more.



On Tue, Aug 4, 2015 at 9:15 AM, Sai Uday Shankar Korlimarla <iamudayshankar@...> wrote:


-------- Original Message --------
Subject: Fwd: Re: Proposed spec for external packages
From: Thomas T Gurney <ttg@...>
Sent: Tuesday, August 4, 2015, 09:14
To: Sai Uday Shankar Korlimarla <iamudayshankar@...>

Date: 4. Aug 2015 08:34
From: pombredanne@...
To: ybronshteyn@...
Cc: spdx@...
Subject: Re: Proposed spec for external packages

On Tue, Aug 4, 2015 at 5:00 AM, Yev Bronshteyn
<ybronshteyn@...> wrote:
Here is the spec for the proposed EternalPackage element. While I touch on
usage in the beginning, I'll discuss some specific use cases in the context
of SpdxTools on the call.

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
general purpose.

- 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
and generic.

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?

Philippe Ombredanne
Spdx mailing list

Join to automatically receive all group messages.