netty / netty-tcnative

A fork of Apache Tomcat Native, based on finagle-native

Netty Project

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.

Links

• Web Site
• Downloads
• Documentation
• @netty_project
• Official Discord server

How to build

For the detailed information about building and developing Netty, please visit the developer guide. This page only gives very basic information.

You require the following to build Netty:

• Latest stable OpenJDK 8
• Latest stable Apache Maven
• If you are on Linux or MacOS, you need additional development packages installed on your system, because you'll build the native transport.

Note that this is build-time requirement. JDK 5 (for 3.x) or 6 (for 4.0+ / 4.1+) is enough to run your Netty-based application.

Branches to look

Development of all versions takes place in each branch whose name is identical to <majorVersion>.<minorVersion>. For example, the development of 3.9 and 4.1 resides in the branch '3.9' and the branch '4.1' respectively.

Usage with JDK 9+

Netty can be used in modular JDK9+ applications as a collection of automatic modules. The module names follow the reverse-DNS style, and are derived from subproject names rather than root packages due to historical reasons. They are listed below:

• io.netty.all
• io.netty.buffer
• io.netty.codec
• io.netty.codec.dns
• io.netty.codec.haproxy
• io.netty.codec.http
• io.netty.codec.http2
• io.netty.codec.memcache
• io.netty.codec.mqtt
• io.netty.codec.redis
• io.netty.codec.smtp
• io.netty.codec.socks
• io.netty.codec.stomp
• io.netty.codec.xml
• io.netty.common
• io.netty.handler
• io.netty.handler.proxy
• io.netty.resolver
• io.netty.resolver.dns
• io.netty.transport
• io.netty.transport.epoll (native omitted - reserved keyword in Java)
• io.netty.transport.kqueue (native omitted - reserved keyword in Java)
• io.netty.transport.unix.common (native omitted - reserved keyword in Java)
• io.netty.transport.rxtx
• io.netty.transport.sctp
• io.netty.transport.udt

Automatic modules do not provide any means to declare dependencies, so you need to list each used module separately in your module-info file.

netty-tcnative's Issues

Gradle doesn't like boringssl-static profile pom

Gradle seems to be a little stricter than maven when resolving artifacts that use classifiers. In particular it doesn't like the fact that the artifact name in the pom being simply 'netty-tcnative' when it has to resolve it in the repo in separate location

• What went wrong:
  Execution failed for task ':grpc-benchmarks:extractIncludeProto'.

  Could not resolve all dependencies for configuration ':grpc-benchmarks:compile'.
  Could not resolve io.netty:netty-tcnative-boringssl-static:1.1.33.Fork12-SNAPSHOT.
  Required by:
  io.grpc:grpc-benchmarks:0.13.0-SNAPSHOT
  Could not resolve io.netty:netty-tcnative-boringssl-static:1.1.33.Fork12-SNAPSHOT.
  > inconsistent module metadata found. Descriptor: io.netty:netty-tcnative:1.1.33.Fork12-SNAPSHOT Errors: bad module name: expected='netty-tcnative-boringssl-static' found='netty-tcnative'

Will take a look at fixing....

Fix build issues on Windows

It seems like one or more of 02fd410, c8a6e7c, and ef7cd7e broke the windows build.

@normanmaurer and @fondemen, could you please take a look and fix it?

HTTP/2 encoder frame merge does not handle integer overflow

The DefaultHttp2ConnectionEncoder does not handle integer overflow when merging frames. Merge attempts should fail when integer overflow of the total size will occur: https://github.com/netty/netty/blob/4.1/codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2ConnectionEncoder.java#L360

CI Server links broken in wiki page

Hi,
I followed the link http://netty.io/wiki/forked-tomcat-native.html#wiki-h2-5 to find 64-bit windows APR DLLs, but the links are broken, due to maybe CI Server changes (jenkins => TeamCity).

Further more, I scanned https://garage.netty.io/teamcity/, but it does seem not build for Windows at all.

Am ideas?

SSL set mode support

Hi,

Do you plan to support SSL_CTX_set_mode operation? In some cases enabling SSL_MODE_ENABLE_PARTIAL_WRITE and SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER modes is necessary but as you pointed out in #81 SSLExt is not supported and there is not any other way to set them.

https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html

UnsatisfiedLinkError org.apache.tomcat.jni.SSLExt.sslCtxSetMode(JJ)J

I was trying to enable SSL_MODE_RELEASE_BUFFERS mode on my context pointer, in order to reduce memory usage of my application.

This is done by:

(SSLExt/sslCtxSetMode (.sslCtxPointer context) SSLExt/SSL_MODE_RELEASE_BUFFERS)

However, I am always getting error:

UnsatisfiedLinkError org.apache.tomcat.jni.SSLExt.sslCtxSetMode(JJ)J  org.apache.tomcat.jni.SSLExt.sslCtxSetMode (SSLExt.java:-2)

This has been tested on Ubuntu with self-compiled openssl 1.0.1p and 1.0.2d, and ArchLinux with latest 1.0.2d.

The ldd result on my ubuntu box:

    linux-vdso.so.1 =>  (0x00007fffc8ebf000)
    libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007fa17e5c2000)
    libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007fa17e1e7000)
    libapr-1.so.0 => /usr/lib/x86_64-linux-gnu/libapr-1.so.0 (0x00007fa17dfb5000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa17dd98000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa17d9d8000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa17d7d3000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fa17d5bc000)
    libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fa17d3b7000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa17ea56000)

and my archlinux

    linux-vdso.so.1 (0x00007ffc2e9dd000)
    libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007fc6c5291000)
    libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007fc6c4e1a000)
    libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0x00007fc6c4be5000)
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fc6c49c7000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007fc6c4623000)
    libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fc6c441f000)
    libz.so.1 => /usr/lib/libz.so.1 (0x00007fc6c4208000)
    libuuid.so.1 => /usr/lib/libuuid.so.1 (0x00007fc6c4003000)
    librt.so.1 => /usr/lib/librt.so.1 (0x00007fc6c3dfb000)
    libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x00007fc6c3bc2000)
    /usr/lib64/ld-linux-x86-64.so.2 (0x0000555797123000)

Just got no idea about this issue, so any question/help is welcomed. Thanks!

Methods do not exist in BoringSSL

PKCS12_verify_mac (sslcontext.c)
CONF_modules_unload (ssl.c)

Compiling statically linked boring profile requires fPIC to be set in environment

Not a bug deal but I had to do

export CFLAGS=-fPIC

to get the profile to work correctly

Review usage of malloc

We should review the usage of malloc and if we check if allocation failed.

CentOS 6 / Amazon Linux openSSL trouble with pre-packaged netty-tcnative

Seems related to #46 / #44... anyhow, we're getting:

java.lang.UnsatisfiedLinkError: /tmp/libnetty-tcnative3858998603798039886.so: libssl.so.1.0.0: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method) ~[na:1.8.0_20]
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929) ~[na:1.8.0_20]
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1814) ~[na:1.8.0_20]
        at java.lang.Runtime.load0(Runtime.java:809) ~[na:1.8.0_20]
        at java.lang.System.load(System.java:1083) ~[na:1.8.0_20]
        at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:193) ~[netty-common-4.1.0.Beta8.jar:4.1.0.Beta8]
        at io.netty.handler.ssl.OpenSsl.<clinit>(OpenSsl.java:58) ~[netty-handler-4.1.0.Beta8.jar:4.1.0.Beta8]
        ... 54 common frames omitted

with 1.1.33 Fork 9 and 1.1.33 Fork 10.

It seems fork 6 used to work well.

1.1.33.Fork15 is not in maven central repository

Hello. Documentation points to 1.1.33.Fork15 but it is not available in maven central.

Could you please advise which version I could use for 4.0.35.Final netty?

Add the binding for SSL_CIPHER_get_version() and other related OpenSSL API

netty/netty@2056aed#diff-6ba8edb6d8a5a127eba9cf97911c6f14R664

Currently, there's no way to get the detailed information about a cipher suite.

Statically link APR when building BoringSSL profile

@Scottmitch I'm assigning to you for now, since you mentioned you'd take a look.

EpollChannelOption.TCP_QUICKACK is set as an Integer

Hello,

Why EpollChannelOption.TCP_QUICKACK is an Integer option ?
In the code, it seems to me that it should be a Boolean, as can be seen in EpollSocketChannelConfig#getOption(ChannelOption), L.105.

