Re: [DISCUSS] Streamline return value from RemoteQuery

If this is a non-blocking function (and maybe even if it isn't), then it might be worth considering a future/promise contract. Perhaps something like folly which provides a very rich interface. Thanks, David On Tue, Aug 14, 2018 at 12:57 PM, Jacob Barrett wrote: > If we are going to change

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #1009 was SUCCESSFUL (with 2423 tests). Change made by John Blum.

--- Spring Data GemFire > Nightly-ApacheGeode > #1009 was successful. --- Scheduled with changes by John Blum. 2425 tests in total.

Re: [Proposal] SSL - hostname verification

Bruce, > To which SSL connections would this apply? All of them? When enabled, these validations affect any client connecting to ssl enabled component depending on `ssl-enabled-components`. Sai On Tue, Aug 14, 2018 at 11:26 AM Bruce Schuchardt wrote: > Hi Sai > > To which SSL connections

Re: [DISCUSS] Streamline return value from RemoteQuery

If we are going to change it I wonder if we can’t do better or look for some other standard to adopt. For the C++ side could we adopt something that is maybe std::tuple or std::vector based? Tuple probably doesn’t work because it’s fixed at compile time but std::vector and StructSet are very

Re: [Proposal] SSL - hostname verification

Hi Sai To which SSL connections would this apply?  All of them? On 8/14/18 7:46 AM, Sai Boorlagadda wrote: Geode currently does not implement hostname verification and is probably not required per TLS spec. But it can be supported on TLS as an additional check. The new proposed[1]

Re: [DISCUSS] Streamline return value from RemoteQuery

+1 for just having StructSet. Return types should always be strongly typed, the user shouldn't have to introspect or guess based on their query what the return type actually will be at runtime. If we think there is value in having separate ResultSet and StructSet results, we could have a

Re: [DISCUSS] Streamline return value from RemoteQuery

In Java, they are separated so that the results can be managed effectively. For example StructSet has its own implementation to manage the query results that are structs (more than one projection attributes). -Anil On Tue, Aug 14, 2018 at 8:28 AM David Kimura wrote: > I have a couple

Re: [Proposal] SSL - hostname verification

> > The current SSL implementation is also susceptible to man-in-the-middle as > well. This proposal is really independent of those proposed changes. > The current SSL implementation is not susceptible to man-in-the-middle attacks, unless someone configures their client to trust public CAs rather

Re: [Proposal] SSL - hostname verification

+1 for making it default and to warn users before making it a hard requirement. On Tue, Aug 14, 2018 at 10:00 AM Anthony Baker wrote: > What if we require certs to have correct hostnames and automatically > perform hostname verification. No property required. The only counter > argument I can

Re: [Proposal] SSL - hostname verification

>The current SSL implementation is also susceptible to man-in-the-middle as >well. This proposal is really independent of those proposed changes. This proposal is independent of the proposed changes to use default context. In both cases, the risk is similar if keys are compromised. But in the

Re: [Proposal] SSL - hostname verification

I like this suggestion. +1 -- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1-631-835-4771 Download the GemFire book here. On Tue, Aug 14, 2018 at 1:00 PM, Anthony Baker wrote: > What if we require

Re: [Proposal] SSL - hostname verification

What if we require certs to have correct hostnames and automatically perform hostname verification. No property required. The only counter argument I can think of is that this change might require users to regenerate certificates when upgrading. Perhaps we start by logging a warning for N

Re: [Proposal] SSL - hostname verification

On Tue, Aug 14, 2018 at 7:47 AM Sai Boorlagadda wrote: > Geode currently does not implement hostname verification and is probably > not required per TLS spec. But it can be supported on TLS as an additional > check. The new proposed[1] implementation to use the default SSL context > could cause

Re: [DISCUSS] Streamline return value from RemoteQuery

I have a couple questions: Do you have an idea or theories of what was the original intent behind separating ResultSet and StructSet? Is execute a blocking or non-blocking call and does the interface have any guarantee of that? Thanks, David On Mon, Aug 13, 2018 at 4:06 PM, Ernest Burghardt

[Proposal] SSL - hostname verification

Geode currently does not implement hostname verification and is probably not required per TLS spec. But it can be supported on TLS as an additional check. The new proposed[1] implementation to use the default SSL context could cause certain man-in-the-middle attacks possible if there is no