Re: [PR] Update, refactor and polish instructions of the documentation. [tomcat-native]
dsoumis merged PR #25: URL: https://github.com/apache/tomcat-native/pull/25 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat-native) branch main updated: Update, refactor and polish instructions of the documentation. (#25)
This is an automated email from the ASF dual-hosted git repository. dsoumis pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/tomcat-native.git The following commit(s) were added to refs/heads/main by this push: new 2b1082d95 Update, refactor and polish instructions of the documentation. (#25) 2b1082d95 is described below commit 2b1082d95f8cb05f4df3bc7cfef83a40ee8de11b Author: Dimitrios Soumis AuthorDate: Tue Jul 9 11:45:20 2024 +0300 Update, refactor and polish instructions of the documentation. (#25) * Update, refactor and polish instructions of the documentation. Remove building section for windows and refer directly to the wiki as it was more confusing than helpful. Fix changelog.xml --- xdocs/index.xml | 112 1 file changed, 47 insertions(+), 65 deletions(-) diff --git a/xdocs/index.xml b/xdocs/index.xml index 24be0623d..9a359adab 100644 --- a/xdocs/index.xml +++ b/xdocs/index.xml @@ -61,7 +61,7 @@ list of changes. - Build tc-native requires three components to be installed: +To build TC-Native, the following components must be installed: APR library @@ -70,73 +70,53 @@ list of changes. - In debian based Linux those dependencies could be installed by something like: +For Debian-based Linux distributions, these dependencies can be installed using the following command: -apt-get install libapr1.0-dev libssl-dev +apt-get install libapr1-dev libssl-dev openjdk-11-jdk - In rpm based Linux those dependencies could be installed by something like: +For RPM-based Linux distributions, these dependencies can be installed using the following command: -yum install apr-devel openssl-devel +yum install apr-devel openssl-devel java-11-openjdk-devel -On all the POSIX systems (Linux, Solaris, HP-UX, AIX etc...) a well-known -configure and make is used to build tc-native. -In the jni/native runs: + On all POSIX-like systems (Linux, Solaris, HP-UX, AIX etc...), the well-known + configure and make are used to build TC-Native. + To see a description of all configuration parameters, run the following command in the native directory of the source distribution: ./configure --help -to read the description of all the parameters. +To create the includes and makefiles necessary for building TC-Native, use the following command: ./configure --with-apr=$HOME/APR \ --with-java-home=$JAVA_HOME \ --with-ssl=$HOME/OPENSSL \ --prefix=$CATALINA_HOME -to create the includes and makefiles to be able to build tc-native. Where: -$HOME/APR is something like /usr/bin/apr-1-config or the path -where apr is installed. -$JAVA_HOME is something like /home/jfclere/JAVA/jdk11 or the -path to a JDK installation. Any JDK should work but it is advisable to use -the same JVM version the JVM you use with Tomcat. +$HOME/APR is the path to the APR installation, such as /usr/bin/apr-1-config. +$JAVA_HOME is the path to a JDK installation, for example, /home/jfclere/JAVA/jdk11. + Any JDK version should work, but it is advisable to use the same JVM version as the one you use with Tomcat. $HOME/OPENSSL is the path where OpenSSL is installed. $CATALINA_HOME is the path where the produced libraries will be -installed. Something like $HOME/apache-tomcat-10.1.0 +installed, such as $HOME/apache-tomcat-10.1.0 -The configure is able to guess most of OpenSSL standard installations. -So most of the time the following will be enough: + The configure script can automatically detect most standard APR and OpenSSL installations. Therefore, an equivalent command is usually sufficient: ./configure --with-apr=/usr/bin/apr-1-config \ ---with-java-home=/home/jfclere/JAVA/jdk11 \ ---with-ssl=yes \ ---prefix=$CATALINA_HOME +>./configure --with-java-home=$JAVA_HOME --prefix=$CATALINA_HOME -To build the libraries and install them: + To build and install the libraries, run: make && make install -The libraries will be found in $CATALINA_HOME/lib +The libraries will be installed in $CATALINA_HOME/lib. - Download the Windows sources of tc-native and extract them. - - - Obtain the Windows sources for - http://apr.apache.org/download.cgi";>APR and - https://www.openssl.org/source/";>OpenSSL. Apply the patches from - native/srclib and build APR and OpenSSL for your platform (X86 or X64). - - -Build with nmake -f NMAKEMakefile WITH_APR=... WITH_OPENSSL=... APR_DECLARE_STATIC=1 - - -More detailed instructions including the steps to create a standard release +Detailed building instructions including the steps to create a standard rele
[Bug 69175] New: https://eikomp.com/
https://bz.apache.org/bugzilla/show_bug.cgi?id=69175 Bug ID: 69175 Summary: https://eikomp.com/ Product: Tomcat Native Version: 2.0.5 Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Documentation Assignee: dev@tomcat.apache.org Reporter: kajalgupta...@gmail.com Target Milestone: --- We pledge to remain abreast of the latest regulations and standards and leverage technology and data-driven insights to deliver efficient and effective solutions. -- 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 69176] New: https://eikomp.com/
https://bz.apache.org/bugzilla/show_bug.cgi?id=69176 Bug ID: 69176 Summary: https://eikomp.com/ Product: Tomcat Native Version: 2.0.5 Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Documentation Assignee: dev@tomcat.apache.org Reporter: kajalgupta...@gmail.com Target Milestone: --- We pledge to remain abreast of the latest regulations and standards and leverage technology and data-driven insights to deliver efficient and effective solutions. https://eikomp.com/ -- 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 69175] SPAM SPAM SPAM SPAM
https://bz.apache.org/bugzilla/show_bug.cgi?id=69175 Chuck Caldarale changed: What|Removed |Added OS||All Summary|https://eikomp.com/ |SPAM SPAM SPAM SPAM Resolution|--- |INVALID Status|NEW |RESOLVED -- 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 69176] SPAM SPAM SPAM SPAM
https://bz.apache.org/bugzilla/show_bug.cgi?id=69176 Chuck Caldarale changed: What|Removed |Added Resolution|--- |INVALID Summary|https://eikomp.com/ |SPAM SPAM SPAM SPAM Status|NEW |RESOLVED OS||All -- 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: OpenSSL alternatives using FFM
On Fri, Jul 5, 2024 at 10:55 PM Christopher Schultz wrote: > > Rémy, > > On 7/4/24 09:15, Rémy Maucherat wrote: > > As an experiment, I tested with LibreSSL and BoringSSL on LInux using > > the FFM code. Both did not need too many API changes to start working, > > so I committed the changes to "add support" for them. > > \o/ > > I'm very happy that you have had the inclination to make this work. > While OpenSSL is everywhere, many OSs are opting to provide "compatible" > clones such as LibreSSL and BoringSSL and the fact is that they aren't > 100% compatible. > > I'd really like to support them because that means supporting Good > Crypto in as many places as are possible. > > (I'd like to see some updated performance numbers from Jean-Frederic on > "Pure Java" TLS versus OpenSSL-based TLS. When we talked about it years > ago it looked like there was a bug in Java preventing it from using > hardware crypto to Java performed terribly in comparison. And of course > used much more resources (e.g. power). I lack the expertise in these libraries to really know what the expected behavior is ... Insights welcome. > > LibreSSL: > > - I cannot get it to renegotiate anything. The client always gets a > > "no_renegotiation" alert. > > - Seems relatively complete. > > - I tested with Linux and 3.9. > > - Testing is easy on GitHub. Out of the box with macos-latest using > > LibreSSL 3.3. Verified it does the same as my 3.9. > > Maybe LibreSSL refuses to renegotiate? > > > BoringSSL: > > - Only TLS 1.3 "renegotiation" seems to work (TestClientCertTls13). > > This could be seen as acceptable. > > - It seems very bare bones, all the stuff for supporting exotic certs > > seems to be gone. So basically you need a standard certificate doing > > TLS 1.3 and that's all it does, but it then just works. > > - When it doesn't like something, the client gets a connection close > > (no alert, no nothing; I guess sending alerts is less efficient ;) ). > > - Testing is far more problematic. The project is quite "original" in > > that it does not do releases. Funny (not ...). > > I think the above (except maybe lack of alerts) is all intentional. > BoringSSL is intended to support "What people should be using today" and > so it lacks all those decades of old code to support things nobody > should be using anymore. I thought it supported TLSv1.2 though... TLS 1.2 seems to work without renegotiation. For both TestSsl [and also the browsers] works. > > I don't have much experience with these so maybe I'm doing something > > wrong. For both, the basics (TestSsl) and quite a bit more work, but > > not everything. BoringSSL inspires more confidence in what it does and > > how it does it than the other one, but not having releases is > > obviously a deal breaker ... > > > > So I'm not very impressed. Given the amount of work it still seems > > "ok", but that's about it, OpenSSL is by far the best choice for > > Tomcat without even factoring in possible quic support in the future. > > I think michael-o has done some more elaborate testing with LibreSSL. He > might be willing to enable FFM and put it through its paces a little > more than you have had time for so far. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