Cheers,

Frédéric.

NPN/ALPN protocol selection preference reversed

The selection preference for the ALPN/NPN protocol negotiation process done by selectProtocols should be select the first local "supported" protocols that the peer advertises per alpn spec and npn tech spec - Protocol Negotiation Section. The iteration order is currently reversed.

Boring SSL library has disabled stackguard

Get the following warning when VM (Oracle 7 64 bit) starts

Java HotSpot(TM) 64-Bit Server VM warning: You have loaded library /tmp/libnetty-tcnative9180597608360647425.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c ', or link it with '-z noexecstack'.

sslcontext.c load_pem_key method looping

The load_pem_key method in sslcontext.c has a loop to call PEM_read_bio_PrivateKey 3 times (or until success). Why is this loop necessary, and why 3 iterations? We should at least clarify this situation with comments.

Build depends on non-existent src.zip

My build of netty-tcnative fails because it tries to download
https://oss.sonatype.org/content/repositories/snapshots/io/netty/netty-tcnative/1.1.32.Fork1-SNAPSHOT/netty-tcnative-1.1.32.Fork1-SNAPSHOT-native-src.zip

which is a 404 (I guess you have it cached or it is in some other repo?).

(I do not know if it would succeed on Solaris, but I can't even find out...)

This in turn causes netty issue 2668 and my netty build fails.

And that in turn causes my build of Scamper to fail because Jenkins local repo contains a mix of downloaded and locally built JARs.

I think if netty-tcnative gets fixed, the rest of the problems will solve themselves. Anything we can do here?

Analyze warnings

A recent discovery (#68 (diff)) has brought up a passing an invalid pointer type is flagged as a warning and still compiles. It turned out this pointer was not used in the method, but if it was undefined results would have followed. We should analyze warnings, and consider turning some (all?) warning into errors to ensure code quality.

Build static libraries on windows

we need to get at least boringssl-static building on windows, but it would be nice to get all variants building on mac, linux, and windows.

Support Debian

For gRPC, we're interested in encouraging users to use tcnative instead of jetty-apln. This would work pretty well, except that lots of our users would be Debian/Ubuntu users. Having a pre-built binary for Debian is a prerequisite for us encouraging our users to use tcnative.

We would have little problem making our own builds of tcnative, but it seems that solving the "Debian vs Red Hat" problem would help tcnative in general.

The main problem I see is what to specify as the classifier for any Debian binary. The OS detector doesn't vary based on RHEL/Debian. We could just add "-debian" to the end and force users to hard-code when they are running on Debian. Not great, but better than nothing.

If combined with #24, we could solve it more cleanly as both variants of the Linux .so could be included in the JAR.

Missing OSGi header Bundle-NativeCode in netty-tcnative

From @fsiegrist netty/netty#5150:

The MANIFEST.MF of netty-tcnative-1.1.33.Fork15-[os-classifier].jar does not contain the Bundle-NativeCode header. Thus when running in an OSGi context (e.g. apache-felix), the bundle does not know the path to its native library (META-INF/native/...). As a result, the NativeLibraryLoader (in netty-common) cannot load the native library, because the call to loader.getResource("META-INF/native/lib" + name + ".jnilib") returns null.

After having manually added the following entry to the MANIFEST.MF (of the osx specific version of the netty-tcnative jar), the resource can be found:
Bundle-NativeCode: META-INF/native/libnetty-tcnative.jnilib;osname=macosx; processor=x86; processor=x86_64

Migrate BoringSSL build to MSVC 2015

@nmittler asked me to file a bug here when we were ready to switch BoringSSL's MSVC version. BoringSSL tracks Chromium's MSVC version which has since switched to MSVC 2015. It should currently build with either, but I'll be switching our bots to 2015 soonish and it'll likely (accidentally or intentionally) break with 2013 when we're no longer regularly testing against it.

Document system requirements

I'm really excited about the statically-linked packages that have just gone out, and also what might come out of #113. I've been trying to figure out whether I can use statically-linked tcnative across the board for a project, and am realizing that some information about system requirements is a little tricky to come by. As recently as ca90f9e, it's not immediately obvious from the README which operating systems/JDKs are supported by netty-tcnative. Some questions I had that didn't have immediate answers:

• What versions of Java are supported? (I understand this to be Java 7+)
  • Which JDKs are supported? All? Just Oracle?
• Which operating systems are supported?
  • Looks like Linux (all?), OS X, and Windows.
  • What about non-Linux flavors of Unix?
  • It looks like there isn't support for ARM-based Linux; is that accurate?
• For the dynamically-linked versions, are specific versions of the native SSL providers required?

Thanks!

Detect correct JNI library at runtime instead of build time

Rather than try to detect the OS at build time to determine which JNI library to place in META-INF/native, it would be better to package all of them and then let the NativeResourceLoader detect the OS/arch at runtime in order to load the appropriate library.

Detecting at build time is problematic because the build machine may not share the same OS/arch as the production environment. Also, this allows one artifact to be shared across multiple architectures.

What do you think?

readFromSSL Missing from JNI native library on osx?

Hello,

I am encountering this error:
Caused by: java.lang.AbstractMethodError: null
at org.apache.tomcat.jni.SSL.readFromSSL(Native Method) ~[netty-tcnative-1.1.33.Fork14-osx-x86_64.jar:1.1.33.Fork14]
at io.netty.handler.ssl.OpenSslEngine.readPlaintextData(OpenSslEngine.java:358) ~[netty-all-4.1.0.CR2.jar:4.1.0.CR2]
at io.netty.handler.ssl.OpenSslEngine.unwrap(OpenSslEngine.java:703) ~[netty-all-4.1.0.CR2.jar:4.1.0.CR2]
at io.netty.handler.ssl.OpenSslEngine.unwrap(OpenSslEngine.java:809) ~[netty-all-4.1.0.CR2.jar:4.1.0.CR2]
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1092) ~[netty-all-4.1.0.CR2.jar:4.1.0.CR2]

I am not sure exactly what it means, so any help is appreciated.

Use of tcnative UNREFERENCED macros

We should investigate what the purpose/value of the UNREFERENCED and UNREFERENCED_STDARGS macros are. We should clarify with comments what their purpose are if they are necessary. We should also consistently use them w.r.t to function pre-condition checks. For example some times we call UNREFERENCED before a precondition check and return, and sometime we only call it if the preconditions are satisfied.

NoClassDefFoundError when building tcnative on Ubuntu

Hi,

I was following instructions from wiki

sudo apt-get install autoconf automake libtool make tar libapr1-dev libssl-dev
git clone https://github.com/netty/netty-tcnative.git
cd netty-tcnative
git checkout netty-tcnative-1.1.32.Fork1
mvn clean install

And getting :

[INFO] os.detected.name: linux
[INFO] os.detected.arch: x86_64
[INFO] os.detected.classifier: linux-x86_64


Exception in thread "main" java.lang.NoClassDefFoundError: org/eclipse/aether/RepositorySystemSession
    at kr.motd.maven.os.DetectExtension.injectSession(DetectExtension.java:115)
    at kr.motd.maven.os.DetectExtension.afterProjectsRead(DetectExtension.java:92)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.lang.ClassNotFoundException: org.eclipse.aether.RepositorySystemSession
    at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
    ... 15 more

Static Library Cleaning and Rebuilding

Are the builds for the static libraries "cleaned" every time? It seems the following commands will run through 2 complete builds of the static libraries:

mvn clean install
mvn install

Is it possible to avoid "cleaning" everything and "rebuilding" every time?

Unable to use pre-built binaries on alpine linux

I am trying to use the netty-tcnative libraries for my grpc application in a docker container. When i use the prebuilt binary I get the following error:

Inconsistency detected by ld.so: dl-lookup.c: 128: check_match: Assertion `version->filename == ((void *)0) || ! _dl_name_match_p (version->filename, map)' failed!

OpenSSL versioning issues

Hi,

I was trying to use netty-tcnative for openssl functionality.
On my dev machine ubuntu 14.04 x86_64. I have libssl1.0.0-1.0.1f installed and softlinked to /lib/x86_64-linux-gnu/libssl.so.1.0.0 to /lib/x86_64-linux-gnu/libssl.so.10

I faced around symbol issues with openssl. here is lddoutput from so file.

ldd ~/Downloads/libnetty-tcnative.so 
/home/paggarwal/Downloads/libnetty-tcnative.so: /lib/x86_64-linux-gnu/libssl.so.10: version `libssl.so.10' not found (required by /home/paggarwal/Downloads/libnetty-tcnative.so)
/home/paggarwal/Downloads/libnetty-tcnative.so: /lib/x86_64-linux-gnu/libcrypto.so.10: version `OPENSSL_1.0.1_EC' not found (required by /home/paggarwal/Downloads/libnetty-tcnative.so)
/home/paggarwal/Downloads/libnetty-tcnative.so: /lib/x86_64-linux-gnu/libcrypto.so.10: version `libcrypto.so.10' not found (required by /home/paggarwal/Downloads/libnetty-tcnative.so)
    linux-vdso.so.1 =>  (0x00007ffd074fb000)
    libssl.so.10 => /lib/x86_64-linux-gnu/libssl.so.10 (0x00007fe296160000)
    libcrypto.so.10 => /lib/x86_64-linux-gnu/libcrypto.so.10 (0x00007fe295d85000)
    libapr-1.so.0 => /usr/lib/x86_64-linux-gnu/libapr-1.so.0 (0x00007fe295b53000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe295935000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe295570000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe29536b000)
    libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fe295166000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe29660d000)

