> -----Ursprüngliche Nachricht----- > Von: Mark Thomas [mailto:ma...@apache.org] > Gesendet: Freitag, 17. Juli 2015 12:33 > An: Tomcat Users List > Betreff: Re: Question concerning mod_jk Security Fix CVE-2014-8111 > > On 16/07/2015 13:16, Kreuser, Peter wrote: > > Please let me repeat my question from June 6th: > > > > Why is this CVE still not addressed in "Apache Tomcat JK Connectors > > vulnerabilities" http://tomcat.apache.org/security-jk.html? > > > > http://www.cvedetails.com/cve/CVE-2014-8111/ > > I'm a project committer but this is my personal view. It is not an > official project view. > > The information on that CVE was leaked by RedHat's security team when > they broke embargoes associated with two Tomcat security vulnerabilities > that they had been informed of in advance and in confidence. (There were > also errors in the information they leaked about the other vulnerability > that made it appear to be much worse than it actually is.) > > To be clear, the Tomcat committers who are employed by RedHat were in no > way responsible for the leaking of this information. The leak was > entirely the fault of the RedHat security team. > > The mod_jk releases involve producing a large number of Windows binaries > and experience with tc-native suggests that figuring out the build > process - even with the available documentation - will be non-trivial. > To give you an idea of what is likely to be involved, compare the > documented build instructions for tc-native on Windows [1] with what is > actually required to produce a release [2]. > > Co-coincidently, the committers who typically handle the mod_jk releases > are RedHat employees. > > Given all the above, I personally have little desire to dedicate a large > chunk of my time figuring out the mod_jk build process so I can clear up > the mess created by RedHat's security team. I'm not against spending the > time to better document the mod_jk build process (like I did for > tc-native) but that isn't a priority for me right now. > > I had hoped that, given that the mess is of RedHat's making, that RedHat > would have directed one if its emmployees who is familiar with the > mod_jk build process to spend the time necessary to produce a new mod_jk > release. That hasn't happened. > > I hadn't realised - until I looked into it as a result of your e-mail - > how long it has been since RedHat leaked this confidential information. > It is looking increasingly like one of the Tomcat committers is going to > have to clean up RedHat's mess for them. > > I'm not going to be in a position to do anything to fix this until week > beginning 27th July but if nothing has been done by then I'll see what I > can do. > > <rant> > If I do end up having to clear up this mess I'll be even more annoyed > with RedHat's security team than I am already. I don't actually mind > that much that a mistake was made. We all make mistakes and I have made > very similar mistakes in the past. What annoys me about this - and I get > more annoyed the longer this goes on - is that after RedHat realised > they had leaked vulnerability information and that some of the > information they had leaked as incorrect RedHat have not (to my knowledge): > - publicly stated some of the leaked information was incorrect; > - publicly corrected the errors in the information they did leak; > - publicly apologised for leaking the information (they have apologised > in private so this is less of an issue); > - done anything to help clear up the mess such as directing their > employees who are Tomcat committers to help with the various releases > that became more urgent as a result of these leaks. > > It is this last point that particularly annoys me. > > It bears repeating here that the RedHat employees who are committers are > in no way responsible for this mess. It just so happens that they are > best placed to clean it up. > </rant> > > I know this doesn't give you the release you need but hopefully you'll > at least have a better understanding of how we ended up where we are and > you do have my assurance that I'll look into this (with no guarantee > I'll be able to produce the release) in just over a week if no-one beats > me to it. > > Note you do have the option of building from trunk. I'm not aware of > anything that needs fixing in mod_jk before the next release so the > chances are that a build from the current trunk is going to be very > close to a 1.2.41 release. > > Mark > > > [1] http://tomcat.apache.org/native-doc/ > [2] http://wiki.apache.org/tomcat/BuildTcNativeWin > > > > > > > > > --------------------------------- > > Hi, > > > > could you please tell us, when the fixed mod_jk-Version 1.2.41 will be > > publicly available? > > > > The webpage does not mention any vulnerability at all, plus no newer > > release than the vulnerable 1.2.40. > > > > For now RedHat mentions only the fix to the source code from December 2014. > > http://svn.apache.org/viewvc?view=revision&revision=1647017 > > > > Best regards. > > > > Peter > > > > >
Hi Mark, I appreciate your open comment and that clarifies the lengthy wait. I trust that now the solution gets going and will be solved soonish. I'm in no position to criticize any wrongdoing on this CVE. I only hope to find a clearer communication on the tomcat-security sites in the future and if THAT is RedHat's fault, then please clean up the process with them. Thank You. Best regards, Peter PS: is that the correct position to add my response? --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
