VOTE - Adopt OpenVEX as project within the OpenSSF under Vuln Disclosure Working Group (WG)

VEX is an emerging spec, and tool set to ease the burden of determining vulnerability exploitation likelihood within components used during a build. OpenVEX is a community currently developing a spec, GO and Rust libraries, and a toolset to further determine minimal requirements as defined by the CISA VEX working group, GO and RUST libraries enabling the ingestion of metadata in other VEX implementations, and the toolset to create, merge, and attest VEX documents. OpenVEX has asked for adoption within the OpenSSF vulnerability disclosures working group towards its spec, libraries, and toolset being further developed and towards ISO specification through the PAS Submitter process
We are seeking the working group's opinion on whether or not to adopt the OpenVEX project (https://github.com/openvex/spec) as an official OpenSSF project under the Vulnerability Disclosure Working Group.  If adopted, the working group would collaborate with the project team on refinements and updates to the specification, collaborate on possible tooling to implement the project seamlessly into developer workflows, and provide support for the ultimate proposal of OpenVEXas an industry standard through the OpenSSF's industry standardization processes.
Working Group Maintainers, Collaborators, and Contributors (https://github.com/ossf/wg-vulnerability-disclosures#governance) are invited to formally vote on their choice to adopt this project, or not.  Additionally, non-working group members are welcome to express their opinions, but not as official voting members of the group.  Members please complete your vote and/or add your comments no later than the next working group meeting,  22March2023, so the results can be discussed in our call.
If this project is adopted by the WG, next steps would be following the TAC's project submission procedure for donated content & intellectual property review (https://github.com/ossf/tac/blob/main/process/project-lifecycle.md).

I've participated in the NTIA/now CISA VEX working group meetings since the second meeting in September 2020. You need to understand two facts about OpenVEX:
First, there is no approved CISA document called "Minimal Requirements". When Chainguard presented to this group more than a month ago, there was only a draft document with that name, that was still being debated by the VEX working group. This group is a collection of individuals convened under CISA's auspices, but is in no way a function of CISA. CISA has no regulatory authority for the private sector and can't define "requirements" for any organizations except federal agencies (of course, this document doesn't apply to federal agencies any more than it does the private sector). The document just describes guidelines that are the personal recommendations of some members of the VEX working group.
The document was approved by the working group two weeks ago, and now has to go through intensive vetting by CISA's lawyers, which may take a couple of months. Only then will it be an official document. CISA may well decide that they don't want to allow a document to be published under CISA's logo with a title like "Minimum Requirements" - so the document may still be amended or killed altogether. I want to point out that this document contradicts in several ways a document published a year ago by the working group, called "VEX Use Cases" (available at cisa.gov/sbom).
Second, the use case that "OpenVEX" addresses - removing false positives from vulnerability scans - has nothing to do with the primary VEX use case, which is identifying non-exploitable vulnerabilities identified for components listed in an SBOM for a particular version of a product. I personally like the OpenVEX use case and I don't care whether or not they use the term "VEX", but this has nothing to do with the NTIA/CISA VEX program.
I've written two blog posts on OpenVEX, available at "Tom Alrich's Blog". I will write a third post soon.

I'm not a voting member of the WG and my support is probably obvious, but non-binding +1 from me!

I'm not a voting member of the WG either, but I'm a fan of VEX and like that OpenVEX avoids taking sides in the SBOM format debate. +1 from me.

A working group can decide if it will take on specification or formal standardization efforts, and on what (as long as it meets the usual OpenSSF requirements on score, openness, licensing, etc.). In particular, formal standardization is a lot of work and shouldn't be taken on lightly.
However, I do want to clarify that formal standardization is a possible path for OpenSSF work. The OpenSSF Charter expressly denotes the recommended license for work that might lead to formal standardization.  The Linux Foundation's Joint Development Foundation (JDF) is recognized as an ISO/IEC JTC 1 Publicly Available Specification (PAS) Submitter.
I don't think this proposal is recommending that it become a formal standard, just that the WG take this work on as a specification effort. If the desire is to make it a formal standard, that should be raised at some point (probably as a separate issue).

I don't think this proposal is recommending that it become a formal standard, just that the WG take this work on as a specification effort. If the desire is to make it a formal standard, that should be raised at some point (probably as a separate issue).

Correct. We've taken the necessary precautions to set ourselves up for that work no using the community specification process, but there's a long road before we're ready to start it.

I'm a little perplexed why this proposal wasn't brought to OASIS, which is already working on VEX. Why setup a "competing VEX initiative"? OASIS is an international standards organization, I worked with OASIS on the ebXML standard, now listed as ISO  15000 standard. Sorry, but this "fracturing" of VEX efforts makes no sense to me.

I am not sure how we are tracking votes. I as well vote no.
Much like @Foxboron I disagree that this group should be throwing weight behind a competing standard to things that already exist, further complicating adoption of VEX in general by making more confusion. We should be rallying behind things that exist and making them better.

"like that OpenVEX avoids taking sides in the SBOM format debate"

@trevrosen Sorry, this is an incorrect statement. OpenVex/Chainguard staff do prefer SPDX and they have spread misinformation about CycloneDX in multiple meetings. They also had "closed" discussions with the SPDX team before making public announcements.

No. Unless CISA (or other standards authority) adopts this variant of VEX, I am against endorsing OpenVEX.  I also view it as having a fracturing effect at OASIS and SBOM standards groups are working towards unification.  It is disingenuous to create/endorse something that competes with (and may overwrite) known work being done at associate organizations we recognize (like CISA and OASIS) without any attempt to encourage collaboration.

REA has been processing SPDX and CycloneDX SBOM's for 3 years in SAG-PM and they are both viable, effective SBOM formats - no need to create drama where none needs to exist.
I will say, the CycloneDX community is very engaged and supportive of implementers. The SPDX community is also very supportive. You can't go wrong choosing either SPDX of CycloneDX.

@costica11 I'm merely pointing out that SBOM format agnosticism is a stated design goal in the spec's FAQ. 😄

+1 on this proposal.

+1 👍

VEX is key to automating the vulnerability remediation lifecycle, and OpenVEX is a step forward in that direction, +1.

I'm not a voting member of the WG and my support is probably obvious, but non-binding +1 from me!

i don't know if i am able to vote but +1. So, superficially i am tracking openvex. Is it fair to say enablement with tooling to enable threat intel and management could help adoption and that an investment could be made to get this going?  @shebashio is happy to find paths to enable. My bottom line is this is 100% an integral component or artifacts that make use of what often is not understood.
vulnerability data is mostly leveraged to identify code level hard exploits. Threat intel is a different beast.

Based on some comments, I'm guessing some people may not be aware that VEX reports on software products that ARE NOT AFFECTED by a new vulnerability. A Security Advisory identifies products that ARE AFFECTED by a new vulnerability. This is the yin-yang view of the same CVE VEX=not affected SA=affected.
A NIST VDR is product based, it shows the vulnerability status of each component in a software product SBOM on an on-going basis (living document)

+1! I'd love to see more tooling and OSS innovation around VEX through OpenVEX!

I'm not a part of the TSC or the WG, but I vote +1 for open standards and tooling for VEX, which I strongly believe we will need as a "negative SBOM" or even a "software disclaimer of materials" in order to be able to qualify SBOMs. I would have preferred a solution contained within SBOMs themselves, but this addition appears to be the best we can do for now.

@trishankkarthik FYI there already are VEX Standards that can be embedded in in the SBOM, like CycloneDX VEX.
This request is to invent another one.

Well, this is interesting... OWASP, who is an OpenSSF associate member, has a VDR/VEX format. SPDX which is a another LF project is developing their own - to be compatible with OWASP CycloneDX. Having a third format with ties to OpenSSF would likely be a public relations issue for the foundation as it promotes continued fragmentation rather than unification.
Also, keep in mind that VEX is only half of the solution. The other half is VDR which is already a requirement in some federal and commercial instances.

For those chiming in - I'd kindly request that you take the time to review the presentation I shared today in the WG meeting: https://docs.google.com/presentation/d/1ekre4ML3tMZ8pODAdLKIwsi1BsiT_q3o_QifTKkW5L0/edit#slide=id.p
It addresses a lot of these questions.
This is a clearly a heated topic, so I'd also kindly request that we keep this issue on-topic and scoped to the vote @SecurityCRob initiated it with.

@dlorenc The only two slides in that deck of substance - 13 and 14 - both have multuple statements each that are flat-out wrong. I agree we need to stick with the vote - that slide deck shouldn't factor into it as-is.

@dlorenc There are a number of OpenSSF members in capital markets (GS, JPMC, Citi, etc), and a number of those organizations don't block access to google docs (Slack too, btw) due a variety of regulatory and other reasons. That's unlikely to change anytime soon. Would be great if important presentations like this were available through another channels such as download via GitHub. The continued insistence within LF communities to use google docs precludes organizations in highly regulated industries that can't use google docs from fully participation. CC @brianbehlendorf @mindthegab

I think Rob means don't allow access or do block access. I agree with Rob but a path that doesn't substantially increase the cost of collaboration requires work to define beyond the scope of this WG and should be raised at the TAC.
Brian
On March 9, 2023 4:34:33 AM GMT+01:00, Robert Underwood @.***> wrote:

@dlorenc There are a number of OpenSSF members in capital markets (GS, JPMC, Citi, etc), and a number of those organizations don't block access to google docs (Slack too, btw) due a variety of regulatory and other reasons. That's unlikely to change anytime soon. Would be great if important presentations like this were available through another channels such as download via GitHub. The continued insistence within LF communities to use google docs precludes organizations in highly regulated industries that can't use google docs from fully participation. CC @brianbehlendorf @mindthegab
--
Reply to this email directly or view it on GitHub:
https://github.com/ossf/wg-vulnerability-disclosures/issues/125#issuecomment-1461217525
You are receiving this because you were mentioned.
Message ID: @.***>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

I think Rob means don't allow access or do block access. I agree with Rob but a path that doesn't substantially increase the cost of collaboration requires work to define beyond the scope of this WG and should be raised at the TAC. Brian
On March 9, 2023 4:34:33 AM GMT+01:00, Robert Underwood @.> wrote: @dlorenc There are a number of OpenSSF members in capital markets (GS, JPMC, Citi, etc), and a number of those organizations don't block access to google docs (Slack too, btw) due to a variety of regulatory and other reasons. That's unlikely to change anytime soon. Would be great if important presentations like this were available through another channels such as download via GitHub. The continued insistence within LF communities to use google docs (and Slack) precludes organizations in highly regulated industries that can't use google docs from fully participating. CC @brianbehlendorf @mindthegab -- Reply to this email directly or view it on GitHub: #125 (comment) You are receiving this because you were mentioned. Message ID: @.>
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Yup. Edited my comment above. Apologies for the typo. Thank you @brianbehlendorf.
If y'all truly want banks at the table, along with their membership fees, this reality needs to be accounted for. In light of events such as the WhatApp fines to banks (google that if you're not familiar) this state of affairs is unlikely to change any time soon. Please don't assume all OpenSSF members can access Google docs. If you want to hold a vote, and want input from the community, level the playing field so everyone has the same access to all information. This issue has been raised many times, over many years, by the financial services participants in the LF. This is not new. Just PDF stuff and put it in a GitHub repo if you have to.

Thanks Rob. I'll follow up on this in another forum, to return this topic to OpenVEX as a project within the OpenSSF.

@dlorenc The only two slides in that deck of substance - 13 and 14 - both have multuple statements each that are flat-out wrong. I agree we need to stick with the vote - that slide deck shouldn't factor into it as-is.

Jason - I've given you comment access to the document. I'd like to fix anything incorrect, please feel free to leave a comment there if anything seems wrong.

@dlorenc There are a number of OpenSSF members in capital markets (GS, JPMC, Citi, MS, etc), and a number of those organizations block access to google docs (Slack too, btw) due to a variety of regulatory and other reasons. That's unlikely to change anytime soon. Would be great if important presentations like this were available through another channel such as download via GitHub. The continued insistence within LF communities to use google docs (and Slack) precludes organizations in highly regulated industries that can't use google docs from fully participating. CC @brianbehlendorf @mindthegab

Thanks for calling this out! I've converted it into a PDF and attached it here.
OpenVEX.pdf

+1 we need solutions in this space designed with the needs of open source projects as first class citizens. While there are pre-existing solutions, IMHO they have hit local optimums and have not achieved broadscale adoption, especially for open source projects. OpenVEX is very nascent but has already achieved traction e.g a new Rust implementation for OpenVEX documents openvex-rs

+1 for openVEX adoption into the OpenSSF

++1 on this proposal.

+1 for OpenVEX adoption.

I don't really care if OpenSSF brings OpenVEX in or not, but I know carpetbagging when I see it.

+1 this fits nicely in workflows I'm building and cleanly separates the static SBOM content from the dynamic VEX reports.

No from me.

+1 on the adoption of openVEX to the OSSF. its a step forward to VEX adoption by the community.

+1 (voting member)
My rational is that this is a nice, minimalistic way to offer VEX statements which will be (already is) easy to adopt for OSS maintainers, and the VulnWG can help promote this as part of their Mission.
While other broader efforts like CycloneDX, SPDX and CSAF do include full or partial VEX statement supports, a dedicated solution here will be more interesting to smaller projects and developers. We are focused on helping the OSS communities, and if OpenVEX can help raise the general security bar w.r.t. vuln scanning, I think it makes sense to have the project live under the VulnWG.
I understand some folks are upset about the splitting of the standards, the "why create a new solution; it'll confuse folks" and that OpenVEX folks should have just reached out to CycloneDX and SPDX and CSAF to broaden the whole thing. Regarding the CISA VEX publiction, we had Art Manion, lead author on it, discuss this during the Feb22 VulnWG meeting. We agree with him.
On collaboration and integration, the OSV project's various ecosystems adoption as mentioned by Oliven, lead of the OSV project in the APAC meeting a few weeks ago also coincide with a joint effort more than a splitting here. OpenVEX is not perpendicular to that effort; we see a good collaboration potential under the same roof. Here is OSV's opinion on OpenVEX as well.
This project would be a good fit in the OpenSSF's vulnerability working group.

This segment from Art's video says it all: https://youtu.be/oZO3rg9mL1w?t=1098

@rjb4standards
"There is no voting procedure, there is no official rules ... we're sorta of making it up as we go" is not going to be comforting for CISO orgs in investment banks to hear, as I'd imagine in many other industries, especially highly regulated ones, working on software supply chain security.
Isn't creating and enforcing proper governance a primary intended use of membership dollars? I know there has been a lot of hard work done on just this - governance - by the LF teams, including in and/or around the community specification standard. @mindthegab, @copiesofcopies, and I, among others, invested many months working on governance for FINOS, which is now in the LF, circa 2018, including and especially around voting procedures, and my impression of the wider LF was that governance was something that is pretty buttoned up.
Surely this effort can't really be a case "making it up as (they) go", particularly given how critical and high profile (even the White House is involved) this effort is.

@u269c Who's "we" in your comment? (This is a genuine question - I realize that this thread is a bit hot and people are getting a bit testy unfortunately.)
Thanks.

"There is no voting procedure, there is no official rules ... we're sorta of making it up as we go" is not going to be comforting for CISO orgs in investment banks to hear, as I'd imagine in many other industries, especially highly regulated ones, working on software supply chain security.
Isn't creating and enforcing proper governance a primary intended use of membership dollars? I know there has been a lot of hard work done on just this - governance - by the LF teams, including in and/or around the community specification standard. @mindthegab, @copiesofcopies, and I, among others, invested many months working on governance for FINOS, which is now in the LF, circa 2018, including and especially around voting procedures, and my impression of the wider LF was that governance was something that is pretty buttoned up.
Surely this effort can't really be a case "making it up as (they) go", particularly given how critical and high profile (even the White House is involved) this effort is.

Please note that @zmanion's comments here referred to the CISA SBOM WG that produced the "Minimum Requirements for VEX" document that will be published soon. That group is not affiliated with the LF or OSSF. The OpenVEX project uses the Community Specification process for decision-making.

@dlorenc "Hey lets go create a standard", is not how standards get developed in any of the standards bodies I've work in since 1992, including the IETF, Supply Chain Integrity, Transparency and Trust (SCITT) work group, which I'm currently working on.

(Voting member)
Three questions:

Is what's being proposed to join as an OpenSSF project just the specification (under openvex/spec), the all the repos in the OpenVEX GitHub org?

What project stage does this want to join at?

How has the OpenVEX project engaged with the Cyclone and SPDX projects to date?

Is what's being proposed to join as an OpenSSF project just the specification (under openvex/spec), the all the repos in the OpenVEX GitHub org?

All the repos.

What project stage does this want to join at?

Sandbox would be fine.

3. How has the OpenVEX project engaged with the Cyclone and SPDX projects to date?

I'm not sure how to answer this authoritatively, but there has been no official "project-to-project" collaboration, although many of the contributors to OpenVEX are also involved in those other projects. The specification was designed to be SBOM-agnostic, and work with both (and any other) SBOM formats: https://github.com/openvex/spec#sbom-agnostic

I vote yes! +1 for me.

@camaleon2016 Is this Microsoft's official position on OpenVEX?

@rjb4standards - please take this discussion elsewhere. It's off topic and inappropriate for this forum.

@dlorenc no problem Dan.  I only invest my time in projects that stand a chance of succeeding, so it's appropriate, and proper for me to depart this discussion.

Folks a reminder to abide by the https://www.linuxfoundation.org/legal/antitrust-policy and refrain from trying to discuss business plans or strategy.

After watching the video; I'm totally confused on where Microsoft stands on VEX/OpenVEX, especially where the OMB M-22-18 requirements refer to NIST Guidance as requirements for software supply chain risk management. NIST's SP 800-161 defines the data that should be communicated to consumers as an attestation showing that software suppliers have checked each SBOM component for vulnerabilities. That artifact is called a Vulnerability Disclosure Report

@rjb4standards  I'd be happy to discuss Microsoft's position offline. But as an FYI, I helped write the issue to vote on OpenVEX's adoption. And to be clear, we are only voting on it's adoption within the OpenSSF and to be further developed and worked on within the VD WG. Any additional discussions should take place aside from this issue. Or, perhaps an additional issue can be raised at a later time to address your concerns.

@annabellegoth2boss The SPDX and CycloneDX camps occasionally collaborate, and in fact we had a meeting yesterday to discuss interop. But I can confirm that no collaboration has happened between OpenVEX and CycloneDX.

@camaleon2016 Is this Microsoft's official position on OpenVEX?

@rjb4standards - Please stop this behaviour.  Each member is entitled to their opinions and should vote based off of whatever factors they desire to weigh (including corporate or community goals, missions, desires).  None of these opinions are considered an "official position" unless that member states so.  If you seek a corporate position, you should approach those individual organizations for such.  I also would invite you, since you appear to have deep interest in these topics, to more frequently engage with our group as part of our meetings, mailing lists, and other outlets to participate and you can share your insights with our community.

Folks a reminder to abide by the https://www.linuxfoundation.org/legal/antitrust-policy and refrain from trying to discuss business plans or strategy.

Also our Code of Conduct and be respectful to each other: https://openssf.org/community/code-of-conduct/

I respectfully request to be removed from this group.

But I can confirm that no collaboration has happened between OpenVEX and CycloneDX.

To be clear, OpenVEX has not collaborated with any SBOM project, as the purpose was to build a light weight microstandard that is used for vulnerability disclosure.  The use case is not specific to SBOMs, but has applications which are complementary.

"While there are pre-existing solutions, IMHO they have hit local optimums and have not achieved broadscale adoption, especially for open source projects. "

Again this is incorrect information. The CycloneDX VEX and VDR have been adopted by both open source and commercial reputed security tools and vendors.
OpenSource Projects:
Anchore grype
Apache Solr
CVE Bin tool
Aqua Trivy
AppThreat/dep-scan
Lockheed Martin Hoppr Cop
OWASP DependencyTrack
Vexy
etc.
Commercial vendors:
Anchore,
AquaSecurity,
Contrast Security,
Checkmarx,
debricked,
IBM,
NowSecure,
PaloAltoNetworks,
QWIET AI
Rezilion,
Sonatype,
StackAware,
Veracode,
etc.

I respectfully request to be removed from this group.

I am currently working with the OpenSSF staff to accommodate your request.

(Voting member) I like the idea of VEX, but I see the issues that @stevespringett raised in his blog post on the topic. Keeping a full list of negative assertions of all the vulnerabilities you aren't impacted by is untenable for the industry. I like the closing line of his article:

NIST guidance recommends that vendors issue VDRs as a regular practice, thus asserting what vulnerabilities a product is potentially affected by. NIST guidance also allows for the inclusion of VEX and similar notification strategies.
Could it be that a hybrid approach of supporting both VDR and VEX is the way forward? In the end, hopefully, pragmatism will be the clear winner.

I'd like to hear from Allan Friedman before casting my vote, (I've pinged him), but, after reviewing the comments above, and the links provided, I'm leaning towards supporting this.
I respect that CycloneDX has a specification for defining a VEX format. That can be seen here:
https://cyclonedx.org/docs/1.4/json/#vulnerabilities_items_analysis_state
If you want an example: https://cyclonedx.org/use-cases/#vulnerability-exploitability
However, this implementation couples the VEX information to the CycloneDX SBOM format. I don't know if that's a good/bad thing. However, I think that being able to ship both VDR and VEX assertions independently from an SBOM seems to make sense. Especially because, while an SBOM for a given release of a product will, hopefully, never change (because dependencies are, ideally, fixed at release time), the VDR and VEX assertions can vary over time as new vulnerabilities are announced.

I respectfully request to be removed from this group.

You can also 'unsubscribe' yourself from this issue on the right sidebar. And if you are following this repository, you can unwatch this repository in the top right corner. Hope this helps. 😃

@JLLeitschuh thanks for the advice. I have unsubcribed. Much appreciate your assistance.

(Voting member)
I am a "no" at this stage based on the OpenSSF's project criteria for maintainer/contributor diversification. While OpenVEX has a list of maintainers with different affiliations, the commit pool and history doesn't show the kind of diversified contribution the OpenSSF's criteria was going for.
I think the questions about OpenSSF's role in standards, collaboration with other formats, etc., are all worthwhile discussions, but should be revisited when OpenVEX is a bit more mature and shows multi-party participation.

@puerco SPDX V2.3 already contains support for VEX and VDR: SPDX V 2.3 Appendix K

Those are references to external documents, I'm referring to the actual vex data expressed in SPDX. It is a planned feature for the security profile.

@puerco

capturing that consensus in a minimal format.

You do realize that many of the original people involved with VEX have left the group because consensus was never going to be achieved.
INFORM @JLLeitschuh

However, this implementation couples the VEX information to the CycloneDX SBOM format. I don't know if that's a good/bad thing

Its actually a good thing. CDX VEX is completely decoupled from an SBOM, and in fact, does not require an SBOM at all. Many of the CISA examples for CDX do not have SBOMs, nor does the Apache Solr VEX that someone else posted in this thread. Having both VEX and SBOM capabilities in the same specification does not mean they have to be present in the same document. CycloneDX recommends against this practice. But having both capabilities in the same specification dramatically simplifies the toolchain and reduces overall cost associated with supporting both SBOM and VEX. I'll assume that SPDX (once they support it) will have similar benefits. CDX VEX can already be used with and without SBOM, including SPDX SBOM. From my understanding, SPDX will have the same capability when complete.
On the flip side, having VEX capabilities in an advisory format such as CSAF would also simplify the toolchain and reduce costs. Vendors such as RedHat and Oracle are doing that today.

Also, keep in mind that VEX is only half of the solution. The other half is VDR which is already a requirement in some federal and commercial instances.

This dynamic of VEX == "not affected" / VDR == "affected" is inaccurate. One of the VEX status values is "affected."
I could imagine a VDR containing one or more VEX statements (presumably with status == affected).
VDR is very weakly defined by NIST. My read is that a typical security advisory, or a collection of advisories, meets the existing "specification" for a VDR. Seems reasonable to work on a more precise definition of VDR, but at least for now, that would be defined by the VDR implementation, and not NIST. Also, beyond general "follow NIST" guidance, it's not clear to me that anyone is actually required to produce a VDR. Even SP 800-161 RA-5 reads "should" and "may consider providing." Limiting VDR to only "affected" is a significant loss of signal.

@zmanion IF VEX can contain affected products, will VEX eliminate the need for CSAF Security Advisories, which are used extensively to communicate when products are affected?
Also, Allan Friedman' presentation, in this youtube video state clearly that VEX is a "negative security advisory" (around 12:50).

+1 I support this initiative

I think @annabellegoth2boss is taking the right approach to this. It's definitely worth trying to be systematic and leave aside emotions and purely subjective opinions. We do have a process so it's good to lean on it.
@dlorenc you referred earlier to "many of the contributors to OpenVEX" but browsing through all the openvex repos I only see about 10 contributors. Are there more?
Thanks.

@dlorenc you referred earlier to "many of the contributors to OpenVEX" but browsing through all the openvex repos I only see about 10 contributors. Are there more?

That number sounds about right for contributors.  It's a rather minimal specification though, so I don't expect hundreds more. As more language libraries come on board things could vary, but we're seeing that happen outside of the organization too, which is great: https://github.com/seedwing-io/openvex-rs

I understand. Thanks.

VEX is basically a... "VBOM", right? It tracks the life-span of a vulnerability, the document is updated and maintained as more details, mitigations, and remediation, until - I assume - "the vulnerability is no more"?
Please correct me, if I am wrong.

I'm afraid not, Henk. The best published document that describes VEX can be downloaded from CISA's site herehttps://www.cisa.gov/sites/default/files/publications/VEX_Use_Cases_Aprill2022.pdf, although there's a very good documenthttps://docs.google.com/document/d/10n3LA1wfD8MBwC-Od5INhd2OBStuW_dXmMoDiWL2rX4/edit# drafted by Allan Friedman in 2021, which was unfortunately never published. I also want to point out that some of the people involved in the VEX effort (including me) have come to believe that VEX should really be an API, not a document that's distributed, for many reasons.
Tom Alrich LLC
312-515-8996

From: Henk Birkholz @.>
Sent: Thursday, March 9, 2023 2:20 PM
To: ossf/wg-vulnerability-disclosures @.>
Cc: Tom Alrich @.>; Comment @.>
Subject: Re: [ossf/wg-vulnerability-disclosures] VOTE - Adopt OpenVEX as project within the OpenSSF under Vuln Disclosure Working Group (WG) (Issue #125)
VEX is basically a... "VBOM", right? It tracks the life-span of a vulnerability, the document is updated and maintained as more details, mitigations, and remediation, until - I assume - "the vulnerability is no more"?
Please correct me, if I am wrong.
—
Reply to this email directly, view it on GitHubhttps://github.com/ossf/wg-vulnerability-disclosures/issues/125#issuecomment-1462713445, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVCDY67NSU7JBCOXZKXMK6TW3I3PXANCNFSM6AAAAAAVUEWJZU.
You are receiving this because you commented.Message ID: @.***>

@tomalrich, could you help me out here a bit and highlight a section in https://docs.google.com/document/d/10n3LA1wfD8MBwC-Od5INhd2OBStuW_dXmMoDiWL2rX4/edit# that would contradict my...I'd say rather terse and simplified assertion?

Sure, @henkbirkholz. The whole first section ("Abstract") is good, but this paragraph is the closest thing to a definition of VEX that I've seen. Again, I'll point out that some of us have changed our ideas about VEX.
The goal of Vulnerability Exploitability eXchange (VEX) is to allow a software supplier or other party to assert the status of specific vulnerabilities in a particular product. This class of security advisory will be of particular help in efficiently managing SBOM data for vulnerability management, by allowing both suppliers and users to focus on vulnerabilities that pose the most immediate risk, while not investing time in searching for or patching vulnerabilities that are not exploitable and therefore have no impact.
Tom
Tom Alrich LLC
312-515-8996

From: Henk Birkholz @.>
Sent: Thursday, March 9, 2023 2:40 PM
To: ossf/wg-vulnerability-disclosures @.>
Cc: Tom Alrich @.>; Mention @.>
Subject: Re: [ossf/wg-vulnerability-disclosures] VOTE - Adopt OpenVEX as project within the OpenSSF under Vuln Disclosure Working Group (WG) (Issue #125)
@Tomalrichhttps://github.com/Tomalrich, could you help me out here a bit and highlight a section in https://docs.google.com/document/d/10n3LA1wfD8MBwC-Od5INhd2OBStuW_dXmMoDiWL2rX4/edit# that would contradict my...I'd say rather terse and simplified assertion?
—
Reply to this email directly, view it on GitHubhttps://github.com/ossf/wg-vulnerability-disclosures/issues/125#issuecomment-1462761519, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVCDY6ZL7X6DMOPQNPPOAQDW3I55VANCNFSM6AAAAAAVUEWJZU.
You are receiving this because you were mentioned.Message ID: @.***>

@dlorenc @lehors in looking a little closer at the contribution stats for the two code projects (vexctl and go-vex), it appears the majority of contributions to both came from one developer. According to GitHub, one of the maintainers' only contribution to those projects has been to add himself to the CONTRIBUTORS.md file, and two of the maintainers have never contributed code to either project.
Following up on others' procedural comments, I would like to better understand how this project meets the multiplicity of maintainers required for admission into the OpenSSF. Are there other artefacts demonstrating the community engagement which the TAC ought to review?

@dlorenc @lehors in looking a little closer at the contribution stats for the two code projects (vexctl and go-vex), it appears the majority of contributions to both came from one developer. According to GitHub, one of the maintainers' only contribution to those projects has been to add himself to the CONTRIBUTORS.md file, and two of the maintainers have never contributed code to either project.
Following up on others' procedural comments, I would like to better understand how this project meets the multiplicity of maintainers required for admission into the OpenSSF. Are there other artefacts demonstrating the community engagement which ought to be reviewed?

This is incorrect, Google and VMware are officially supporting OpenVEX and the have contributed to this PR - https://github.com/openvex/community/pull/6

Before I vote one way or the other.  I need to ask.  Does an acceptance vote to move this under the governance of the OpenSSF at a technical level and the release of IP rights?
I don't profess to be an expert in where the state of the art is here, but I do know that most of the linux distros are based on some previous with cherry-picked solutions to some CVE.  This declaration can be represented in the SBOM and thus ties into the language of VEX\VDR or the final replacement.  Having that clarified and worked through is important.
I do know that SBOM's support two serialization formats, but this does come at a complexity cost of walking the graph.  If we could strive to not repeat this in this space great.  I am not sure that OpenVEX though will trump any move from CISA or influence from other governments going forward.
If the desire is to push far enough into the vanguard space with tooling and thus own mindshare, I should point out that we have remnants of that approach over broad areas from S\MIME to ...  Undoing or supporting the quirks should be a non-goal.

Before I vote one way or the other. I need to ask. Does an acceptance vote to move this under the governance of the OpenSSF at a technical level and the release of IP rights?

Yes - that's the main intention here.

Before I vote one way or the other. I need to ask. Does an acceptance vote to move this under the governance of the OpenSSF at a technical level and the release of IP rights?
I don't profess to be an expert in where the state of the art is here, but I do know that most of the linux distros are based on some previous with cherry-picked solutions to some CVE. This declaration can be represented in the SBOM and thus ties into the language of VEX\VDR or the final replacement. Having that clarified and worked through is important.
I do know that SBOM's support two serialization formats, but this does come at a complexity cost of walking the graph. If we could strive to not repeat this in this space great. I am not sure that OpenVEX though will trump any move from CISA or influence from other governments going forward.
If the desire is to push far enough into the vanguard space with tooling and thus own mindshare, I should point out that we have remnants of that approach over broad areas from S\MIME to ... Undoing or supporting the quirks should be a non-goal.

@roywill I believe, procedurally, if this project is adopted, next steps are to go through LF legal review and the IP transfer. Can anyone from the TAC confirm this or provide perspective on these steps?

Sure, @henkbirkholz. The whole first section ("Abstract") is good, but this paragraph is the closest thing to a definition of VEX that I've seen. Again, I'll point out that some of us have changed our ideas about VEX. The goal of Vulnerability Exploitability eXchange (VEX) is to allow a software supplier or other party to assert the status of specific vulnerabilities in a particular product. This class of security advisory will be of particular help in efficiently managing SBOM data for vulnerability management, by allowing both suppliers and users to focus on vulnerabilities that pose the most immediate risk, while not investing time in searching for or patching vulnerabilities that are not exploitable and therefore have no impact. Tom Tom Alrich LLC<PHONE_NUMBER>
…
________________________________ From: Henk Birkholz @.> Sent: Thursday, March 9, 2023 2:40 PM To: ossf/wg-vulnerability-disclosures @.> Cc: Tom Alrich @.>; Mention @.> Subject: Re: [ossf/wg-vulnerability-disclosures] VOTE - Adopt OpenVEX as project within the OpenSSF under Vuln Disclosure Working Group (WG) (Issue #125) @Tomalrichhttps://github.com/Tomalrich, could you help me out here a bit and highlight a section in https://docs.google.com/document/d/10n3LA1wfD8MBwC-Od5INhd2OBStuW_dXmMoDiWL2rX4/edit# that would contradict my...I'd say rather terse and simplified assertion? — Reply to this email directly, view it on GitHub<#125 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVCDY6ZL7X6DMOPQNPPOAQDW3I55VANCNFSM6AAAAAAVUEWJZU. You are receiving this because you were mentioned.Message ID: @.***>

@Tomalrich, (I hope this is not too off-topic for an issue with a vote label). How is your highlighted description not documentations created and maintained by several parties wrt certain vulnerabilities effecting certain products that are amended or augmented over time until the vulnerabilities are believably fixed (i.e., that all VEX documents about the vulnerability / product composites can state a "not affected" justification)? I might be missing something obvious here, but I still cannot see a contradiction to my test assertion above. What am I missing?

identifying non-exploitable vulnerabilities identified for components listed in an SBOM for a particular version of a product

Does that actually exclude exploitable vulnerabilities? I am not entirely sure, what OpenVEX is, if:

I cannot really tell what VEX is, or
I cannot really tell if OpenVEX actually is VEX or a superset (or a subset) of VEX.

(if anyone would rather we take this discussion offline, please let me know)
VEX is basically a... "VBOM", right? It tracks the life-span of a vulnerability, the document is updated and maintained as more details, mitigations, and remediation, until - I assume - "the vulnerability is no more"?
@henkbirkholz, I think the biggest difference between the passage by Allan Friedman that I quoted and what you're saying above is that Allan is articulating VEX as the VEX working group has been thinking of it since 2020 (although, again unfortunately, we have published very little to document what we've been thinking) - i.e. VEX is a description of the product, not the vulnerability.
In other words, VEX (or VDR, for that matter) statements say, "Product ABC is/is not affected by vulnerability CVE-2023-12345", where this CVE is typically one that applies to a component in the product, revealed in a recent SBOM. Thus, the question VEX answers is, "Given that component XYZ is vulnerable to CVE-2023-12345 (as shown in the NVD or another vulnerability database), does it follow that Product ABC is also vulnerable?" I believe your statement is about the vulnerability itself, regardless of the individual products that may or may not harbor this vulnerability.
Tom Alrich LLC
312-515-8996

From: Henk Birkholz @.>
Sent: Thursday, March 9, 2023 3:25 PM
To: ossf/wg-vulnerability-disclosures @.>
Cc: Tom Alrich @.>; Mention @.>
Subject: Re: [ossf/wg-vulnerability-disclosures] VOTE - Adopt OpenVEX as project within the OpenSSF under Vuln Disclosure Working Group (WG) (Issue #125)
Sure, @henkbirkholzhttps://github.com/henkbirkholz. The whole first section ("Abstract") is good, but this paragraph is the closest thing to a definition of VEX that I've seen. Again, I'll point out that some of us have changed our ideas about VEX. The goal of Vulnerability Exploitability eXchange (VEX) is to allow a software supplier or other party to assert the status of specific vulnerabilities in a particular product. This class of security advisory will be of particular help in efficiently managing SBOM data for vulnerability management, by allowing both suppliers and users to focus on vulnerabilities that pose the most immediate risk, while not investing time in searching for or patching vulnerabilities that are not exploitable and therefore have no impact. Tom Tom Alrich LLC<PHONE_NUMBER>
…
________________________________ From: Henk Birkholz @.> Sent: Thursday, March 9, 2023 2:40 PM To: ossf/wg-vulnerability-disclosures @.> Cc: Tom Alrich @.>; Mention @.> Subject: Re: [ossf/wg-vulnerability-disclosures] VOTE - Adopt OpenVEX as project within the OpenSSF under Vuln Disclosure Working Group (WG) (Issue #125https://github.com/ossf/wg-vulnerability-disclosures/issues/125) @Tomalrichhttps://github.com/Tomalrichhttps://github.com/Tomalrich, could you help me out here a bit and highlight a section in https://docs.google.com/document/d/10n3LA1wfD8MBwC-Od5INhd2OBStuW_dXmMoDiWL2rX4/edit# that would contradict my...I'd say rather terse and simplified assertion? — Reply to this email directly, view it on GitHub<#125 (comment)https://github.com/ossf/wg-vulnerability-disclosures/issues/125#issuecomment-1462761519>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVCDY6ZL7X6DMOPQNPPOAQDW3I55VANCNFSM6AAAAAAVUEWJZU. You are receiving this because you were mentioned.Message ID: @.***>
@Tomalrichhttps://github.com/Tomalrich, (I hope this is not too off-topic for an issue with a vote label). How is your highlighted description not documentations created and maintained by several parties wrt certain vulnerabilities effecting certain products that are amended or augmented over time until the vulnerabilities are believably fixed (i.e., that all VEX documents about the vulnerability / product composites can state a "not affected" justification)? I might be missing something obvious here, but I still cannot see a contradiction to my test assertion above. What am I missing?
—
Reply to this email directly, view it on GitHubhttps://github.com/ossf/wg-vulnerability-disclosures/issues/125#issuecomment-1462844760, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVCDY62WC2D24ABVGGBO2VLW3JDDHANCNFSM6AAAAAAVUEWJZU.
You are receiving this because you were mentioned.Message ID: @.***>

Tom,
That's description of VDR is not accurate. A VDR is an attestation by a software vendor showing that each component of a product SBOM has been checked for vulnerabilities, and any components with vulnerabilities must be addressed by the software suipplier. Some vulnerabilities may be false positives, some may relate to earlier versions of components and are also false positives. Any real exploitable vulnerabilities need to be flagged and resolved before product release. After product release, and newly reported vulnerabilities also need to be addressed in the "online living" VDR document maintained by the software supplier. An example VDR is provided here a CycloneDX VDR example is provided here

@henkbirkholz, I realize I didn't address your question, "I cannot really tell if OpenVEX actually is VEX or a superset (or a subset) of VEX."
I regard OpenVEX as neither one of those options. OpenVEX addresses a different use case altogether from what VEX (as conceived by the VEX working group under the NTIA and CISA initiatives) does. The purpose of OpenVEX is to identify vulnerability scan results that are false positives. The purpose of VEX is to identify component vulnerabilities that aren't exploitable in the product itself (which is a different type of false positive, of course).
I think OpenVEX is a good use case, and I'm sure it addresses the need for which it was developed. But it has nothing to do with SBOM or VEX, as those ideas have been developed (although not well documented, to be sure!) by the NTIA and CISA initiatives. I don't have a trademark on "VEX", so if OpenVEX wants to use that acronym, that's fine with me. But it's important to keep in mind that it's a very different use case, so it shouldn't be compared with the two existing VEX formats (both of which have a large number of maintainers), CSAF VEX and CycloneDX VEX.
I discussed this issue in more detail in thishttps://tomalrichblog.blogspot.com/2023/02/vexual-confusion-reigns.html blog post.
Tom Alrich LLC
312-515-8996

From: Henk Birkholz @.>
Sent: Thursday, March 9, 2023 3:32 PM
To: ossf/wg-vulnerability-disclosures @.>
Cc: Tom Alrich @.>; Mention @.>
Subject: Re: [ossf/wg-vulnerability-disclosures] VOTE - Adopt OpenVEX as project within the OpenSSF under Vuln Disclosure Working Group (WG) (Issue #125)
identifying non-exploitable vulnerabilities identified for components listed in an SBOM for a particular version of a product
Does that actually exclude exploitable vulnerabilities? I am not entirely sure, what OpenVEX is, if:

I cannot really tell what VEX is, or
I cannot really tell if OpenVEX actually is VEX or a superset (or a subset) of VEX.

—
Reply to this email directly, view it on GitHubhttps://github.com/ossf/wg-vulnerability-disclosures/issues/125#issuecomment-1462853014, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVCDY64SDYTXKHAPFHSPZWDW3JD6XANCNFSM6AAAAAAVUEWJZU.
You are receiving this because you were mentioned.Message ID: @.***>

(Voting Member) +1
After quite a bit of discussion today with various parties, and reviewing the links above, I'm onboard with adopting OpenVEX under this working group.

(Voting Member) +1
After quite a bit of discussion today with various parties, and reviewing the links above, I'm onboard with adopting OpenVEX under this working group.

Thank you for taking the time to do the diligence and for expressing your opinion!

@roywill I believe, procedurally, if this project is adopted, next steps are to go through LF legal review and the IP transfer. Can anyone from the TAC confirm this or provide perspective on these steps?

Putting my TAC hat on, that matches my understanding.
With my OpenVEX hat on, we've strived to make this legal and IP process smooth from the start so we don't anticipate any issues.

Re process, the next step would be a Sandbox Application and a PR for the TAC vote (Sandbox entry process).

Re process, the next step would be a Sandbox Application and a PR for the TAC vote (Sandbox entry process).

I'm not sure this is correct. As per the last TAC meeting, the TAC is not required for WGs to accept projects like this.
See this PR from @david-a-wheeler which attempts to clarify this: https://github.com/ossf/tac/pull/142

Re process, the next step would be a Sandbox Application and a PR for the TAC vote (Sandbox entry process).

I'm not sure this is correct. As per the last TAC meeting, the TAC is not required for WGs to accept projects like this.
See this PR from @david-a-wheeler which attempts to clarify this: ossf/tac#142

In the last TAC meeting, I believe we noted that this procedure needs to be clarified. Uncertain whether the TAC needed to vote on a project joining under a WG, we none the less held a vote and had 6 YES 1 ABSTAIN to approve that project (I was the lone abstention).

@Tomalrich @henkbirkholz @roywill @JLLeitschuh &others -- I think the discussion you are having ("what is OpenVEX and what is its relationship to VEX, VDR, etc?") is an important discussion, and it's important that the WG and TAC have a shared understanding of the project maintainers' vision for the project.
I suggest taking that discussion offline (either to slack or email or to the next WG meeting) for high-bandwidth resolution and then updating the OpenVEX project documentation to clarify that distinction in a manner that is understandable by folks who have not been deeply involved in the VEX working group for the past two+ years.
I believe that will help move us towards an easier voting decision.

@dlorenc @lehors in looking a little closer at the contribution stats for the two code projects (vexctl and go-vex), it appears the majority of contributions to both came from one developer. According to GitHub, one of the maintainers' only contribution to those projects has been to add himself to the CONTRIBUTORS.md file, and two of the maintainers have never contributed code to either project.
Following up on others' procedural comments, I would like to better understand how this project meets the multiplicity of maintainers required for admission into the OpenSSF. Are there other artefacts demonstrating the community engagement which ought to be reviewed?

This is incorrect, Google and VMware are "officially supporting" OpenVEX and the have "contributed" to this PR - openvex/community#6

@costica11 - the PR you linked is merely a change to the MAINTAINERS.md file, not a substantive contribution to the project. Is there somewhere else we should be looking?

@dlorenc "Hey lets go create a standard", is not how standards get developed in any of the standards bodies I've work in since 1992, including the IETF, Supply Chain Integrity, Transparency and Trust (SCITT) work group, which I'm currently working on.

I do not agree. IETF is open to work on a document if there's enough energy in a group wanting to take on the work. In some cases this has resulted in overlapping IETF RFCs which is just fine.

I suggest taking that discussion offline (either to slack or email or to the next WG meeting) for high-bandwidth resolution and then updating the OpenVEX project documentation to clarify that distinction in a manner that is understandable by folks who have not been deeply involved in the VEX working group for the past two+ years.

@AevaOnline, thanks. If this discussion goes somewhere else, could someone please leave a pointer here? I am really bad at following bread crumbs - unless they are really bright and shiny :sparkle:

Just addressing one last piece of misinformation:

The purpose of OpenVEX is to identify vulnerability scan results that are false positives.

This is one application of OpenVEX.  It is not the only application.  The purpose of OpenVEX is to leverage presently existing microstandards such as PUrl to enable sharing of data relating to vulnerabilities in a framework that looks and feels like something aligned with the various draft documents produced by the VEX working group.
In reality, its functionality is a superset of the functionality discussed by the VEX working group, so it can "turn off" scan results (by saying a component is fixed, or not affected, or whatever), but it can also say "we fixed this component by doing XYZ" etc.
And being a microstandard itself (indeed, OpenVEX is only a JSON-LD vocabulary), it can also be trivially extended by other microstandards to provide even more functionality.
Ultimately the purpose of OpenVEX isn't so much "turning off scan results" as it is enabling FOSS maintainers and security teams to collaborate on vulnerability management.  The vision is one of an ecosystem backed by rich vulnerability data presented as linked data, with OpenVEX attestations being a description of how a vulnerability is mutated (e.g. confirmed, fixed, acknowledged or whatever else we want to say about the vulnerability).  If you can imagine, for a second, an SBOM which references an OSV advisory, which then references some OpenVEX attestations, we want to enable tooling which can present all of that information in a concise and tactically useful way.

OpenVEX is only a JSON-LD vocabulary

You are basically saying OpenVEX is an ontology T-Box. If that is case, OpenVex would be more aligned with SPDX that I initially realized. Maybe W3C would be a good candidate venue to move from individual specification to standards text? To be honest, I am a little bit surprised, as I cannot see any linked data in https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md. Is that a planned next step? (and sorry for not keeping it offline. At the moment, the shiny bread crumbs lead here).

At the moment, we have indeed not shown any examples of how the linked data aspects will work.  That work is forthcoming.  But it has always been the goal since OpenVEX was conceptualized last year.

Before I vote one way or the other. I need to ask. Does an acceptance vote to move this under the governance of the OpenSSF at a technical level and the release of IP rights?
I don't profess to be an expert in where the state of the art is here, but I do know that most of the linux distros are based on some previous with cherry-picked solutions to some CVE. This declaration can be represented in the SBOM and thus ties into the language of VEX\VDR or the final replacement. Having that clarified and worked through is important.
I do know that SBOM's support two serialization formats, but this does come at a complexity cost of walking the graph. If we could strive to not repeat this in this space great. I am not sure that OpenVEX though will trump any move from CISA or influence from other governments going forward.
If the desire is to push far enough into the vanguard space with tooling and thus own mindshare, I should point out that we have remnants of that approach over broad areas from S\MIME to ... Undoing or supporting the quirks should be a non-goal.

@roywill I believe, procedurally, if this project is adopted, next steps are to go through LF legal review and the IP transfer. Can anyone from the TAC confirm this or provide perspective on these steps?

yes, LF Legal review and IP transfer would be next steps if this is adopted by the WG.

Fam - can we please keep this discussion professional, respectful, and focused on the merits/detriments of adopting the OpenVEX body of work and efforts?  It is very exciting that we've generated so much external interest, and I hope many of you that are joining us for the first time for this dialog stick around and continue to contribute to our ongoing efforts within the open source vulnerability disclosure community, but the purpose of this issue is for our working group members to ask questions and ultimately express their desires around any future collaborations with the OpenVEX group.  It is easy to see the passion everyone is bringing here, and we'd like to find productive ways to harness that for the betterment of our ecosystem, maintainers, and downstream consumers.

@AevaOnline Apologies, I didn't mean to confuse you. I thought you might be already aware of all the mess related to this. From what I know, these people were contacted to be listed for namesake, for publicity and for a potential future OpenSSF submission. I am not sure if Google and VMware officially reviewed this project and gave their clearance. There was already a "closed" discussion with the L.F staff about all this. There was a coordinated PR with the OpenVEX announcement. I think that the project is abusing the power of media manipulation and access to the L.F. staff as well as the positions in OpenSSF.

All I'm going to say here is that this is completely false.

+1 as an Independent OpenSSF Contributor.

it is our intention that OpenVEX fits very well into SPDX, especially the upcoming SPDX 3

With respect to future collaborations, joining the SPDX Defects Profile Meeting might be a good path towards that goal.
I am bad at finding invites... As far as I can tell, the meeting occurs weekly: Wed, 14:00 CST (currently 20:00 CET), at https://meet.jit.si/SPDXDefectsMeeting

I'd LOVE to see folks from both SPDX and CycloneDX continue to engage with this group going forward.  Perhaps we could get some reps to come in and do a quick demonstration for our members and showcase how the tools both can help maintainers and consumers manage with risk around open source vulnerabilities and show how devs can leverage the great software and communities around both.

Can this discussion be documented and shared here? The GSD is keeping an eye on this issue as it affects us (the good news is we can probably support it, I think, but the bad news is I'm not exactly sure what "it" is), in other words I'm not entirely clear on what the intended purpose of OpenVEX is, e.g., what problem does it solve (technical? procedural? you want to make sure there's a reference open source implementation?) and have any other options have been considered (and found to be lacking?). Thanks.
I can say from experience that inventing a new data format has long-term effects, witness CVE v5 just finally becoming sane, the first four versions were not bad, but they weren't great, I didn't get any community feedback/project feedback so I went ahead with what I thought was best (and often times the only way to truly learn and explore a problem space is to build a solution, theory craft only gets you so far).
My only concrete ask is: please make a schema version (e.g. "schema_version": "1.0") a mandatory tag, and please consider making an identification tag (e.g. "data_type": "openvex") mandatory as well. This is hugely helpful when ingesting lots of data from lots of different sources, that may or may not label/mix and match their data.

If anyone really wants to continue the more off-topic aspects of this issue, I opened discussion https://github.com/ossf/wg-vulnerability-disclosures/discussions/127.

+1 as an OpenSSF VDWG member.

The recording from last week's presentation is now available on Youtube: https://www.youtube.com/watch?v=MBn1Ph6aBxc

@dlorenc "Hey lets go create a standard", is not how standards get developed in any of the standards bodies I've work in since 1992, including the IETF, Supply Chain Integrity, Transparency and Trust (SCITT) work group, which I'm currently working on.

I do not agree. IETF is open to work on a document if there's enough energy in a group wanting to take on the work. In some cases this has resulted in overlapping IETF RFCs which is just fine.
@oej , IETF has an entire process before a work group can be setup to work on a standard, this requires BOF's and a formal chartering process, before a work group is approved. It's definitely not a "rag tag" "ad hoc" thing, it's a well defined process that must be followed. That's my experience, yours may be different. I've worked in other ANSI SDO's and they all have similar requirements before standards development begins.

Absolutely. But that doesn't prevent competing proposals to get working groups. You have many standards for voice over the net, for presence and chat too.

@dlorenc The only two slides in that deck of substance - 13 and 14 - both have multuple statements each that are flat-out wrong. I agree we need to stick with the vote - that slide deck shouldn't factor into it as-is.

Jason - I've given you comment access to the document. I'd like to fix anything incorrect, please feel free to leave a comment there if anything seems wrong.

I was out on PTO last week, so am just getting to this now. I have added all of my comments on that deck. I won't repeat them here but encourage others to go read them. The TL;DR for me is that the claims in those two slides are not data-driven - they are subjective, and seem written with a very specific point of view in mind (commercial - the "we" statements are not referring to the WG or OSSF). If they are data-driven, then the data should be provided...

I have added all of my comments on that deck. I won't repeat them here but encourage others to go read them.

Just a heads-up that you can't see the comments added to the slides without having edit rights on the deck. Anyone casually following along to this issue can't see them.

Just a heads-up that you can't see the comments added to the slides without having edit rights on the deck. Anyone casually following along to this issue can't see them.

I've now opened up comment access. If it starts getting abused I'll have to drop it to a list specific to this WG or something. I don't see a way to allow viewing comments without adding them :(

I've now opened up comment access. If it starts getting abused I'll have to drop it to a list specific to this WG or something. I don't see a way to allow viewing comments without adding them :(

Thanks!

Just a heads-up that you can't see the comments added to the slides without having edit rights on the deck. Anyone casually following along to this issue can't see them.

I've now opened up comment access. If it starts getting abused I'll have to drop it to a list specific to this WG or something. I don't see a way to allow viewing comments without adding them :(

Understood. Thank you for the benefit of doubt. Maybe comment on inappropriate comments for a while before considering doing permission churn again. I think the gesture is duly appreciated. One question: what does "this WG" refer to?

One question: what does "this WG" refer to?

@henkbirkholz this discussion is occurring within a GitHub Issue within the Vulnerability Disclosure Working Group (WG). The URL for this Issue lists the WG name. This Issue opened a request for that WG to vote.
For more information on the OpenSSF's organizational structure and what Working Groups are in this context, please refer to the OSSF/TAC repository.

Understood. Thank you for the benefit of doubt. Maybe comment on inappropriate comments for a while before considering doing permission churn again. I think the gesture is duly appreciated. One question: what does "this WG" refer to?

Sorry folks, that didn't last long. I'm dropping permissions again to view only. Just click "request access" if you want to comment.

Projects must be aligned with the OpenSSF mission and either be a novel approach for existing areas or address an unfulfilled need.

Respectfully, OpenVEX doesn't pass this sniff test for OpenSSF project adoption.

+1 OpenVEX seems really useful for filtering CVEs.

I'm disappointed to have my team's motivations and by proxy the reputation of folks like rnjudge brought into this discussion.  At VMware our emphasis is in doing what we can to contribute to the open source evolution of both standards and interoperable tools/process implementations in the software supply chain security space.  Our initial involvement with this early OpenVEX project is directly aligned with both that and the track record visible with our involvement in areas like purl, OCI, SPDX, and even bringing CycloneDX support to tools we're interested in.  Our involvement is because we believe the future needs actively bridged to be one in which the ecosystem is performing trustworthy exchange of artifacts and metadata, composed and consumed by diverse tools via common, machine readable formats (yes plural).  It's unlikely that one solution will fit all sizes in this complex technical domain.  Whether this proposal moves forward now, later, or not at all, please expect VMware to be contributing in these spaces and hopefully then with more time our presence comes to surprise people less.

@tpepper  I've worked with Rose Judge on SPDX and her honesty and integrity is impeccable.

One question: what does "this WG" refer to?

@henkbirkholz this discussion is occurring within a GitHub Issue within the Vulnerability Disclosure Working Group (WG). The URL for this Issue lists the WG name. This Issue opened a request for that WG to vote.
For more information on the OpenSSF's organizational structure and what Working Groups are in this context, please refer to the OSSF/TAC repository.

@AevaOnline Thanks. I am finding my bearings now.

+1 for OpenVEX adoption. VEX is an important development in the world of vulnerability management and this WG being a part of the growth and improvements through OpenVEX is a targeted and valuable way to contribute.

+1
Work to do here but this is a great start / approach

I've hesitated to vote because like others I very much dislike the tone this discussion has taken but as it has been pointed out this proposal appear to fail the requirements set up by our process. On that basis I vote no.
If anything this should have helped Chainguard identify other interested parties and once they have beefed up a bit the community around this they should be in a better position to bring it here.
I would advise making an effort to better explain why this is needed. The main argument against using Vex seems to be that Vex is immature and lack adoption. I find that pretty unconvincing. I would prefer an approach that starts from Vex and that extends/modifies it if found necessary.
It also seems that one common motivation is to have tools. But why not build tools for Vex?

No worries.    Our goal is to let folks express their thoughts and opinions and ultimately give the members an opportunity to help shape our path forward.  Healthy debate and dialog help us create stronger and more diverse ideas to support our communities and goals.  I appreciate your participation!

I would advise making an effort to better explain why this is needed. The main argument against using Vex seems to be that Vex is immature and lack adoption. I find that pretty unconvincing. I would prefer an approach that starts from Vex and that extends/modifies it if found necessary.
It also seems that one common motivation is to have tools. But why not build tools for Vex?
Arnaud, there are tools for all the VEX formats, but all three formats lack widespread adoption. There's no question there is a big problem with identifying exploitable vs. non-exploitable component vulnerabilities in a software product. However, it appears now that VEX as described in the three published NTIA/CISA documents doesn't address that problem well.
Steve Springett, whose CDX community created the most successful VEX format, recently stated in this blog posthttps://owasp.org/blog/2023/02/07/vdr-vex-comparison that VDR is a much more useful format for this purpose than VEX. That assertion can and should be debated. I honestly think this group could spend its time much better discussing how software users can best be advised of exploitable and non-exploitable component vulnerabilities in the products they rely on. This might be a document or an API; it might be called VEX, VDR or something else. But this discussion needs to happen.
Tom Alrich LLC
312-515-8996

From: Arnaud J Le Hors @.>
Sent: Thursday, March 16, 2023 10:02 AM
To: ossf/wg-vulnerability-disclosures @.>
Cc: Tom Alrich @.>; Mention @.>
Subject: Re: [ossf/wg-vulnerability-disclosures] VOTE - Adopt OpenVEX as project within the OpenSSF under Vuln Disclosure Working Group (WG) (Issue #125)
I've hesitated to vote because like others I very much dislike the tone this discussion has taken but as it has been pointed out this proposal appear to fail the requirements set up by our process. On that basis I vote no.
If anything this should have helped Chainguard identify other interested parties and once they have beefed up a bit the community around this they should be in a better position to bring it here.
I would advise making an effort to better explain why this is needed. The main argument against using Vex seems to be that Vex is immature and lack adoption. I find that pretty unconvincing. I would prefer an approach that starts from Vex and that extends/modifies it if found necessary.
It also seems that one common motivation is to have tools. But why not build tools for Vex?
—
Reply to this email directly, view it on GitHubhttps://github.com/ossf/wg-vulnerability-disclosures/issues/125#issuecomment-1472152488, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVCDY66HNMOE5QMU4GCXPX3W4MTRXANCNFSM6AAAAAAVUEWJZU.
You are receiving this because you were mentioned.Message ID: @.***>

An example CycloneDX VDR is available here:
https://raw.githubusercontent.com/rjb4standards/REA-Products/master/CDXVEX/CDX14.xml
I refer to this as an "implied" VDR model, where only SBOM components with reported CVE are listed.
An explicit VDR model lists all SBOM components and their vulnerability status, including those with no reported vulnerabilities.

Steve's blog is one of the most important links in this entire thread.
I have a different takeaway from it though, and it is actually what Steve himself says in the last sentence "Could it be that a hybrid approach of supporting both VDR and VEX is the way forward? In the end, hopefully, pragmatism will be the clear winner."
The sooner everyone agrees that the concepts of VDR and VEX are largely trying to do the same thing and the only reason they have different names is due to historical happenstance, and we should intersect the venn diagram and get it over with, the better this all will become.

OK it's my turn to express disappointment to have my team's motivations and by proxy the reputation of folks like puerco brought into this discussion. At Chainguard we are committed to making open source software secure by default and driving technologies to solve problems as we come across them.
While a great deal has been made of maintainership in this issue I will call out that there is as yet not enough clarity from the TAC around process and requirements around accepting projects as top level ones vs under the auspices of the working group. And I will highlight that there are current OpenSSF projects under working groups with only maintainers from single organizations e.g. S2C2F. Nevertheless OpenVEX aims to build a strong community and bootstrapped with maintainers from multiple orgs.
To clarify some aspects of open source and the OpenSSF:

We see open source as win/win, a rising tide that raises all boats. Starting a new project does not automatically create conflict or division - this is a zero-sum game mindset that we try to avoid. There are many great examples (e.g. in CNCF of seemingly competing projects thriving)
Anyone is able to plan or propose a new project to the OpenSSF at any stage of the project to a working group.
The GB or OpenSSF itself have nothing to do with projects being accepted to the OpenSSF. The TAC members have no special privilege for project submission.
Simply because you disagree with what someone says does not automatically make it misinformation. And if items need clarification or correction ourselves and media publications are happy to listen, please reach out.
Chainguard have been active participants in the SPDX & CycloneDX interoperability effort which we see as extremely important, we are not the party leaving the table.

We will continue to drive for interoperability where possible, and new elegant solutions where it makes sense -  all in service of making open source secure by default.

My intention is to just understand what exactly is VMWare and Google's major open contributions to the "Open"Vex project and how they have achieved maintainer status.

Primarily I want to comment on voting process and selection criteria relative to OpenSSF: At this point it's quite unclear what criteria voters are applying here.  Multiple comments in the thread have these ambiguous notions of "major" or "enough" in ways not backed clearly by the project lifecycle.
OpenSSF needs better metrics of sufficiency for sandboxing and subsequent graduation.
Second though, trying to put on the hat of a reviewer looking at git repos and this new org on GitHub, and knowing of the quality and passion of folks like @cpanato, @puerco, and @rnjudge: It looks like common co-travelers openly and collaboratively doing early initial review/comment, and that participation then elevating to a bootstrap role. That's not exactly uncommon in open source, and I'd argue is even laudable.  Bootstrap may be followed by formal elections.  Or not?  Governance of tiny early projects is different from large established ones.  The project though should have documented process for it, OpenSSF should expect that, and even maybe offer templates.
I can't speak to @costica11 's other comments as I have literally zero knowledge of anything related to activity which may predate that open collaboration on the openvex git repos.  (I do suspect the same types of clarifying process and documentation improvements in OpenSSF might have helped with the Notary situation they reference.)
Again it feels strangely unfortunate that we're in a position where taking an initial open source collaborative interest in something published on GitHub is suddenly a negative for individuals and a project.

OK folks, I want to thank everyone for their patience and perseverance through this last week.  At this stage, we are going to pause comments on this issue and speak at the next TAC call about this matter.  At this point, I count voting 10 members expressing agreement to adopt the project and 5 members turning it down.  After our TAC meeting I will be reaching out to the outstanding eligible members to see if they are willing and interested in participating.


usage of null with varargs in methods

Hi I have some doubt about the usage of varargs for handling contexts in some methods from connection, for example for the method clear we could write something like:
Repository repo = new SailRepository(new MemoryStore());
repo.initialize();
RepositoryConnection conn = repo.getConnection();

// 1
conn.clear();
// 2
conn.clear(null);
// 3
conn.clear(new Resource[]{});

conn.close();
Repo.shutdown();

I expected the three methods to have a similar behaviour, but instead something like the last (3) option seems not having effects at all.
Am I missing something?
Even if it may sound strange, I would expect passing an array without elements to have the same meaning of passing null: this would be helpful when calling methods from Scala (and similarly I'd expect in Java 8), when usually the adoption of null is discouraged.
What do you think about? Thanks in advance for any comments or suggestion

Well, one could argue this is the intended behavior, because 3) is a list/array of contexts that just happens to be empty.
Say you have an application that stores e.g. submitted form data in separate named graphs / contexts, and from time to time old info needs to be deleted. You run a query to get old contexts, and provide the list to con.clear(), and the triples get deleted.
However, the list may be empty (no old context found), but in this cause you don't want to clear the entire repository (of course, you can also argue that in this example checking for an empty list should be done before passing the list to con.clear)

clear() and clear(new Resource[]{}) should both clear all contexts, if this is not the case please provide a more detailed example.
Whereas clear(null) and clear((Resource)null) and clear((Resource[])null) and clear(new Resource[]{null}) should either clear only the null context or throw IllegalArgumentException.


Implement additional event for click on autocompletion list - fix #16712

So second try.
I changed the event handling for "click" on the completion list to be mousedown and click.
The event handler is wrapped by a debounce function to avoid calling the handler multiple time.
Tested in:

Chrome
Firefox
Safari
IE 11
iOS emulator

If this is done to fix this on touch devices, why can’t we just add a touch event?

If this is done to fix this on touch devices, why can’t we just add a touch event?

It's working fine on Android at the moment - only problem is mobile safari.
So you'd go with binding mousedown and touchstart on the ul?
But touch is not that good supported isn't it? And now that there is the Pointer Events vs. Touch Events discussion going on, I'm not sure, if mouse and touch are the right way.
http://caniuse.com/#feat=touch
As mousedown is a hack for safari and unfortunately is not working on mobile safari I just thought of going the safe road with debounce.
click is fired for everybody except desktop Safari, where mousedown comes into play.

click does seem like the way to go here. @LeaVerou was there a reason for choosing mousedown instead?

The reason for mousedown was that Safari was failing with click, though I don't remember the why.

According to this it seems from a quick read that mousedown should be fired on Mobile Safari, as long as there is a onclick handler on the element (even if empty). Have you tried that @stefanjudis? What about other mobile browsers?

Have you tried that @stefanjudis? What about other mobile browsers?

If I remember correctly I tried the empty eventlistener and it didn't work.
I shipped with a hacked version of awesomplete - so feel free to close this one as no other is complaining about this issue. :)

@stefanjudis, could we consider getting this PR on track again and resolve the conflicts? I shipped a release with a hacked version of awesomplete as well that included a similar fix you wrote here.

@MHanslo I don't have the time for that right now and will close it. But feel free to open a new one and adjust the changes. :) Sorry.


Type mismatch: inferred type is Short.Companion but SnackbarDuration was expected

https://github.com/android/nowinandroid/blob/a83c8731419a9297fd79c27396d7cee9e697b21a/app/src/main/kotlin/com/google/samples/apps/nowinandroid/ui/NiaApp.kt#L241
I'm having the error:

Type mismatch: inferred type is Short.Companion but SnackbarDuration was expected

NiaApp
    import androidx.compose.material3.SnackbarResult.ActionPerformed

    /* Some code */

               NiaNavHost(
                    appState = appState,
                    onShowSnackbar = { message, action ->
                        snackbarHostState.showSnackbar(
                            message = message,
                            actionLabel = action,
                            duration = Short,
                        ) == ActionPerformed
                    },
                )

NiaNavHost
fun NiaNavHost(
    appState: NiaAppState,
    onShowSnackbar: suspend (String, String?) -> Boolean,
    modifier: Modifier = Modifier,
) {

Is this a bug in the code or am I missing some implementation?

It seems you import wrong Short, you need to import SnackbarDuration.Short

@Jaehwa-Noh You're right. That was the problem. Thank you.


Add more quotes.

@mubaris i am working on this

Minimum of 20 :smile:

I've opened a PR with some quotes for you. Let me know if I need to restructure them.

If you are adding more quotes, add 20 quotes in a new json file in data folder. Then make a PR

can more quotes still be added?. I would like to add more.

Yeah. Sure.
On Tue, Oct 10, 2017, 12:07 PM Emehinola Idowu<EMAIL_ADDRESS>wrote:

can more quotes still be added?. I would like to add more.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mubaris/motivate/issues/3#issuecomment-335375345, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ANOqa6GyUv5QyTxalFU0dB5xgoohGFN3ks5sqxC6gaJpZM4PzUoz
.

Great. on it

okay..will iadd in a new json file..

I would like to contribute to this project :hand:

Best way to get started is to add more quotes. Fork the repo and add new json file containing 20 quotes. Then send a PR. :smile:

I've come up with more quotes. Please have a look at it. :smile:

@mubaris I would like to contribute to this.

i would like to contribute

This project is awesome! I would like to contribute to this (even though I'm in the beginner level lol).
My first step: Play with it (installing now).
2nd step:  Find 20 quotes and figure out how to make a json file (I know I should put it into the data folder :) )
3rd step: PR - pull a request
I haven't contributed a project on Github before. Although I've already read articles related to "how to contribute to open source projects", you guys can correct me if I do something wrong. >"<

@EveChen you are good to go.... Awesome!

I added some quotes from famous artists about what motivated them to get work done.

@dhanya1 @Curchel Everyone is welcome to contribute. :smile:

I'm on it too!

Go us!

You're always welcome to add more quotes.

hi there, I would like to also participate in this :). How I can do it?

@Pr00bit you can create a new JSON file following the naming format and add a minimum of 20 quotes... :)

hi thanks for explanation. Just would have small question - in which location the Json file needs to be upladed/created?

OK.....I think there are many dynamics to this. However, when i contributed, I create a JSON file in the "data" folder which is in the "motivate" folder.

Thanks for hint, will try to create Json file then :)

Hi @mubaris , I added 20 more quotes to the data folder and followed this article on how to contribute. Let me know if this is okay :)

Hello, Can I add to this?

You can use this scrapper to extract more quotes from good reads - [https://github.com/abhinuvpitale/Spiders/blob/master/goodreads_quotes_spider.py](

How about automating it to collect quotes by itself? @mubaris

If you have a solution, Please share and make a PR

Please check my PR, maintainer. Thanks for the opportunity.

i will add more quotes too #first_timer

@mubaris can more motivate quotes still be added?.
I would like to add more.

Hi, I added more quotes and just created my first pull request. Thank you for the opportunity and hopefully it's all good. :)

Hi, this project seems great. I am a first timer and was looking for a place to start. I went through the community chat here and this community seems great. Ill try to add a few more quotes. Glad to be a part of this !

Hey!
I just got an idea. We can create a screenlet/widget of this app and run it during startup. Every 15 min new quotes come up. So it sticks around the desktop in a corner. A constant Motivation ;)
How's the idea ? Should I work on this ?

@AbhishekVarghese Your idea sounds awesome. If you can work on that, I'll be so glad. If you need any help, just ping me.

Sent a PR #82
This is my first ever PR ;)
Thanks for letting me work on this :)

Please have look at #88
It's my first time commenting on an issue.

I put in a PR with more quotes if you want to accept it :)
https://github.com/mubaris/motivate/pull/136  #136

Hi @mubaris , I want to contribute also, working on it ...

Hey @mubaris I'd like to contribute as well

Hey @mubaris , I would like to contribute to the project with 20 more quotes.

Hello, I'd like to contribute 45 quotes if you still need them. Thank you!

Hey-
Just created a PR with a new json file of quotes.  It's my first PR, so please let me know if you have any suggestions!  Thanks!

Hi, I am very new at this, but would like to contribute!
I guessed the best way to get started is to play around with it first, then fork-> add a new JSON with 20 or so quotes-> ask for PR
hope it works
please let me know if I am on a wrong track 🤞 😬

@mubaris I want to contribute too.

Hi I would like to contribute too!

Any plan to display quotes in other languages?

Just made a pull request! My first one, please let me know if there are any issues/mistakes :)