When I built netty-tcnative locally then I was able to use it.
here is another ldd output

    linux-vdso.so.1 =>  (0x00007ffe6cbf1000)
    libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f7e41012000)
    libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f7e40c37000)
    libapr-1.so.0 => /usr/lib/x86_64-linux-gnu/libapr-1.so.0 (0x00007f7e40a05000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7e407e7000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7e40422000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7e4021d000)
    libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f7e40018000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f7e414c0000)

For further debugging I took a look at output of objdump -p of local so file and so file downloaded via maven.

local

.
.
Version References:
  required from libpthread.so.0:
    0x09691a75 0x00 06 GLIBC_2.2.5
  required from libc.so.6:
    0x06969194 0x00 10 GLIBC_2.14
    0x0d696914 0x00 09 GLIBC_2.4
    0x09691974 0x00 08 GLIBC_2.3.4
    0x0d696917 0x00 07 GLIBC_2.7
    0x09691a75 0x00 04 GLIBC_2.2.5
  required from libcrypto.so.1.0.0:
    0x066a2b20 0x00 03 OPENSSL_1.0.0
  required from libssl.so.1.0.0:
    0x066a2b20 0x00 05 OPENSSL_1.0.0
    0x066a2b21 0x00 02 OPENSSL_1.0.1

