DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
- The Apache Software Foundation (ASF) is one of the first and largest open source organizationsfoundations, home to many high profile projects.
- Background on the ASF (statistics, videos, and links) can be found at: https://apache.org/.
- Software developed at the ASF is made available at no cost and without warranty, under a license permitting commercial modification and reuse without notification. Many commercial products include ASF software without the end user being aware.
- Projects act independently and set their own technical policies and directions and have their own communities of developers and management
- Required policies exist for important supply-chain functions such as security vulnerability handling and notification, release management and distribution.
...
The ASF is a US 501(c)3 non-profit charity that acts as a steward for several hundred open source projects. The ASF is one of the largest open source organizations in the world, and is home to prolific projects such as Apache Hadoop, Apache Tomcat, Apache Cassandra, and scores of others. The The ASF provides a known and vetted set of governance, intellectual property, and release processes as well as providing a vendor-neutral place for contributors to collaborate. However, within those processes there is a high degree of autonomy for each project. Projects decisions are driven by the people doing the work. The ASF Board of Directors is responsible for project oversight, ensuring the health and vitality of each project.
...
ASF projects are run by Project Management Committees (PMCs). PMC members nominate and vote on new PMC members and collectively manage community, security, trademarks, or other problems. The The PMC plays a key role in technical project oversight, but not the only role. The full project community contributes by working, creating and reviewing patches and contributing to discussion.
The ASF regards all contributors as individuals and volunteers as part of its vendor neutrality. We do this despite the fact that many, if not most, of our contributors are paid by their employers to contribute to projects at the ASF. As part of that neutrality, we expect that all ASF contributors act in the best interest of the project. Additionally, who a contributor works for has no bearing on their standing in any particular project community. Contributors earn different levels of project standing based on their contributions to the project.
- The Apache Way
- How to get involved with the ASF
- https://apache.org/theapacheway/index.html
- https://www.apache.org/foundation/getinvolved.html
How development works (https://www.apache.org/dev/pmc.html)
The ASF doesn't pick technologies or set technical direction for our projects. Projects to have to adhere to various foundation-wide policies including trademarks, release policy, security vulnerability handling policy. However the number of mandated policies is kept to a minimum to allow projects to manage their own processes (for . For example there is no software development life cycle (SDLC policy)) policy mandated by the foundation, each project is expected to set its own.
We also require that everything happens in the open:
...
Software developed at the ASF is made available at no cost and without warranty
Commercial products may include ASF software without entering into any form of contract with the ASF, or even notifying us
- Vendors of said commercial products though, must inform end users as indicated in section 4a of the Apache License, Version 2.0
- Once informed, it is the responsibility of end users to keep track of whether and where an ASF software is used and which version(s), possibly with the help of a Software Asset Management (SAM)
- End users may purchase these products but may have little interest or ability to apply fixes
- There is a natural nesting that happens as software dependencies propagate through applications. Addressing vulnerabilities in base level components (e.g. log4j) has a cascading impact. Unless and until all downstream systems have effectively automated build, test and deployment systems, this creates systemic risk which has nothing to do with OSS per se.
- ASF software is used in running systems in basically 2 ways:
- A distributed system includes a running ASF product (e.g. Apache web server)
- ASF software is integrated with other software to build applications. When applications created are themselves used to create other applications, nesting happens, causing the impact of a vulnerability or incompatible change at the lowest level to have a cascading impact. When a new release is made available by an ASF project, downstream users need to minimally make configuration changes and test their systems. They typically have to rebuild and redeploy their applications. In nested situations, this often has to happen sequentially.
...
The ASF encourages responsible disclosure of security vulnerabilities discovered in software managed by ASF projects. The ASF security team sets a common policy, maintains security contacts for PMCs, and provides support for projects responding to security issues. Reporters are encouraged to use the designated security contacts to report vulnerabilities privately. PMCs are required to respond to security reports promptly, working with reporters to investigate and if necessary develop patches.
The ASF Security team are is a CVE Project Candidate Naming Authority (CNA). CVE names are issued to vulnerabilities regardless if they are found by the project committers, members, PMCs, other ASF members, or third-parties. The ASF Security team and PMCs work from time to time with third parties who wish to perform security functions such as code audits , and bug bounties.
The ASF Security team assist the PMC PMCs in publishing a CVE once the vulnerability has been patched and a release containing the patch has been made available. Vulnerability reports are sent to common and consistent locations including security lists, project development lists, and announce@apache.org. The security team oversee oversees all reported issues across all ASF projects. The security team report reports monthly to the board and produce produces other public reports:
...
End of life is an industry standard concept that we apply at the ASF. End of life means no more patches. Like all software products, ASF code lines go through a lifecycle that terminates in end of support. Typically, ASF PMCs communicate end of support dates for products or code lines with ample time (one year plus) for users to plan upgrades or find alternatives. Once communicated end of life dates arrive, the PMC is no longer expected or required to accept or apply patches to the end of life versions. This includes security patches against identified vulnerabilities. Therefore in some cases, when users who are depending on no longer supported versions of ASF software, a version upgrade will be required on the users side to obtain a fix of an identified vulnerability and that which may also require code changes to integratebe integrated. The ASF security team may still issue CVE names against EOL software to help users quantify the risk.
End of life software running in critical systems is a systemic risk which is not unique to open source software or the ASF.
...
The content above was developed on the security-discuss@community.apache.org mailing list, and perusing the archives there from late December 2021 to early January 2022 may provide important context. Everyone is invited to participate there, but be aware that posts to that mailing list are publicly archived. Background reading used to construct this page:
...