Hi! I've added 20 new quotes in the PR #210
Great project!

I want to add quotes to this project.But it is saying permission denied.Could you help please.

I would like to start on this as well - I forked the repo. Should I try adding the quotes now?

I would like to contribute to this. Why are we manually adding quotes? We can randomize it. Just a thought :)

Interested. Agreed with Deb23, would be good to have an API provide quotes on the fly. Either it can scrap off quotes from motivational sites or use some existing quotes API for the same

I would like to contribute!

This is an interesting project.Can i join to contribute?

I would like to contribute to this project. Why don't we consume API that provides motivational quotes in real-time rather than adding and maintaining a manual inventory? Checkout some API link https://rapidapi.com/HealThruWords/api/universal-inspirational-quotes

Sure Lakshmi let's do it
On Sat, 5 Oct, 2019, 11:49 PM Lakshmikanth Rajamani, <
<EMAIL_ADDRESS>wrote:

I would like to contribute to this project. Why don't we consume API that
provides motivational quotes in real-time rather than adding and
maintaining a manual inventory? Checkout some API link
https://rapidapi.com/HealThruWords/api/universal-inspirational-quotes
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mubaris/motivate/issues/3?email_source=notifications&email_token=ACPIB46W322X37IFXYGNQKTQNDLE7A5CNFSM4D6NJIZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEANYWRA#issuecomment-538676036,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACPIB45Q4LHI6FTQVCQ6ZWDQNDLE7ANCNFSM4D6NJIZQ
.

