Closed MarcinHoppe closed 3 years ago
MarcinHoppe
commented
3 years ago Would it make sense to move those documents to a collaborative Markdown edit such as HackMD? It would make it a bit easier to move the final documents to this repo when we're done.
I am curious to know your opinion about this idea.
JasonKeirstead
commented
3 years ago From my experience in lots of other groups, whether or not Google Docs vs MD files is better depends a lot on the document type and who is going to be editing it. Longer highly-active documents that have a lot of collaboration, really need mature commenting and formatting capabilities beyond what HackMD can provide. Also if you have documents being collaborated upon by non-technical folks, Google Docs is much simpler. As an example - collaborating on a group specficiation draft, or whitepaper, in HackMD is not going to go well.
But for above documents - which are simple documents - HackMD would be fine....
SecurityCRob
commented
3 years ago On 12/4/20 8:17 AM, Jason Keirstead wrote:
From my experience in lots of other groups, whether or not Google Docs vs MD files is better depends a lot on the document type and who is going to be editing it. Longer highly-active documents that have a lot of collaboration, really need mature commenting and formatting capabilities beyond what HackMD can provide. Also if you have documents being collaborated upon by non-technical folks, Google Docs is much simpler. As an example - collaborating on a group specficiation draft, or whitepaper, in HackMD is not going to go well.
But for above documents - which are simple documents - HackMD would be fine....
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ossf/wg-vulnerability-disclosures/issues/80#issuecomment-738778546, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQRFDLAOGEPKP5YEP6FCB3DSTDONHANCNFSM4UE5HYYQ.
I think the ultimately end-state of artifacts we create should be an MD file in git once all of the heavily lifting of creating/editing the document is worked out. Once the group crafts and publishes that final first draft git lends itself to those future (smaller) patches to the artifact and the change management thereafter.
-- That is the Way. I have spoken, CRob
Christopher "CRob" Robinson
Modern Renaissance Man for Red Hat Product Security
....and other duties as required
irc: CRob | tz: UTC -5:00 (US/Eastern) | email: CRob@RedHat.com
Red Hat Product Security contact: secalert@redhat.comI think there is relatively little controversy around the final format, the question is about the format used in the "early days" where collaborative editing and commenting are probably very valuable.
It seems like Google Docs are providing exactly that. Per @kaywilliams suggestion on the mailing list, I will try to move those documents to the OpenSSF Google Drive if permissions let me do that (I am not the owner of all of them).
SecurityCRob
commented
3 years ago Cross-posting from OpenSSF Dev Best Practices - https://github.com/ossf/wg-best-practices-os-developers/issues/38
To assist us in understanding the user stories we want to address as part of this working group I started drawing out a high-level workflow of the process of finding and fixing vulnerabilities in open source and third-party components that I'd love to get everyone's feedback on.
As the diagram is viewed, let me explain the elements/convergences. There are at least 3 separate working groups working to address part of the problem "How do vulnerabilities get fixed within OSS software" (probably also several others I'm unaware of): OpenSSF Vulnerability Disclosure Group - OSS maintainer/ecosystem-focused, trying to standardize and provide guidance on vulnerability remediation in OSS components. This is the "head-end" of the process from my perspective. OpenSSF Developer Best Practice Group - OSS maintainer-focused, trying to provide guidance and resources around secure software development, which elements include reacting to vulnerabilities as they are identified (and techniques/tools to capture them before they become escapes). This is the longer-term. lessons-learned, teaching aspect that will help share whatever standards processes the community agrees upon. FIRST PSIRT Third Party Component Management Group - Focused on Vendors/Suppliers that consume (or are involved on some level) with third party hardware and software components.
The diagram shows a high-level flow from when a vuln gets report to where an fix is released to where a downstream supplier picks that fix up and provides it to their consumers. Our OpenSSF groups are only primarily concerned with the first few steps of this where a Reporter/Finder and Maintainer/Project interact and fix the issue (or not). There are several external factors like industry standards, concepts like secure supply chain, slide, or software bill of materials that are related to this process, but not directly part of the work we're concerned with at this stage (or in these particular groups). The Supplier piece is also less interesting to maintainers, so I'm not looking for feedback on that angle in this forum at this point (if you have feels about it, let me know and I can get that to the appropriate group).
I welcome thoughts, suggestions, collaboration on the attached diagram and the concepts detailed within. Hopefully this can help us focus in on the gaps/pain points of this process to address developer/maintainer concerns. Thanks!
In the past several working group meeting we discussed the need to document pain points in the current state of open source vulnerability disclosure processes for various stakeholders. This would allow us to solidify goals and objectives for this WG.
Google Docs we can use to collaborate on use cases for specific personas: