Re: [DISCUSS] Streamline return value from RemoteQuery

[Jacob Barrett]

Oh wouldn’t it be nice if it was asynchronous... :(

> On Aug 14, 2018, at 8:56 PM, David Kimura  wrote:
> 
> 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 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 similar in behavior.
>> 
>> -Jake
>> 
>> 
>>> On Aug 14, 2018, at 11:01 AM, Dan Smith  wrote:
>>> 
>>> +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 separate query::executeXXX method for each type.
>>> But I think just returning StructSet seems reasonable.
>>> 
>>> The Java API for query is even worse. I think the Java API actually
>> returns
>>> an Object, which the user has to cast into one of three things - an
>>> individual value, SelectResult of values, or a SelectResults of structs.
>> We
>>> should fix that too!
>>> 
>>> -Dan
>>> 
>>> On Tue, Aug 14, 2018 at 10:47 AM, Anilkumar Gingade >> 
>>> wrote:
>>> 
 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 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 <
>> eburgha...@pivotal.io
> 
> wrote:
> 
>> Currently, geode-native's query::execute returns a
>> shared_ptr and
>> that pointer can be either ResultSet or StructSet.
>> 
>> 
>> RemoteQuery::execute contains logical code to determine with
 QueryResults
>> are greater than 0... We should look at removing this logic and only
>> returning StructSets
>> This allows removal of ResultSet which will streamline the API and
>> associated code...
>> 
>> This duality is unnecessary and should be removed.
>> I am proposing that the results only return  StructSet
>> 
>> Best,
>> EB
>> 
> 
 
>> 

Geode Summit 2018 coming up on Sept 24th - register now

[Jagdish Mirani]

Hello Geode enthusiasts:

The next Geode Summit is a bit more than a month away, this September 24th,
in Washington D.C. This year’s agenda is even larger and more comprehensive
than last year --- showcasing the latest Geode case studies and tech
features.

The Geode community has been busy. During the last 9 months since our last
summit, the Geode project has had 3 releases, 55 contributors, 1300 code
commits and the resolution of over 1400 JIRA tickets. For 2017, Geode was
the fifth most active mailing list
. These are good indicators
of the brisk and sustained pace of the project.

Please note that *Geode sessions start on Monday, Sept 24th*, a day before
the opening of the SpringOne Platform
 main conference. You'll be
able to add Geode sessions to your online schedule maker once the
conference app is available nearing the start of the conference.

We’re eager to see you at this year’s Apache Geode Summit. See the full
agenda and listing here  of
Geode sessions at the conference. You can register for the conference here
. Use
special discount code Attendee_Geode_100
 for $100 off the price of
your SpringOne Platform conference pass!

We look forward to seeing you in September!
-- 
Regards
Jag

Re: [DISCUSS] Streamline return value from RemoteQuery

[Blake Bender]

+1 for always returning StructSet.  Just this change would have pretty
minimal impact.  We took a slightly more in-depth look at the code, and it
doesn't look like there's anything preventing us from converting most of
this stuff to standard library code.  StructSet could be replaced with
std::map >, and client developers
really wouldn't lose anything of value in the process.

On Wed, Aug 15, 2018 at 5:25 AM Jacob Barrett  wrote:

> Oh wouldn’t it be nice if it was asynchronous... :(
>
> > On Aug 14, 2018, at 8:56 PM, David Kimura  wrote:
> >
> > 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 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 similar in behavior.
> >>
> >> -Jake
> >>
> >>
> >>> On Aug 14, 2018, at 11:01 AM, Dan Smith  wrote:
> >>>
> >>> +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 separate query::executeXXX method for each
> type.
> >>> But I think just returning StructSet seems reasonable.
> >>>
> >>> The Java API for query is even worse. I think the Java API actually
> >> returns
> >>> an Object, which the user has to cast into one of three things - an
> >>> individual value, SelectResult of values, or a SelectResults of
> structs.
> >> We
> >>> should fix that too!
> >>>
> >>> -Dan
> >>>
> >>> On Tue, Aug 14, 2018 at 10:47 AM, Anilkumar Gingade <
> aging...@pivotal.io
> >>>
> >>> wrote:
> >>>
>  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 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 <
> >> eburgha...@pivotal.io
> >
> > wrote:
> >
> >> Currently, geode-native's query::execute returns a
> >> shared_ptr and
> >> that pointer can be either ResultSet or StructSet.
> >>
> >>
> >> RemoteQuery::execute contains logical code to determine with
>  QueryResults
> >> are greater than 0... We should look at removing this logic and only
> >> returning StructSets
> >> This allows removal of ResultSet which will streamline the API and
> >> associated code...
> >>
> >> This duality is unnecessary and should be removed.
> >> I am proposing that the results only return  StructSet
> >>
> >> Best,
> >> EB
> >>
> >
> 
> >>
>

Re: [DISCUSS] Streamline return value from RemoteQuery

[David Kimura]

On Wed, Aug 15, 2018 at 5:24 AM, Jacob Barrett  wrote:

> Oh wouldn’t it be nice if it was asynchronous... :(


"Hold my beer"  :P

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #1010 was SUCCESSFUL (with 2423 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #1010 was successful.
---
Scheduled
2425 tests in total.

https://build.spring.io/browse/SGF-NAG-1010/





--
This message is automatically generated by Atlassian Bamboo

Re: [Proposal] SSL - hostname verification

[Jacob Barrett]

On Tue, Aug 14, 2018 at 10:22 AM Dan Smith  wrote:

> >
> > 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
> than directly trusting their gemfire servers. If you are using a public CA
> model of trust, then you need hostname verification.


1) Compromise any host, client or server, in the cluster.
2) Copy key and certificate.
3) Hide tracks.
4) Create rouge host using stolen key and certificate pair.
 - Lack or hostname validation means my host with an otherwise valid