Lets do it !

Hi, I'd like to contribute to this repo as well.

Added 20 new comments. @mubaris

Added 20 quotes #337

Greetings, I'd like to contribute to this repo (beginner level). This is uplifting and motivating.

I would like to contribute to this

Hi, I'm also contributing! Hooray! Gonna make my first PR.

Hello, adding my contribution here! #384

Hi, everyone! I just did my first PR here.  #393

I want to do this!

Is this still an active issue?

what if we setup a scrapper bot to fetch the quotes from a well know quote site??? in that way we can have so many quotes

@salmannotkhan That sounds interesting.

Added one more for Dennis Ritchie (DMR) https://github.com/mubaris/motivate/pull/411
RIP

@hydeenoble @salmannotkhan
There is some support for that:
For example:
$ python -c 'from quotes_api import ForismaticAPI; import json; print(json.dumps(ForismaticAPI().get_random_quote(), ensure_ascii=False))' motivate/quotes_api.py
# Output manually reformatted, because github does not wrap long lines ;)
{
  'quote': 'Time stays long enough for anyone who will use it.',
  'author': 'Leonardo da Vinci'
}

Hi, I would like to contribute to it.

Hi, I would like to contribute to it

Hi, this is my first PR here. #419

Hey everyone !!
As, this project is not actively maintained now, I've forked it and updated it for the contributors here.
PRs are welcome :tada:.
There is also a new gitter community room for chat in case anyone needs help or to communicate with each other. :+1:

