Hi, In the past few days I've been trying to gather information on how Apache projects are handling security vulnerabilities. The Security Committee has created a nice summary at http://www.apache.org/security/, but unfortunately there doesn't seem to be a good forum for discussing the details. I'm hoping to use community@ for this purpose.
One especially interesting topic is how an open source project that normally should conduct it's affairs in public should handle security vulnerabilities. Responsible disclosure means that a vulnerability should be kept private until the project has had a chance to develop and release a fix for that issue. How should this be handled at Apache? The process at .../security/ answers parts of that question, but I find some steps like the suggestion to obscure the commit that fixes a vulnerability a bit awkward. One idea I came up with is to have a read-protected area in svn where (only?) security fixes can be developed and prepared for release. A PMC could work in such an area in private until it has voted (again in private) to release the fix. At that point the "security branch" would be moved to the normal project area where the all changes become public and can be merged back to the project trunk. Is such a setup worth the effort? A related point is the delay that our mirror infrastructure puts on the release process. A security release that gets set up for mirroring is already publicly available even though it can't under current policies be announced until 24 hours later. Would it be acceptable to avoid this delay by pointing people directly to www.apache.org/dist when releasing security fixes? BR, Jukka Zitting --------------------------------------------------------------------- To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
