[
https://issues.apache.org/jira/browse/ARROW-10105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208007#comment-17208007
]
James Duong commented on ARROW-10105:
-------------------------------------
Making some progress on this:
* I tested putting in a PEM for tls_roots_pem and see the new tests pass. I can
confirm that it's running the callback I added to skip over cert verification
-- I was actually getting a crash due to [this bug in
gRPC|https://github.com/grpc/grpc/issues/22287] until I wrote a workaround for
it.
* The CentOS 5.11 build errors were from using gRPC 1.29 in build_grpc.sh
scripts. This puts TlsCredentials and related classes in a different namespace
than in 1.32 which is what brew and other environments used. grpc::experimental
is used in 1.32 and grps_impl::experimental is used in older versions.
I'm running into two build problems now:
The first:
Several Ursabot / AMD64 Conda builds are failing. I do not know where they are
getting gRPC from or how they determine the gRPC version to get. eg:
https://ci.ursalabs.org/#/builders/66/builds/11440
The second:
When I switch build_grpc.sh to compile gRPC 1.32, I get build errors building
it on CentOS 5. The first was that it now has a new dependency on RE2, which I
resolved. The second seems to be related to CentOS5 using an older Linux kernel
(https://github.com/apache/arrow/pull/8325/checks?check_run_id=1208358439):
{noformat}
CMakeFiles/grpc_unsecure.dir/src/core/lib/iomgr/socket_utils_common_posix.cc.o
-c src/core/lib/iomgr/socket_utils_common_posix.cc
In file included from /usr/include/asm-x86_64/byteorder.h:30:0,
from /usr/include/asm/byteorder.h:5,
from /usr/include/linux/tcp.h:21,
from src/core/lib/iomgr/socket_utils_common_posix.cc:34:
/usr/include/linux/byteorder/little_endian.h:43:19: error: ‘__le64’ does not
name a type
static __inline__ __le64 __cpu_to_le64p(const __u64 *p)
^
/usr/include/linux/byteorder/little_endian.h:47:46: error: ‘__le64’ does not
name a type
static __inline__ __u64 __le64_to_cpup(const __le64 *p)
^
/usr/include/linux/byteorder/little_endian.h:67:19: error: ‘__be64’ does not
name a type
static __inline__ __be64 __cpu_to_be64p(const __u64 *p)
^
/usr/include/linux/byteorder/little_endian.h:71:46: error: ‘__be64’ does not
name a type
static __inline__ __u64 __be64_to_cpup(const __be64 *p)
{noformat}
I have read about a similar problem in QT where it could be resolved by using
-std=gnu++11 instead of -std=c++11. But we'd have to figure out a way to get
gRPC's build system to do this. What's also odd is that particular class and
the #include of linux/tcp.h have been around since gRPC 1.21. I don't think we
could get away with just using an older gRPC either -- we'll get build issues
due to TlsCredentials being in different namespaces depending on gRPC versions.
I don't see a way to define a macro to identify the namespace to look for
TlsCredentials either -- gRPC has a method to get the version at runtime but
there wasn't an obvious way to get this through the preprocessor.
There are also build failures in MinGW and R that seem to be issues downloading
dependencies.
> [FlightRPC] Add client option to disable certificate validation with TLS
> ------------------------------------------------------------------------
>
> Key: ARROW-10105
> URL: https://issues.apache.org/jira/browse/ARROW-10105
> Project: Apache Arrow
> Issue Type: New Feature
> Components: C++, FlightRPC, Java, Python
> Reporter: James Duong
> Assignee: James Duong
> Priority: Major
> Labels: pull-request-available
> Fix For: 2.0.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Users of Flight may want to disable certificate validation if they want to
> only use encryption. A use case might be that the Flight server uses a
> self-signed certificate and doesn't distribute a certificate for clients to
> use.
> This feature would be to add an explicit option to FlightClient.Builder to
> disable certificate validation. Note that this should not happen implicitly
> if a client uses a TLS location, but does not set a certificate. The client
> should explicitly set this option so that they are fully aware that they are
> making a connection with reduced security.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
