Greetings all,
It would be good to capture these in any produced SPDX document. I'm thinking adding the user doing the creation as an additional creator would be appropriate, but there is also a good argument for adding them as a reviewer. In terms of feedback on the different approaches, I am thinking a "wiki-like" approach in #1 would best match the openness of the site and allow anyone with somewhat validated credentials to update the information. It is also the simplest to implement. In terms of security and authenticating the user, I don't see too much difference between the 3. If you want to have stronger security, I would recommend supporting some form of public key signing. Most development oriented systems use SSH public keys for this purpose (see Git's use of public keys <http://git-scm.com/book/en/Git-on-the-Server-Generating-Your-SSH-Public-Key > ). Being more secure, it is also more cumbersome for the user, so unless you think it is critical to authenticate the user, I would suggest the simpler approach. Github, for example, requires stronger authenticate for commits, but allows a weaker authentication for most other activities. Gary From: [email protected] [mailto:[email protected]] On Behalf Of Matt Germonprez Sent: Wednesday, March 19, 2014 6:07 AM To: Jeremiah Foster Cc: [email protected] Subject: Re: Questions/Concerns about online verification of SPDX Documents. We would edit an SPDX for primarily two things: - Adding document/package/file comments - Documenting a Concluded License. Right now, with any of our scanners that we use (FOSSology and Ninka), we put NOASSERTION in every Concluded License field. We put the results of what the scanners found in Declared License. Maybe 'authenticity' isn't the right word. It is more to document the meta-data associated with the SPDX document and its edits. Tracking who has edited and concluded what. Regards, Matt On Wed, Mar 19, 2014 at 6:44 AM, Jeremiah Foster <[email protected]> wrote: On Wed, Mar 19, 2014 at 11:52 AM, Matt Germonprez <[email protected]> wrote: Hi Jeremiah, The ideas behind this are: 1) Creation of an SPDX dashboard similar to: http://spdxhub.ist.unomaha.edu/dashboard Cool. I can see having signed SPDX docs that I can compare as a very nice feature of a dashboard. that will display SPDX docs. We are adding functionality that will allow for the editing of SPDX documents, comparison of SPDX docs (between different versions of the same package), the 'sign off' of SPDX docs by people. Why would you edit a SPDX document? Isn't it meant as a machine-readable BoM that is automatically generated on the target? 2) More specific to this question, once an SPDX docs is created following a FOSSology or Ninka scan, it can be further edited via the dashboard and signed-off by a person or a series of people as a measure of SPDX document authenticity. How does the signed-off by act as a measure of document authenticity? If I can edit the document online it has lost its authenticity of 1-to-1 correspondence with the target. If I need to ensure the integrity of a given target, now I need to trust every editor of the document as well as the document generation process itself. Its easier for me to just check the target with an existing tool and not use SPDX which needs additional verification. Are you enabling the ability to add meta-data in the form of a signature only? In which case the underlying SPDX document does not get changed? Regards, Jeremiah Regards, Matt On Wed, Mar 19, 2014 at 3:26 AM, Jeremiah Foster <[email protected]> wrote: On Wed, Mar 19, 2014 at 7:21 AM, ajay medury <[email protected]> wrote: Hello, My name is Ajay Medury, and I am student taking Prof. Germonprez's class on Open Source Tool Development. My team and I have been working on getting the SPDX Dashboard up and running and have run into some issues when considering the online verification (signing) of SPDX documents. I don't understand the use case. What do you mean with "online verification"? Do you mean someone logging into a web site with OAUTH? And what do you mean with "signing"? Are you talking about signing with a cryptographic key? Overall I don't really understand where you're going with this. Doesn't the BoM need to be generated from the actual hardware target? Otherwise, how do you know it comes from the target? What evidence do you provide that the generated BoM corresponds in a 1 to 1 fashion with the built binary target? In Debian for example you can use debsums which has a cryptographically secure hash sum generated on the binary package which corresponds 1 to 1 with the source package. The source package holds the BoM which is also signed with a strong cryptographic key and hash summed. In the source package is the pristine source code for the binary as well as the BoM which denotes copyright and license for any and all corresponding artifacts. This is the chain of causality if you will and can be displayed on the web, but changing the BoM changes the hash sum and compromises integrity. What is the process for the SPDX dashboard? Does it aim to allow one to generate a BoM from a package online? Cheers, Jeremiah We were hoping to get the community's help on this matter as we have discussed three possible alternatives on solving this issue. They are listed below: 1. Allowing anyone to signoff (verify) an SPDX document after they enter and confirm their identity (via a conformation email sent to them) in the form of email ids. Then keep track of all verifications in a sort of log, which would be recorded in our common database (can answer questions about this if needed). This sounds like a wiki? 1. Allow only a preselected group of users to signoff on documents after they first provide and confirm (same as above) their email id, which the system will then check to see if this is present in the list of preselected individuals. All of these signoffs will also be recorded in the database. 2. Have a simple login system which has a list of email ids and passwords stored in the common database, and allows users to login t signoff on documents. All interactions here, including the login and signoff will be logged. My team and I greatly the community's input on this matter and look forward to hearing from you. Thank you, Ajay B. Medury (& Team Dashboard) _______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech -- ============================================= Jeremiah C. Foster GENIVI Community Manager Pelagicore AB Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden Mobile: +46 (0)730 93 0506 <tel:%2B46%20%280%29730%2093%200506> E-Mail: [email protected] ============================================= === NOTE === The information contained in this E-mail message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. ============= _______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech -- Mutual of Omaha Associate Professor of Information Systems University of Nebraska at Omaha <http://myweb.unomaha.edu/~mgermonprez/> Vita <http://ocrl.unomaha.edu/> Open Communities Lab <http://1.usa.gov/17mbd1Z> NSF Grant on Open Communities -- ============================================= Jeremiah C. Foster GENIVI Community Manager Pelagicore AB Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden Mobile: +46 (0)730 93 0506 <tel:%2B46%20%280%29730%2093%200506> E-Mail: [email protected] ============================================= === NOTE === The information contained in this E-mail message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. ============= -- Mutual of Omaha Associate Professor of Information Systems University of Nebraska at Omaha <http://myweb.unomaha.edu/~mgermonprez/> Vita <http://ocrl.unomaha.edu/> Open Communities Lab <http://1.usa.gov/17mbd1Z> NSF Grant on Open Communities
_______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