There are some of you who've already opened PR here, for them:
Just open a new PR with base avats-dev/motivate like below:

For them who are new:

fork repo
clone https://github.com/avats-dev/motivate.git
follow these guides.

This new repo is active, and I'm maintaining this. Feel free to drop a message on gitter chat if you're stuck or need help.

I would add instructions for FIRST TIMERS in a short while to assist them and get started with OPEN SOURCE.

Thanks everyone for contributions. :heart:


Place header files on a separate directory

Hi,
So here's the question:
In my repository, I have the following directory structure:
src                                     -> all source files
include/#{projectName}/   -> all headers
test/                                   ->

Is there a way to tell ceedling to generate headers under include/projectName/srcName.h instead of src/srcName.h?

Yep see https://github.com/ThrowTheSwitch/Ceedling/blob/master/plugins/module_generator/README.md for full configuration options, but TL;DR  you would add this your project.yml:
:module_generator:
  :project_root: ./
  :source_root: src/
  :inc_root: include/#{projectName}/
  :test_root: test/

Worked beautifully, thank you


allow endOfNight.sh to be run with an arbitrary date

y'know, to reprocess historical data.

That's a great change! I was thinking about it this week when reprocessing the previous day's data and I had to edit the script because it was 12:03 pm...
Thanks


Python 3.8.6 has an incompatibility with gevent and gunicorn

