1. Spdx
  2. Topics

Proposed spec for external packages

Kate Stewart
 

Hi Uday,

On Mon, Aug 10, 2015 at 9:54 AM, Sai Uday Shankar Korlimarla <skorlimarla@...> wrote:
Hi Kate,

Thanks a ton for the clarification. It definitely helps, I am sorry for this delayed response.

I have one more question/doubt though. In 2.2.1 Corpus Tags, What I infer is that either the distributor or software vendor produces the SWID tag. In the future, assuming SWIDs are prevalent, Are we considering SPDX tools to accommodate creation of SWID tags if a vendor does not do so?

I don't think so.   This is an optional field to permit linkage to security information IF it exists.   If it doesn't exist,  its more the responsibility of the package creator or distributor to register it (or the person finding a security issue - might force it to be created).   SPDX would only reference it if it exists (its an optional field for that reason).   Similar story for CPE's I think.

If someone can describe a good use case that is counter though, we can certainly discuss further.  :-)

Kate
Sai Uday Shankar Korlimarla
 

Hi Kate,

Thanks a ton for the clarification. It definitely helps, I am sorry for this delayed response.

I have one more question/doubt though. In 2.2.1 Corpus Tags, What I infer is that either the distributor or software vendor produces the SWID tag. In the future, assuming SWIDs are prevalent, Are we considering SPDX tools to accommodate creation of SWID tags if a vendor does not do so?

Regards
Uday

On Tue, Aug 4, 2015 at 3:10 PM, Kate Stewart <kstewart@...> wrote:
Hi Uday,

On Tue, Aug 4, 2015 at 10:20 AM, Sai Uday Shankar Korlimarla <skorlimarla@...> wrote:
Hi Philippe, HI Yev 

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

Proposal was to permit use of either.  It was not mandating that one or another needs be used.
 
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.
 
Agree.  

Also,  see appendix A in NIST-8060 where  CPE can be derived from SWID. 


2. SWID are not available in the open.

NIST-8060 is an emerging NIST standard, so are not present today, but if the standard is approved, they will be in the future.
 
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"

http://www.security-database.com/detail.php?alert=CVE-2015-5605

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.

SWID's are the proposed standard to eventually replace CPEs in the infrastructure.
Adding the ability to reference to them as an external identifier in SPDX is a future proofing measure.    
 

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.

For your purposes,  use the CPEs.   see earlier comments about future proofing. 
 

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.

Completely agree CPE is what should be linked to today.  

From the NIST 8060 (which is open):
1532 At some point in the future, as SWID tags become widely used and available, SWID tags will be 
1533 able to supplant CPE names as the primary means of identifying software products and 
1534 correlating vulnerability reports with those products. Until that occurs, SWID tags need to 
1535 provide certain data values from which CPE names could be mechanically generated. These 
1536 generated CPE names can be used to populate the CPE dictionary and to allow for searching 
1537 repositories like the NVD. 


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.

Its a standard that is in "public review" right now, from NIST.  


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.

See Appendix A for the mapping. 
 

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

Hopefully the above clarifies.

Kate 
Jeremiah Foster <jeremiah.foster@...>
 



On Wed, Aug 5, 2015 at 4:56 PM, Kate Stewart <kstewart@...> wrote:


On Tue, Aug 4, 2015 at 3:18 PM, Jeremiah Foster <jeremiah.foster@...> wrote:


On Tue, Aug 4, 2015 at 8:09 PM, Kate Stewart <kstewart@...> wrote:
On Tue, Aug 4, 2015 at 11:40 AM, Mike Milinkovich <mike.milinkovich@...> wrote:
On 04/08/2015 12:15 PM, Kate Stewart wrote:
I agree we should not depend on closed standards.  However,  the question is do we want to be able to reference to external packages that other systems are supporting?

 Beats me. But to me the proposed solution looks much worse than whatever problem it is that you're trying to solve. Speaking of which, where is the document that describes the problem you're trying to solve?

The base document that these changes are being proposed for is SPDX 2.0 see: http://spdx.org/SPDX-specifications/spdx-version-2.0 

My impression is that the consumers of open source software are trying to create a system to make it easier to identify and manage the artifacts used within their organization. Is that correct?

The goal of software package data exchange (SPDX) is to create a common way to communicate copyright and licensing information in the entire ecosystem.   There are producers and consumers through out the entire supply chain.   