cert can join the cluster.
5) Profit.

While strictly not a CA trust man-in-the-middle, it has the same effect. It
is an attack vector that hostname verification thwarts that current
implementation does not.

-Jake

Re: [Proposal] SSL - hostname verification

[Sai Boorlagadda]

I agree that hostname verification is independent of supporting default
context and I like Dan's suggestion of making hostname validation is
enabled by default if the user wants to use default SSL context otherwise
can be enabled using 'ssl-enable-endpoint-identification'.

Here is what the behavior going forward:

1) Decide whether you want SSL? Enabled using 'ssl-enabled-components'
2) Great. Do you want to use
 2.a) default ssl context? (using ssl-use-default-context)
 2.b) configure ssl context with specific trust and key store types,
locations, passwords (using ssl-key* and ssl-trust*)
3) In any case (2.a or 2.b) you have an option to restrict SSL protocols
and ciphers (using ssl-protocols, ssl-ciphers)
4) In any case (2.a or 2.b) you have an option to enable mutual auth (using
ssl-require-auth)

For 2.a, hostname validation is enabled by default.
For 2.b, user has a choice to enable using
'ssl-enabled-endpoint-identification'. We default this to false with a
warning and make it true in 2.0

The only simplification I see is making 2.a a default behavior when SSL is
configured and user does not specify ssl-key* and ssl-trust* parameters.
But as this will break backward compatibility as we default
{user-home}/.keystore, so the need for 2.a.

Sai

On Wed, Aug 15, 2018 at 8:58 PM Jacob Barrett  wrote:

> On Tue, Aug 14, 2018 at 10:22 AM Dan Smith  wrote:
>
> > >
> > > 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
> > than directly trusting their gemfire servers. If you are using a public
> CA
> > model of trust, then you need hostname verification.
>
>
> 1) Compromise any host, client or server, in the cluster.
> 2) Copy key and certificate.
> 3) Hide tracks.
> 4) Create rouge host using stolen key and certificate pair.
>  - Lack or hostname validation means my host with an otherwise valid
> cert can join the cluster.
> 5) Profit.
>
> While strictly not a CA trust man-in-the-middle, it has the same effect. It
> is an attack vector that hostname verification thwarts that current
> implementation does not.
>
> -Jake
>