When using the python:3.8 image, gunicorn and gevent do not play nice and infinite loop.

Do you have an example command / Dockerfile we can use to reproduce?

Closed source unfortunately - it looks like a very recent (today) change to python:3.8 caused an old version of gevent (1.4.0) to break.
Apparently 1.4.0 was never tested on 3.8 so this compatibility was always suspicious and untested - so that's not ideal.

If anyone else hits this issue or this issue: https://github.com/gevent/gevent/issues/1679
The resolution is to update gevent to a modern version, we used 20.9.0 and that resolved it.

Ah, so this is an upstream Python / gevent incompatibility?  (and we can close this issue?)

I'm not sure, I think so. You might see other people find this issue over the next few days.

Ok, sounds good; since there's nothing we can do to fix this in the image, I'm going to close.
Hopefully other users running into the same will find this thread. 👍


add link-local IP to veth0 for istio

robot cherry pick PR https://github.com/spidernet-io/spiderpool/pull/3588 from cyclinder,to branch release-v0.9,  action https://github.com/spidernet-io/spiderpool/actions/runs/9609000879  , commits 13c95f09d9040352c02750cb8d8d970feea319f5

@ty-dc  ci

The code merged into release-v0.9 triggers the pull_request_target to use the image of the main branch.

     fail to run a pod when IP resource of an ippool is exhausted and an IP who is set in excludeIPs field of ippool, should not be assigned to a pod [E00008, S00002]

Warning  FailedCreatePodSandBox  4m38s (x17 over 8m8s)  kubelet            (combined from similar events): Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "915253528605f96a4db27301569495040e6e5bfd93e55e643aff6b04711acd4e": plugin type="multus" name="multus-cni-network" failed (add): [ns187-858559962/deploy187-858549683-5b4569f6dc-qrqk7/7a54422a-5a39-4650-8e1d-07d5d67ab318:macvlan-vlan0]: error adding container to network "macvlan-vlan0": spiderpool IP allocation error: [POST /ipam/ip][500] postIpamIpFailure  failed to allocate IP addresses in standard mode: it's invalid to use 'ipam.spidernet.io/subnets' or 'ipam.spidernet.io/subnet' annotation when Auto-Pool feature is disabled

The upgrade-ci command in cherry-pick fails due to an image usage error.


[SA-21814] https git protocol

Description
Checklist

[ ] Bump .version and .appVersion in k8s/crd/Chart.yaml
[ ] Bump .version and .appVersion in k8s/operator/Chart.yaml

Need help how to generate the docs and testing this internally

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: mandopaloooza:x: dlnilssonYou have signed the CLA already but the status is still pending? Let us recheck it.


reset scrollbar position to top onFilterQueryChanged

Prerequisites:
Number of bookmarks > 300
StR:

Open PagesManager
Scroll bookmarks list approximately to the center
Enter any search query which is leads to success (reduces number of items in the bookmarks list)

=> the list remains scrolled: the most relevant search results are not visible because they are at the top of the list

Moved to PM repository


Textblock rendered as visual brush in combobox.

Describe the bug
When directly set TextBlock as ComboBox 's Items, selected item will be rendered as Rectangle with the text as brush.
To Reproduce
Add below control in any of your sample project.
  <ComboBox>
    <TextBlock>AAA</TextBlock>
    <TextBlock>BBB</TextBlock>
    <TextBlock>CCC</TextBlock>
  </ComboBox>

The selected Item looks abnormal.

Expected behavior
It should behave exactly as set ComboBoxItem directly as Items, which looks like below.

Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: Windows 11
Version 11.0.0-preview5

Additional context
Checking the Visual tree, when item is TextBlock, it is converted to a Rectangle with the text as visual brush.

This is the logic from
https://github.com/AvaloniaUI/Avalonia/blob/master/src/Avalonia.Controls/ComboBox.cs#L421-L454
Here TextBlock is not a ContentControl thus it goes to the Rectangle logic. Why do we need to do this?
I found this issue when I was developing Semi.Avalonia, it looks way much worse when apps are published.

Well, the same control cannot be simultaneously attached to both the ComboBox and its Popup.
When it is inside a ComboBoxItem, then its Content is a string, which causes a new TextBox control to be created inside the ComboBox, but when you specify that it is a TextBlock, it is not possible to connect the same TextBlock twice to the visual tree.

It still seems to me a bug in VisualBrush.

It still seems to me a bug in VisualBrush.

Yep, the visual brush looks awkward. But I think it's another issue.


Chapter numbering is incorrect

There are two chapter 2's. Renumber chapters and fix up all chapter references.

Fixed in #14.


Also update the graph thumbnails automatically?

Maybe we could write a very short imagemagick script to put all the plots together and resize them?

A little:
convert +append timeline.png top_municipalities.png province_count_time.png -resize 1000 static/static_descriptive.png

should do it!

That would be very nice IMO. Perhaps also rename it to thumbnail_descriptive.png or something similar as it is no longer static?

Great, I did some work on this. I will push some results somewhere today!

Can this be closed or is it still work in progress? @J535D165