Open source projects are built on top of other open source projects all the time (libraries, dependencies, etc.)    Providing a clear way that can be machine readable and trusted,`

How do you propose it be trusted? It is just a string! You need substantially more infrastructure than just a SPDX tag to generate trust. 

There is no SPDX tag - per se.   An SPDX document for a package contains hash codes at the file level.  (SHA1, SHA256 ),  as well as an algorithm for a verification code to be generated from the component files at the package level. 

in  Section 3 Package Section see 3.8 Package Verification Code & 3.9 Package Checksum.
in  Section 4 File Section see 4.4 File Checksum.

The proposal is to add cross link to other databases where security information is being tracked already.

All I can do is comment on the SPDX spec from the perspective of a small business and FOSS contributor. The spec is already quite heavy weight and adding this tag might make sense for the larger commercial organizations, but it doesn't fit the need for a lightweight process that SME's use in my experience.

Today this is primarily through the CPE,  however NIST is reviewing SWID proposal to be used, and so linking to the software identifier tag (SWID tag),  seems to be useful from a security vulnerability tracking perspective.   ie. lets not duplicate work, but rather make other's work easy to find.     

I don't see the use case. I already use Debian's security tracking which relies on CVE's and Debian package versions and that works quite well. I personally wouldn't consume this additional tag but I see how it might be used to market commercial tools. 

As an aside, after NIST's work with crypto ciphers I wonder how closely FOSS projects will follow their proposals?  
 
There is another proposal already in discussion to include external identifiers which include the Debian, Fedora, Maven, etc. repositories. 

Kate

Regards,

Jeremiah
Kate Stewart
 



On Tue, Aug 4, 2015 at 3:18 PM, Jeremiah Foster <jeremiah.foster@...> wrote:


On Tue, Aug 4, 2015 at 8:09 PM, Kate Stewart <kstewart@...> wrote:
On Tue, Aug 4, 2015 at 11:40 AM, Mike Milinkovich <mike.milinkovich@...> wrote:
On 04/08/2015 12:15 PM, Kate Stewart wrote:
I agree we should not depend on closed standards.  However,  the question is do we want to be able to reference to external packages that other systems are supporting?

 Beats me. But to me the proposed solution looks much worse than whatever problem it is that you're trying to solve. Speaking of which, where is the document that describes the problem you're trying to solve?

The base document that these changes are being proposed for is SPDX 2.0 see: http://spdx.org/SPDX-specifications/spdx-version-2.0 

My impression is that the consumers of open source software are trying to create a system to make it easier to identify and manage the artifacts used within their organization. Is that correct?

The goal of software package data exchange (SPDX) is to create a common way to communicate copyright and licensing information in the entire ecosystem.   There are producers and consumers through out the entire supply chain.   

Open source projects are built on top of other open source projects all the time (libraries, dependencies, etc.)    Providing a clear way that can be machine readable and trusted,`

How do you propose it be trusted? It is just a string! You need substantially more infrastructure than just a SPDX tag to generate trust. 

There is no SPDX tag - per se.   An SPDX document for a package contains hash codes at the file level.  (SHA1, SHA256 ),  as well as an algorithm for a verification code to be generated from the component files at the package level. 

in  Section 3 Package Section see 3.8 Package Verification Code & 3.9 Package Checksum.
in  Section 4 File Section see 4.4 File Checksum.

The proposal is to add cross link to other databases where security information is being tracked already.

Today this is primarily through the CPE,  however NIST is reviewing SWID proposal to be used, and so linking to the software identifier tag (SWID tag),  seems to be useful from a security vulnerability tracking perspective.   ie. lets not duplicate work, but rather make other's work easy to find.     

There is another proposal already in discussion to include external identifiers which include the Debian, Fedora, Maven, etc. repositories. 

Kate
Jeremiah Foster <jeremiah.foster@...>
 



On Tue, Aug 4, 2015 at 8:09 PM, Kate Stewart <kstewart@...> wrote:
On Tue, Aug 4, 2015 at 11:40 AM, Mike Milinkovich <mike.milinkovich@...> wrote:
On 04/08/2015 12:15 PM, Kate Stewart wrote:
I agree we should not depend on closed standards.  However,  the question is do we want to be able to reference to external packages that other systems are supporting?

 Beats me. But to me the proposed solution looks much worse than whatever problem it is that you're trying to solve. Speaking of which, where is the document that describes the problem you're trying to solve?

The base document that these changes are being proposed for is SPDX 2.0 see: http://spdx.org/SPDX-specifications/spdx-version-2.0 

My impression is that the consumers of open source software are trying to create a system to make it easier to identify and manage the artifacts used within their organization. Is that correct?

The goal of software package data exchange (SPDX) is to create a common way to communicate copyright and licensing information in the entire ecosystem.   There are producers and consumers through out the entire supply chain.   