from mavencentral

.
.
.
.
Version References:
  required from libpthread.so.0:
    0x09691a75 0x00 05 GLIBC_2.2.5
  required from libc.so.6:
    0x0d696917 0x00 06 GLIBC_2.7
    0x09691a75 0x00 04 GLIBC_2.2.5
  required from libssl.so.10:
    0x0a779bd0 0x00 03 libssl.so.10
  required from libcrypto.so.10:
    0x02b21533 0x00 08 OPENSSL_1.0.1_EC
    0x066a2b21 0x00 07 OPENSSL_1.0.1
    0x0af47420 0x00 02 libcrypto.so.10

Following dependency versions seems to be the cause of issue. any way to strip them from the build?

0x02b21533 0x00 08 OPENSSL_1.0.1_EC
0x0af47420 0x00 02 libcrypto.so.10
0x0a779bd0 0x00 03 libssl.so.10

Non standard project layout

Since we have started supporting the static library builds the directory structure is no longer following the standard maven directory structure. This can make discovery and IDE interop more difficult. Is it possible to put the java/c code back to the "top" level so maven can correctly generate IDE project files?

OpenSSL version detection broken

Calling OpenSsl.version() seems to result in the version that it was compiled against. I tried building openssl and setting LD_LIBRARY_PATH, but it kept returning the same version (1.1.33.Fork6 seems to be built against 1.0.1e). The logic for OpenSsl.isAlpnSupported() is based on version, so if it's broken, ALPN support is broken as well.

It seems that tc_native is using a macro to get the value:

netty-tcnative/src/main/c/ssl.c

Line 273 in be811ae

return OPENSSL_VERSION_NUMBER;

. I tried switching to using methods:

