[Bug 62131] New: dependency on MSVC2010
https://bz.apache.org/bugzilla/show_bug.cgi?id=62131 Bug ID: 62131 Summary: dependency on MSVC2010 Product: Tomcat 8 Version: 8.5.x-trunk Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: evgeny.marmalst...@verint.com Target Milestone: When Tomcat is starting it requires MSVC2010 (MSVCR100.dll). I think it is related to JNI. MSVCS2010 will end of extended support on May 2018. When is planned to upgrade the dependency. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Is Gump still useful for you?
On 2018-02-24, Mark Thomas wrote: > On 23/02/18 17:52, Stefan Bodewig wrote: >> Are you even aware Gump is there and do you still consider it to provide >> value to your project? This is not any request for you to get involved >> but really a curious question. > Personal view, not speaking for the project. > Yes and yes. Thanks Mark. Tomcat is the one project where I was sure you knew Gump was still there. > Another area that is particularly useful is the tests against the latest > OpenSSL build. Gump enables is to spot within 24 hours when OpenSSL has > added a new cipher, removed an old cipher, etc so we can update our > integration. Great, this is a really good example of where Gump is able to do more than traditional CI systems. Many thanks Stefan - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62131] dependency on MSVC2010
https://bz.apache.org/bugzilla/show_bug.cgi?id=62131 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED OS||All Resolution|--- |INVALID --- Comment #1 from Mark Thomas --- Tomcat is pure Java and as such has no dependencies on any Windows DLLs. The report mentions when Tomcat is starting so this reported relates to Tomcat at run-time but for completeness I have reviewed all the supporting components that do have a native Windows component whether they are used at run-time or not. Windows Installer - No such dependency Windows Service Runner 32-bit - No such dependency Windows Service Runner 64-bit - No such dependency Windows Service Manager 32-bit - No such dependency Tomcat Native Connector 32-bit - No such dependency Tomcat Native Connector 64-bit - No such dependency ISAPI redirector 32-bit - No such dependency ISAPI redirector 64-bit - No such dependency Which as I as would expect given that the project has taken great care to ensure that Tomcat does not have any dependency on the Microsoft Visual Runtime. Note that if you have built one of these supporting components yourself, or obtained them from a source other than the ASF or one of our mirrors, then it is possible that they will have been built differently and do have such a dependency. In this case you should seek support from the provider of the component. It is also possible you are seeing a dependency of the Java Runtime Environment. If this is the case you should seek support from your JRE provider. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62132] New: No reliable way to know if the request emerged from localhost
https://bz.apache.org/bugzilla/show_bug.cgi?id=62132 Bug ID: 62132 Summary: No reliable way to know if the request emerged from localhost Product: Tomcat 7 Version: 7.0.82 Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: vasa@gmail.com Target Milestone: --- We have a requirement such that admins(tomcat users) need to login remotely to the machine where Tomcat is hosted and access tomcat webapp to perform certain action or see certain pages . These pages or actions are not permitted if users login remotely Initially thought request.getRemoteAddr can be used determine actual client ip is local or not but looks like based X-Forwarded-For header it is easay to spoof request.getRemoteAddr . The spoofing is possible even from trusted internal proxies So thought request.getServerName is reliable than request.getRemoteAddr But HOST header can be spoofed to reflect request.getServerName Strangely Tomcat honors HOST header to update request. getServerName . I strongly feel this is a tomcat issue or let us know how can we reliably determine if the request is originated from local or this is something not possible -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