Open source projects are built on top of other open source projects all the time (libraries, dependencies, etc.)    Providing a clear way that can be machine readable and trusted,`

How do you propose it be trusted? It is just a string! You need substantially more infrastructure than just a SPDX tag to generate trust. 
 
Regards,

Jeremiah
Kate Stewart
 

Hi Uday,

On Tue, Aug 4, 2015 at 10:20 AM, Sai Uday Shankar Korlimarla <skorlimarla@...> wrote:
Hi Philippe, HI Yev 

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

Proposal was to permit use of either.  It was not mandating that one or another needs be used.
 
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.
 
Agree.  

Also,  see appendix A in NIST-8060 where  CPE can be derived from SWID. 


2. SWID are not available in the open.

NIST-8060 is an emerging NIST standard, so are not present today, but if the standard is approved, they will be in the future.
 
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"

http://www.security-database.com/detail.php?alert=CVE-2015-5605

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.

SWID's are the proposed standard to eventually replace CPEs in the infrastructure.
Adding the ability to reference to them as an external identifier in SPDX is a future proofing measure.    
 

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.

For your purposes,  use the CPEs.   see earlier comments about future proofing. 
 

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.

Completely agree CPE is what should be linked to today.  

From the NIST 8060 (which is open):
1532 At some point in the future, as SWID tags become widely used and available, SWID tags will be 
1533 able to supplant CPE names as the primary means of identifying software products and 
1534 correlating vulnerability reports with those products. Until that occurs, SWID tags need to 
1535 provide certain data values from which CPE names could be mechanically generated. These 
1536 generated CPE names can be used to populate the CPE dictionary and to allow for searching 
1537 repositories like the NVD. 


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.

Its a standard that is in "public review" right now, from NIST.  


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.

See Appendix A for the mapping. 
 

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

Hopefully the above clarifies.

Kate 
Philip Odence
 

Adding to Kate’s comments, the SPDX presumption is that developers of open source software would like to:
a. have their software used by others
b. make sure the software is used under the terms they desire, as expressed in a license

We believe SPDX makes is easier for organizations to use open source and to make sure they comply with the developer’s desires, and therefore aligns with the above. That’s why we don’t think the idea is fundamentally flawed. We do understand that even assuming we are right, there’s a chicken/egg problem in getting producers of open source to participate.


From: Kate Stewart <kstewart@...>
Date: Tuesday, August 4, 2015 at 2:09 PM
To: Mike Milinkovich <mike.milinkovich@...>
Cc: "spdx@..." <spdx@...>
Subject: Re: Proposed spec for external packages

On Tue, Aug 4, 2015 at 11:40 AM, Mike Milinkovich <mike.milinkovich@...> wrote:
On 04/08/2015 12:15 PM, Kate Stewart wrote:
I agree we should not depend on closed standards.  However,  the question is do we want to be able to reference to external packages that other systems are supporting?

Beats me. But to me the proposed solution looks much worse than whatever problem it is that you're trying to solve. Speaking of which, where is the document that describes the problem you're trying to solve?

The base document that these changes are being proposed for is SPDX 2.0 see: http://spdx.org/SPDX-specifications/spdx-version-2.0 

My impression is that the consumers of open source software are trying to create a system to make it easier to identify and manage the artifacts used within their organization. Is that correct?

The goal of software package data exchange (SPDX) is to create a common way to communicate copyright and licensing information in the entire ecosystem.   There are producers and consumers through out the entire supply chain.   

Open source projects are built on top of other open source projects all the time (libraries, dependencies, etc.)    Providing a clear way that can be machine readable and trusted, will allow a lot of the discussions about what license applies, etc. to go away.    If this key information is a transparent part of the package - rather than a time intensive opaque exploration,  then its easier for other open source projects that use that package,  to comply with the terms of the code they are using.    Upstream projects can use it to ensure clarity about the licenses the code is provided under, and enable automation (and stop getting bugged by folks who are trying to interpret their wishes).  Distributions and Packagers (including other open software distribution), can use it to summarize what they've received from elsewhere (ie. upstreams) and what they've added.   
 
If so, what I am missing is how you are going to motivate the producers of open source to use such a system. You're already getting our libre software for free. Why are we going to do more work to make your lives easier?

Many open source packages depend on other open source packages - making it clear what obligations come with the use of the software saves the developers lots of investigation work - whether they are part of an open source project or a commercial company that is developing software. 

If we can have open tools that are trusted to generate these software license summaries, it will stop developers from having to do full manual inspection when releasing their software.
 

My apologies in advance if I'm completely off base here.

Happy to discuss the goals of this further with you in a phone call some time.

Kate

 

Kate Stewart
 

On Tue, Aug 4, 2015 at 11:40 AM, Mike Milinkovich <mike.milinkovich@...> wrote:
On 04/08/2015 12:15 PM, Kate Stewart wrote:
I agree we should not depend on closed standards.  However,  the question is do we want to be able to reference to external packages that other systems are supporting?

 Beats me. But to me the proposed solution looks much worse than whatever problem it is that you're trying to solve. Speaking of which, where is the document that describes the problem you're trying to solve?

The base document that these changes are being proposed for is SPDX 2.0 see: http://spdx.org/SPDX-specifications/spdx-version-2.0 

My impression is that the consumers of open source software are trying to create a system to make it easier to identify and manage the artifacts used within their organization. Is that correct?

The goal of software package data exchange (SPDX) is to create a common way to communicate copyright and licensing information in the entire ecosystem.   There are producers and consumers through out the entire supply chain.   

Open source projects are built on top of other open source projects all the time (libraries, dependencies, etc.)    Providing a clear way that can be machine readable and trusted, will allow a lot of the discussions about what license applies, etc. to go away.    If this key information is a transparent part of the package - rather than a time intensive opaque exploration,  then its easier for other open source projects that use that package,  to comply with the terms of the code they are using.    Upstream projects can use it to ensure clarity about the licenses the code is provided under, and enable automation (and stop getting bugged by folks who are trying to interpret their wishes).  Distributions and Packagers (including other open software distribution), can use it to summarize what they've received from elsewhere (ie. upstreams) and what they've added.   
 
If so, what I am missing is how you are going to motivate the producers of open source to use such a system. You're already getting our libre software for free. Why are we going to do more work to make your lives easier?

Many open source packages depend on other open source packages - making it clear what obligations come with the use of the software saves the developers lots of investigation work - whether they are part of an open source project or a commercial company that is developing software. 

If we can have open tools that are trusted to generate these software license summaries, it will stop developers from having to do full manual inspection when releasing their software.
 

My apologies in advance if I'm completely off base here.

Happy to discuss the goals of this further with you in a phone call some time.

Kate

 
Jeremiah Foster <jeremiah.foster@...>
 



On Tue, Aug 4, 2015 at 6:40 PM, Mike Milinkovich <mike.milinkovich@...> wrote:
On 04/08/2015 12:15 PM, Kate Stewart wrote:
I agree we should not depend on closed standards.  However,  the question is do we want to be able to reference to external packages that other systems are supporting?

Its impossible to answer this question, largely because there's not enough data -- what are these "other systems" (Windows?) and what are the "external packages"? 

 Beats me. But to me the proposed solution looks much worse than whatever problem it is that you're trying to solve. Speaking of which, where is the document that describes the problem you're trying to solve?

My impression is that the consumers of open source software are trying to create a system to make it easier to identify and manage the artifacts used within their organization. Is that correct?

This is my assumption as well.
 
If so, what I am missing is how you are going to motivate the producers of open source to use such a system. You're already getting our libre software for free. Why are we going to do more work to make your lives easier?

My apologies in advance if I'm completely off base here.

I think you're on target. 

Much of this design is coming from the pseudo-standard world where standards are made on paper and forced to be adopted. FOSS works in completely the opposite direction; multiple implementations are tested and then adopted as a standard once proven. If this is not the planned way of working then I suggest looking at W3C's requirements for standards adoption which *requires* two independent implementations of the standard before it can be adopted. 

Regards,

Jeremiah 
Mike Milinkovich
 

On 04/08/2015 12:15 PM, Kate Stewart wrote:
I agree we should not depend on closed standards. However, the question is do we want to be able to reference to external packages that other systems are supporting?
Beats me. But to me the proposed solution looks much worse than whatever problem it is that you're trying to solve. Speaking of which, where is the document that describes the problem you're trying to solve?

My impression is that the consumers of open source software are trying to create a system to make it easier to identify and manage the artifacts used within their organization. Is that correct? If so, what I am missing is how you are going to motivate the producers of open source to use such a system. You're already getting our libre software for free. Why are we going to do more work to make your lives easier?

My apologies in advance if I'm completely off base here.

--
Mike Milinkovich
mike.milinkovich@...
+1.613.220.3223 (mobile)
Kate Stewart
 



On Tue, Aug 4, 2015 at 10:45 AM, Mike Milinkovich <mike.milinkovich@...> wrote:
On 04/08/2015 9:34 AM, Philippe Ombredanne wrote:
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.

https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharinghttps://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharing

Yev:
I guess you meant External and not Eternal....

I provided a few comments to your proposed spec in the doc at
https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit#

 To add to Philippe's comments, and speaking on behalf of a major producer of open source software, the proposal for an "External Security and Asset Management Identifier" seems to be fundamentally flawed. A quick perusal of the tagvault.org website tells me that the spec is not publicly available (i.e. you must buy it for $265 from ANSI), and that the tools used to tag software assets are available only to members of their private club.

The SPEC being referred to is a NIST one,  rather than ANSI.   see:  http://csrc.nist.gov/publications/PubsDrafts.html#NIST-IR-8060 
Which is open.

Its in its second reading right now, and its in a public comment window, before NIST adopts it. 

IMO, any requirement that open source communities use a closed standard, and proprietary tools to annotate their open source code is dead on arrival.

I agree we should not depend on closed standards.  However,  the question is do we want to be able to reference to external packages that other systems are supporting?

Kate
Kate Stewart
 



On Tue, Aug 4, 2015 at 10:43 AM, Kate Stewart <kstewart@...> wrote:
Hi Philippe,
    The document you commented on was from last week's discussion.  
Your input is appreciated and you're opinion is lining up 
with some of the thoughts expressed as part of the external identifier
proposal from 2 weeks ago from Bill Schineller.

here's the link: 
 

Kate

On Tue, Aug 4, 2015 at 8:34 AM, Philippe Ombredanne <pombredanne@...> wrote:
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.
>
> https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharinghttps://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharing
>

Yev:
I guess you meant External and not Eternal....

I provided a few comments to your proposed spec in the doc at
https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit#

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
called tagvault.org;
 - 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?

--
Cordially
Philippe Ombredanne
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Mike Milinkovich
 

On 04/08/2015 9:34 AM, Philippe Ombredanne wrote:
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.

https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharinghttps://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharing
Yev:
I guess you meant External and not Eternal....

I provided a few comments to your proposed spec in the doc at
https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit#
To add to Philippe's comments, and speaking on behalf of a major producer of open source software, the proposal for an "External Security and Asset Management Identifier" seems to be fundamentally flawed. A quick perusal of the tagvault.org website tells me that the spec is not publicly available (i.e. you must buy it for $265 from ANSI), and that the tools used to tag software assets are available only to members of their private club.

IMO, any requirement that open source communities use a closed standard, and proprietary tools to annotate their open source code is dead on arrival.

--
Mike Milinkovich
Executive Director,
Eclipse Foundation
mike.milinkovich@...
+1.613.220.3223 (mobile)
Kate Stewart
 

Hi Philippe,
    The document you commented on was from last week's discussion.  
Your input is appreciated and you're opinion is lining up 
with some of the thoughts expressed as part of the external identifier
proposal from 2 weeks ago from Bill Schineller.

Kate

On Tue, Aug 4, 2015 at 8:34 AM, Philippe Ombredanne <pombredanne@...> wrote:
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.
>
> https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharinghttps://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharing
>

Yev:
I guess you meant External and not Eternal....

I provided a few comments to your proposed spec in the doc at
https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit#

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
called tagvault.org;
 - 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?

--
Cordially
Philippe Ombredanne
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
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"

http://www.security-database.com/detail.php?alert=CVE-2015-5605

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.

Regards
Uday






Regards
Uday

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

Regards
Uday



-------- 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@...>
CC:




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.

https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharinghttps://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharing

Yev:
I guess you meant External and not Eternal....

I provided a few comments to your proposed spec in the doc at
https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit#

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
called tagvault.org;
- 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?

--
Cordially
Philippe Ombredanne
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Yev Bronshteyn
 

D’oh! Arrgh! Other grunting noises!

Here is the correct link. Terribly sorry for the confusion/inconvenience.




On Aug 4, 2015, at 9:04 AM, Kate Stewart <kstewart@...> wrote:

Hi Yev,
    The spec you linked to was the one I created for las week's call.
Is there a different document we should be refering to?

Thanks, Kate

On Mon, Aug 3, 2015 at 10:00 PM, 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.


Thanks!

_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Philippe Ombredanne
 

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.

https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharinghttps://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharing
Yev:
I guess you meant External and not Eternal....

I provided a few comments to your proposed spec in the doc at
https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit#

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
called tagvault.org;
- 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?

--
Cordially
Philippe Ombredanne
Kate Stewart
 

Hi Yev,
    The spec you linked to was the one I created for las week's call.
Is there a different document we should be refering to?

Thanks, Kate

On Mon, Aug 3, 2015 at 10:00 PM, 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.


Thanks!

_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Yev Bronshteyn
 

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.

https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharinghttps://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharing

Thanks!

1 - 19 of 19