> -----Original Message----- > From: Jukka Zitting [mailto:[email protected]] > > 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?
My biggest concern is early disclosure of the vulnerability. If using a public commit the risks are: a) patch may be reverse engineered before release b) process of approving patch may be obviously different, highlighting that it may be security related Not much you can do about a) apart from security by obscurity. Not great but if the window between commit and release is small (few days) then you are usually OK. b) is down to the project to be careful If using a private branch the risks are: c) community is excluded from voting/commenting on release d) uploading of files for release that has not been publically discussed is a clear indicator of a security issue (diff of the uploaded src and current svn head will ID patch which can then be reverse engineered) e) have to wait for the mirrors to sync or www.a.o/dist could be overwhelmed f) using a different, unfamiliar process can lead to mistakes If the release is just a security fix over and above a previous release then c) is probably not a major concern. d) is my biggest concern, particularly if e) applies. If e) doesn't apply then the private branch approach is probably better, assuming the everything is correctly merged back into svn trunk etc. If e) applies then the time to sync the mirrors is the head start the attacker has to get the src, do the diff, work out what the vulnerability is and use it. I know from bitter personal experience how easy it is to get things wrong and inadvertently publicly disclosure a vulnerability. The risks of f) should not be under estimated. My own view is that the public commit is generally the better choice and the one I would recommend projects follow. > 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? I assume not, give the high demand there would be for a critical security fix something like httpd. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
