gRPC + SSL = UnsatisfiedLinkError [英] gRPC + SSL = UnsatisfiedLinkError

问题描述

我一直在尝试对我的gRPC服务进行SSL验证(在纯文本模式下可以正常工作).注意:这是在商业环境中限制了我的某些选择(例如开发环境和部署平台).

I've been trying to SSL-ify my gRPC service (which works fine in plaintext mode). Note: this is in a commercial context which limits some of my options (such as development environment & deployment platform).

我遵循了 SECURITY.md ，该指南建议使用OpenSSL ...，因此 netty-tcnative ...导致

I followed SECURITY.md which recommends using OpenSSL ... and therefore netty-tcnative ... which leads to Forked Tomcat Native and a number of choices:

1. netty-tcnative-{arch}-动态链接，要求目标系统上已经安装了APR和OpenSSL
2. netty-tcnative-boringssl-static-{os_arch}-静态链接到APR和Google的OpenSSL fork
3. netty-tcnative-boringssl-static-静态链接的uber jar和通用平台的本地库
4. netty-tcnative-openssl-static-{os_arch}-静态链接到APR和OpenSSL ...但是不在maven Central上，所以不是我的第一选择

1. netty-tcnative-{arch} - dynamically linked, requires APR and OpenSSL already installed on target systems
2. netty-tcnative-boringssl-static-{os_arch} - statically linked to APR and google's OpenSSL fork
3. netty-tcnative-boringssl-static - statically linked uber jar with native libraries for common platforms
4. netty-tcnative-openssl-static-{os_arch} - statically linked to APR and OpenSSL ... but isn't on maven central so not my first choice

#3

医生说#3是最简单的工件. 但是，对我而言，这导致无法找到netty-tcnative.dll(在这种情况下，该文件应该来自jar AFAIK).

#3

The doc says #3 is the simplest artifact to use. But, for me, that results in a failure to find netty-tcnative.dll (which, in this case, should come from the jar AFAIK).

这似乎是下一个最简单的方法. 大概我可以使用 os-maven-plugin 在构建时找出分类器，用于需要一个(即2和4)的这些工件的版本. 尽管可以正确解决这些问题(根据mvn compile输出)，但是我得到了不同的运行时行为:

This looks to be the next simplest. Supposedly I can use os-maven-plugin to figure out, at build time, the classifier to use for the versions of these artifacts that require one (i.e. 2 and 4). Although it correctly works them out (according to mvn compile output), I get different runtime behaviour:

• 使用<classifier>${os.detected.classifier}</classifier>我得到java.lang.ClassNotFoundException: org.apache.tomcat.jni.SSL
• 硬编码为<classifier>windows-x86_64</classifier>我走得更远，但仍然没有雪茄:现在netty-tcnative将无法加载:java.lang.UnsatisfiedLinkError: C:\Temp\netty-tcnative1392766600896877072.dll: Can't find dependent libraries(不寻常的路径，因为DLL已从jar复制到了我的temp目录和System.load从那里
  • 根据依赖行者，该DLL具有一整套依赖关系，其中有些确实没有出现在我的文件系统上.但这似乎是因为 depends.exe与时俱进 .
  • 相同的代码也无法在同事的PC上运行，因此不仅限于我.
  • 我仍然有一个问题，因为我的目标系统是RHEL，而不是Windows(我的Linux工作站王国！).所以我必须弄清楚如何解决${os.detected.filesystem}问题...
  • using <classifier>${os.detected.classifier}</classifier> I get java.lang.ClassNotFoundException: org.apache.tomcat.jni.SSL
  • hard-coding to <classifier>windows-x86_64</classifier> I get further but still no cigar: now netty-tcnative won't load: java.lang.UnsatisfiedLinkError: C:\Temp\netty-tcnative1392766600896877072.dll: Can't find dependent libraries (an unusual path because the DLL's been copied from the jar to my temp directory and System.load'ed from there)
    • According to dependency walker, that DLL has a whole stack of dependencies some of which really don't appear on my filesystem. But it seems that's because depends.exe hasn't kept up with the times.
    • The same code also doesn't work on a colleague's PC so it's not just me.
    • And I still have a problem because my target system is RHEL, not Windows (my kingdom for a Linux workstation!). So I'd have to figure out how to fix the ${os.detected.filesystem} problem...

    我猜这可能有用.但这不是在Maven Central上，所以不是我最喜欢的路径.

    This might work I guess. But it's not on maven central so is not my favoured path.

    可能会起作用.但是，这意味着要在我们部署的任何服务器上安装APR和OpenSSL.我不喜欢使用内部PaaS的机会.暂时避免.

    Probably would work. But means installing APR and OpenSSL on whichever servers we deploy upon. I don't like my chances of that for internal PaaS I have to use. Avoid for now.

    我可能尝试一下. 但是文档强烈建议您反对该文档，因为Java的bootclasspath(我可以在这里想象更多的PaaS障碍，也许没有根据...). 而且它的性能似乎并不过分(比OpenSSL慢10倍以上). 而且它很脆弱(Jetty-ALPN版本必须与使用中的JRE完全一致，尽管听起来可能对此有解决方案.)

    I might try this. But the doc strongly recommends against it as you have to fiddle with Java's bootclasspath (I can imagine more PaaS obstacles here, perhaps unfounded...). And it's apparently not overly performant (>10x slower than OpenSSL). And it's brittle (Jetty-ALPN version must correspond exactly with JRE in use although it sounds like there may be solutions to this).

    如果我不能解决此问题，则可能会杀死我的项目的gRPC.这是否是一件坏事，尚待辩论……与此同时，是否有人有任何想法或可使用SSL认证的gRPC客户端/服务器应用程序(

    If I can't solve this problem, it may kill gRPC for my project. Whether or not that's a bad thing is up for debate... In the meantime, does anyone have any ideas or a working SSL-ified gRPC client/server app (grpc-java/examples all use plaintext only).

    推荐答案

    这绝对是一种与网赚有关的错误.我刚刚创建了 https://github.com/netty/netty-tcnative/issues/ 141 ，并将考虑减少MSVC带来的依赖项列表.

    This is definitely a netty-tcnative bug. I've just created https://github.com/netty/netty-tcnative/issues/141 and will be looking at reducing the list of dependencies brought in by MSVC.

    现在，尝试自己构建openssl [static/dynamic]，看看是否适合您.

    For now, try building openssl[static/dynamic] yourself and see if that works for you.

    这篇关于gRPC + SSL = UnsatisfiedLinkError的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！