// From my local ssl.c...
TCN_IMPLEMENT_CALL(jint, SSL, version)(TCN_STDARGS)
{
    UNREFERENCED_STDARGS;
    fprintf(stderr, "NM: in new code");
    return (jint) SSLeay();
}

TCN_IMPLEMENT_CALL(jstring, SSL, versionString)(TCN_STDARGS)
{
    UNREFERENCED(o);
    fprintf(stderr, "NM: in new code");
    return AJP_TO_JSTRING(SSLeay_version(SSLEAY_VERSION));
}

However I still see the same problem. I had considered that the method may have been inlined, but it appears that the definition is in a c file (https://github.com/openssl/openssl/blob/6218a1f57e7e25a6b9a798f00cf5f0e56a02ff31/crypto/cversion.c#L104), so that should work.

Any ideas?

@Scottmitch @normanmaurer

Docs give example for non-existent uber-jar

Following up on netty/netty#5052, the wiki gives instructions for using an uber jar with fork15, but there won't be an uber jar until fork16.

Remove unused code

I would like to propose removing all code that we not need for netty (like Socket, Multicast and many more). We are only interested in the parts that are needed for our OpenSslEngine anyway. This will help us to focus on things we care about and not ship things that we are not using.

@nmittler @Scottmitch @trustin WDYT ?

SSLPeerUnverifiedException: peer not verified when using OpenSSL provider

Don't know if this is netty or netty-tcnative related: netty/netty#4722

Consider merging with Android Conscrypt

@normanmaurer
@gregw (for Jetty)
@kruton (for Conscrypt)

Conscrypt is an Apache 2 Licensed JSSE provider built on top of boringssl that has been developed by the Android team. It has had a non-trivial amount of tire-kicking and is used with OpenJDK on the server side at Google.

Merging efforts here would offer some major upside to the Java development community.

https://android.googlesource.com/platform/external/conscrypt/+/master

Even if they don't merge, having a solid alternative JSSE provider easily available would benefit lots of folks

tomcat-native 1.1.33

http://tomcat.apache.org/native-doc/news/2015.html#20150323.1

Build process fails detecting openssl on OS X (El Capitan)

[INFO] libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I./src -I/usr/local/opt/openssl/include -I/usr/local/opt/openssl/include/openssl -I/usr/local/opt/openssl/include -O3 -Werror -I/usr/include/apr-1 -D_LARGEFILE64_SOURCE -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include/darwin -c src/pool.c  -fno-common -DPIC -o src/.libs/pool.o
[INFO] /bin/sh ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I./src   -I/usr/local/opt/openssl/include -I/usr/local/opt/openssl/include/openssl -I/usr/local/opt/openssl/include   -O3 -Werror   -I/usr/include/apr-1  -D_LARGEFILE64_SOURCE -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include/darwin -c -o src/proc.lo src/proc.c
[INFO] libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I./src -I/usr/local/opt/openssl/include -I/usr/local/opt/openssl/include/openssl -I/usr/local/opt/openssl/include -O3 -Werror -I/usr/include/apr-1 -D_LARGEFILE64_SOURCE -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include/darwin -c src/proc.c  -fno-common -DPIC -o src/.libs/proc.o
[INFO] /bin/sh ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I./src   -I/usr/local/opt/openssl/include -I/usr/local/opt/openssl/include/openssl -I/usr/local/opt/openssl/include   -O3 -Werror   -I/usr/include/apr-1  -D_LARGEFILE64_SOURCE -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include/darwin -c -o src/shm.lo src/shm.c
[INFO] libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I./src -I/usr/local/opt/openssl/include -I/usr/local/opt/openssl/include/openssl -I/usr/local/opt/openssl/include -O3 -Werror -I/usr/include/apr-1 -D_LARGEFILE64_SOURCE -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include/darwin -c src/shm.c  -fno-common -DPIC -o src/.libs/shm.o
[INFO] /bin/sh ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I./src   -I/usr/local/opt/openssl/include -I/usr/local/opt/openssl/include/openssl -I/usr/local/opt/openssl/include   -O3 -Werror   -I/usr/include/apr-1  -D_LARGEFILE64_SOURCE -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include/darwin -c -o src/ssl.lo src/ssl.c
[INFO] libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I./src -I/usr/local/opt/openssl/include -I/usr/local/opt/openssl/include/openssl -I/usr/local/opt/openssl/include -O3 -Werror -I/usr/include/apr-1 -D_LARGEFILE64_SOURCE -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include/darwin -c src/ssl.c  -fno-common -DPIC -o src/.libs/ssl.o
[INFO] src/ssl.c:2085:2: error: OpenSSL is required!
[INFO] #error OpenSSL is required!
[INFO]  ^
[INFO] 1 error generated.
[INFO] make: *** [src/ssl.lo] Error 1
[INFO] rc: 2
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Netty/TomcatNative [Parent] ........................ SUCCESS [  3.078 s]
[INFO] Netty/TomcatNative [OpenSSL - Dynamic] ............. FAILURE [ 25.502 s]
[INFO] Netty/TomcatNative [OpenSSL - Static] .............. SKIPPED
[INFO] Netty/TomcatNative [BoringSSL - Static] ............ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 28.886 s
[INFO] Finished at: 2016-04-04T14:22:18-04:00
[INFO] Final Memory: 19M/298M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.fusesource.hawtjni:maven-hawtjni-plugin:1.11:build (build-native-lib) on project netty-tcnative: build failed: org.apache.maven.plugin.MojoExecutionException: make based build failed with exit code: 2 -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :netty-tcnative

$ env | grep C*FLAGS
LDFLAGS=-L/usr/local/opt/openssl/lib
CPPFLAGS=-I/usr/local/opt/openssl/include

$ brew install openssl
Warning: openssl-1.0.2g already installed

netty-4.0.35.Final breaks ssl < TLSv1.2 when used w/ netty-tcnative >= 1.1.33.Fork13

In the transition from 1.1.33.Fork12 to 1.1.33.Fork13, the native implementation of SSLContext.make in sslcontext.c was restructured to use a switch statement, rather than a series of if .. else if statements. In the process, the default case when not finding an exact match for protocol changed from SSLv23_method to TLSv1_2_method.

This is coupled with the fact that netty-4.0.35.Final was compiled against netty-tcnative-1.1.33.Fork11 means that protocol will not be correct by default. The value in Fork11 was 28 (SSL_PROTOCOL_TLSV1 | SSL_PROTOCOL_TLSV1_1 | SSL_PROTOCOL_TLSV1_2), and this is compiled into the .class file for OpenSslContext in netty-all.

Unfortunately, this is not the correct value, and with the restructuring to a switch statement, this value doesn't match any particular case and falls through to the new default: TLSv1_2_method. Client versions < TLSv1.2 then stop working, because the server no longer supports them.

Static Library Build Phase

Just initializing the project files for the IDE mvn eclipse:eclipse seems to build all of the static libraries. Is this necessary just for setting up the IDE project files (building the static libraries can take some time).

Update build and usage instructions

Given recent refactoring into multi-modules and added support for linking statically to OpenSSL libraries, we need to update the docs on the wiki for building netty-tcnative.

Some things that should be made clear (from #115):

• The versions of Java are supported?
• Which JDKs are supported? All? Just Oracle?
• Which OS/arch are supported?
• For the dynamically-linked versions, are specific versions of the native SSL providers required?

Init constants via JNI

We may want to consider init the constants via a JNI call so we are sure these are correct.
#71 (comment)

strange names of loaded native libraries

hi! I'm wondering why netty-tcnative is laoding normal tomcat libraries, and not the library it is building.

The patch to fix it is:

# this patch is suspicious
# why netty-tcnative is building its own .so library, and still loading tomcat's one?

--- netty-tcnative-netty-tcnative-1.1.30.Fork2/src/main/java/org/apache/tomcat/jni/Library.java
+++ netty-tcnative-netty-tcnative-1.1.30.Fork2/src/main/java/org/apache/tomcat/jni/Library.java
@@ -24,7 +24,7 @@
 public final class Library {

     /* Default library names */
-    private static final String [] NAMES = {"tcnative-1", "libtcnative-1"};
+    private static final String [] NAMES = {"netty-tcnative", "libnetty-tcnative", "netty-tcnative-1", "libnetty-tcnative-1"};
     /*
      * A handle to the unique Library singleton instance.
      */

Or remove native sources and build from the fork.

Thank you!

tcn_ssl_ctxt_t->cb_data null checks and tcn_password_callback

It is common practice whenever tcn_ssl_ctxt_t->cb_data is used to check for NULL, and if NULL to then use a temporary variable which is set to tcn_password_callback. It seems like tcn_ssl_ctxt_t->cb_data should be set in sslcontext.c's make method by the SSL_CTX_set_default_passwd_cb_userdata method. Are these NULL checks and temporary variables necessary?

BoringSSL does not support des_read_pw_string

Currently, sslutils.c has the following code:

#ifdef WIN32
        rv = WIN32_SSL_password_prompt(data);
#elif !defined(OPENSSL_IS_BORINGSSL)
        EVP_read_pw_string(data->password, SSL_MAX_PASSWORD_LEN,
                           data->prompt, 0);
#else
        des_read_pw_string(data->password, SSL_MAX_PASSWORD_LEN,
                           data->prompt, 0);
#endif

This would have des_read_pw_string called in the BoringSSL case, which does not exist. I suspect that this builds for some developers because the include may be getting pulled in from openssl. Not entirely sure.

Build issue on 32-bit Linux

From @junjiemars:

@trustin I resolved the issue: io.netty:netty-tcnative:jar:linux-x86_32:1.1.32.Fork1 can not be found on 32-bit Linux,

1. git clone netty-tcnative.git
2. run mvn -X compile, it will be failed on 32-bit Linux
3. found the Makefile under the ./target/native-build, insert -DLARGEFILE64_SOURCE into CFLAGS section nearly 262 line
4. comment 2 <forceAutogen .../> and <forceConfigure .../> sections in pom.xml
5. run mvn -X install to install io.netty:netty-tcnative:jar:linux-x86_32:1.1.32.Fork1 into local repository
6. now, io.netty:netty-tcnative:jar:linux-x86_32:1.1.32.Fork1 can be found by maven, done.

Seems like the user experienced a build problem when building on 32-bit Linux

1.1.33.Fork4+: Unable to load openssl on OS X (Homebrew installed openssl)

java.lang.UnsatisfiedLinkError: /private/var/folders/5f/jc_d179x0qlbhm0kzxlssyl00000gn/T/libnetty-tcnative4749163000461898953.dylib: dlopen(/private/var/folders/5f/jc_d179x0qlbhm0kzxlssyl00000gn/T/libnetty-tcnative4749163000461898953.dylib, 1): Library not loaded: /usr/local/lib/libssl.1.0.0.dylib
  Referenced from: /private/var/folders/5f/jc_d179x0qlbhm0kzxlssyl00000gn/T/libnetty-tcnative4749163000461898953.dylib
  Reason: image not found
    at java.lang.ClassLoader$NativeLibrary.load(Native Method) ~[na:1.8.0_45]
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) ~[na:1.8.0_45]
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1822) ~[na:1.8.0_45]
    at java.lang.Runtime.load0(Runtime.java:809) ~[na:1.8.0_45]
    at java.lang.System.load(System.java:1086) ~[na:1.8.0_45]
    at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:193) ~[netty-all-4.1.0.Beta6-20150726.163256-175.jar:4.1.0.Beta6-SNAPSHOT]
    at io.netty.handler.ssl.OpenSsl.<clinit>(OpenSsl.java:58) ~[netty-all-4.1.0.Beta6-20150726.163256-175.jar:4.1.0.Beta6-SNAPSHOT]

When using 1.1.33.Fork3 with netty 4.1.0.Beta6-SNAPSHOT on OS X. there is no exception thrown.

openssl version: 1.0.2d_1 (installed by homebrew)
openssl path: /usr/local/opt/openssl/lib

Linux .so for boring isn't stripped

This is effectively a repeat of #45, but for boring and MB involved instead of KB. OS X's native library is 1.9 MB uncompressed, whereas Linux's is 7.1 MB. Running strip on the Linux .so reduces its size to 1.9 MB. I think that will change the compressed size from 2.5 MB to ~900 KB.

Linux .so isn't stripped

netty-tcnative-1.1.33.Fork2-linux-x86_64.jar is 422.7K, whereas osx-x86_64 and windows-x86_64 are ~125K.

libnetty-tcnative.so is actually 996K in size. Stripping it reduced it to 163K and the JAR itself to 129K.