Jenkins build is back to normal : Geode-nightly #1289

[Apache Jenkins Server]

See 

[DISCUSS] Streamline return value from RemoteQuery

[Ernest Burghardt]

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

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

[Spring CI]

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

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





--
This message is automatically generated by Atlassian Bamboo

Re: Proposal to support custom java.security.Provider

[Sai Boorlagadda]

Exactly. I would have assumed #2 is bringing in default context if the user
does not specific keystore and truststore. But unfortunately, the current
code loads keystore from "{user.home}/.keystore" and so the proposal for
this new property.
We should probably disable loading from user.home if not specified in 2.0

Sai

On Mon, Aug 13, 2018 at 8:48 AM Jinmei Liao  wrote:

> Doing #2 an #3 alone would fix GEODE-5338, right? We don't really need this
> new option.
>
> On Mon, Aug 13, 2018 at 8:32 AM Sai Boorlagadda  >
> wrote:
>
> > To make it clear about the different options:
> >
> > 1) if ssl-enabled-component & ssl-use-default-context is configured then
> > use default SSL context.
> > 2) if ssl-enabled-component & no other ssl-* properties are configured
> then
> > configure SSL context by loading truststore and keystore from user home
> > directory.
> > 3) if ssl-enabled-component & ssl-* properties are configured then
> > configure SSL context as configured by user.
> >
> > While #2 and #3 are existing behavior, #1 is implemented as part of
> current
> > proposal for GEODE-5338.
> >
> > On Mon, Aug 13, 2018 at 8:25 AM Sai Boorlagadda <
> sai.boorlaga...@gmail.com
> > >
> > wrote:
> >
> > > I missed follow up emails on this thread, for some reason my email
> client
> > > didn't show there were new messages on this thread. Like Jinmei said, a
> > > user has to first enable SSL by configuring ssl-enable-component and
> then
> > > chose between using default context or using specific
> > > keystore/trustsore (existing implementation).
> > >
> > > Also, I am dropping the idea of making it a new default to use default
> > SSL
> > > context as it will break backward compatibility.
> > >
> > > On Thu, Aug 9, 2018 at 10:52 AM Jinmei Liao  wrote:
> > >
> > >> let me see if my understanding is correct: if ssl-enabled-component is
> > >> none, then we would accept non-ssl connections, no ssl context will be
> > >> used. if ssl-enabled-component is something other than "none", but we
> > don't
> > >> specify any other ssl-* configurations, then we use the default ssl
> > context
> > >> provided by JDK, any customization to the JDK's ssl context (either by
> > >> installing a custom provider or keystore/truststore installed in jdk's
> > >> path) will be used this way. But we do specify any other ssl-*
> > >> configurations, then we use our usual way of loading the ssl context.
> > >>
> > >> On Thu, Aug 9, 2018 at 10:33 AM Anthony Baker 
> > wrote:
> > >>
> > >>>
> > >>>
> > >>> > On Aug 9, 2018, at 10:05 AM, Jacob Barrett 
> > >>> wrote:
> > >>> >
> > >>> >
> > >>> >
> > >>> > On Aug 9, 2018, at 9:42 AM, Anthony Baker 
> wrote:
> > >>> >
> > >>> >>>
> > >>> >>>
> > >>> >>> I would like to also get consensus on defaulting GEODE's behavior
> > to
> > >>> always
> > >>> >>> use default SSL context instead of introducing a new parameter
> > >>> >>> 'ssl-use-default-sslcontext'. If user's have specified any
> existing
> > >>> ssl-*
> > >>> >>> props then the current implementation is exercised (ie to
> configure
> > >>> the
> > >>> >>> context as per provided properties).
> > >>> >>>
> > >>> >>
> > >>> >> If geode is always configured to use the default SSL context, how
> do
> > >>> we know to when to accept SSL v non-SSL connections?
> > >>> >>
> > >>> >
> > >>> > The enable ssl properties.
> > >>> >
> > >>>
> > >>> Sorry I’m missing something.  If the only time we accept SSL
> > connections
> > >>> is when you enable geode ssl-* properties, what is the point of
> > enabling
> > >>> the default SSL context by default?
> > >>>
> > >>> Anthony
> > >>>
> > >>>
> > >>
> > >> --
> > >> Cheers
> > >>
> > >> Jinmei
> > >>
> > >
> >
>
>
> --
> Cheers
>
> Jinmei
>

Re: Proposal to support custom java.security.Provider

[Sai Boorlagadda]

Good question. We can allow a user to use current properties ssl-protocols
and ssl-ciphers even when he wants to use the default security provider.

Here would be a sequence of steps user can to answer:
1) Decide whether you want SSL?
2) Great. Do you want to use
 2.a) default ssl context? or
 2.b) configure ssl context with specific trust and key store types,
locations, passwords.
3) In any case (2.a or 2.b) you have an option to restrict SSL protocols
and ciphers.

On Mon, Aug 13, 2018 at 8:38 AM Jens Deppe  wrote:

> How does this work if the user wants to use the Trust/KeyStoreManager from
> the default security provider but still override other SSL properties such
> as ciphers or protocols?
>
> --Jens
>
> On Mon, Aug 13, 2018 at 8:32 AM Sai Boorlagadda  >
> wrote:
>
> > To make it clear about the different options:
> >
> > 1) if ssl-enabled-component & ssl-use-default-context is configured then
> > use default SSL context.
> > 2) if ssl-enabled-component & no other ssl-* properties are configured
> then
> > configure SSL context by loading truststore and keystore from user home
> > directory.
> > 3) if ssl-enabled-component & ssl-* properties are configured then
> > configure SSL context as configured by user.
> >
> > While #2 and #3 are existing behavior, #1 is implemented as part of
> current
> > proposal for GEODE-5338.
> >
> > On Mon, Aug 13, 2018 at 8:25 AM Sai Boorlagadda <
> sai.boorlaga...@gmail.com
> > >
> > wrote:
> >
> > > I missed follow up emails on this thread, for some reason my email
> client
> > > didn't show there were new messages on this thread. Like Jinmei said, a
> > > user has to first enable SSL by configuring ssl-enable-component and
> then
> > > chose between using default context or using specific
> > > keystore/trustsore (existing implementation).
> > >
> > > Also, I am dropping the idea of making it a new default to use default
> > SSL
> > > context as it will break backward compatibility.
> > >
> > > On Thu, Aug 9, 2018 at 10:52 AM Jinmei Liao  wrote:
> > >
> > >> let me see if my understanding is correct: if ssl-enabled-component is
> > >> none, then we would accept non-ssl connections, no ssl context will be
> > >> used. if ssl-enabled-component is something other than "none", but we
> > don't
> > >> specify any other ssl-* configurations, then we use the default ssl
> > context
> > >> provided by JDK, any customization to the JDK's ssl context (either by
> > >> installing a custom provider or keystore/truststore installed in jdk's
> > >> path) will be used this way. But we do specify any other ssl-*
> > >> configurations, then we use our usual way of loading the ssl context.
> > >>
> > >> On Thu, Aug 9, 2018 at 10:33 AM Anthony Baker 
> > wrote:
> > >>
> > >>>
> > >>>
> > >>> > On Aug 9, 2018, at 10:05 AM, Jacob Barrett 
> > >>> wrote:
> > >>> >
> > >>> >
> > >>> >
> > >>> > On Aug 9, 2018, at 9:42 AM, Anthony Baker 
> wrote:
> > >>> >
> > >>> >>>
> > >>> >>>
> > >>> >>> I would like to also get consensus on defaulting GEODE's behavior
> > to
> > >>> always
> > >>> >>> use default SSL context instead of introducing a new parameter
> > >>> >>> 'ssl-use-default-sslcontext'. If user's have specified any
> existing
> > >>> ssl-*
> > >>> >>> props then the current implementation is exercised (ie to
> configure
> > >>> the
> > >>> >>> context as per provided properties).
> > >>> >>>
> > >>> >>
> > >>> >> If geode is always configured to use the default SSL context, how
> do
> > >>> we know to when to accept SSL v non-SSL connections?
> > >>> >>
> > >>> >
> > >>> > The enable ssl properties.
> > >>> >
> > >>>
> > >>> Sorry I’m missing something.  If the only time we accept SSL
> > connections
> > >>> is when you enable geode ssl-* properties, what is the point of
> > enabling
> > >>> the default SSL context by default?
> > >>>
> > >>> Anthony
> > >>>
> > >>>
> > >>
> > >> --
> > >> Cheers
> > >>
> > >> Jinmei
> > >>
> > >
> >
>

Re: Proposal to support custom java.security.Provider

[Jinmei Liao]

Doing #2 an #3 alone would fix GEODE-5338, right? We don't really need this
new option.

On Mon, Aug 13, 2018 at 8:32 AM Sai Boorlagadda 
wrote:

> To make it clear about the different options:
>
> 1) if ssl-enabled-component & ssl-use-default-context is configured then
> use default SSL context.
> 2) if ssl-enabled-component & no other ssl-* properties are configured then
> configure SSL context by loading truststore and keystore from user home
> directory.
> 3) if ssl-enabled-component & ssl-* properties are configured then
> configure SSL context as configured by user.
>
> While #2 and #3 are existing behavior, #1 is implemented as part of current
> proposal for GEODE-5338.
>
> On Mon, Aug 13, 2018 at 8:25 AM Sai Boorlagadda  >
> wrote:
>
> > I missed follow up emails on this thread, for some reason my email client
> > didn't show there were new messages on this thread. Like Jinmei said, a
> > user has to first enable SSL by configuring ssl-enable-component and then
> > chose between using default context or using specific
> > keystore/trustsore (existing implementation).
> >
> > Also, I am dropping the idea of making it a new default to use default
> SSL
> > context as it will break backward compatibility.
> >
> > On Thu, Aug 9, 2018 at 10:52 AM Jinmei Liao  wrote:
> >
> >> let me see if my understanding is correct: if ssl-enabled-component is
> >> none, then we would accept non-ssl connections, no ssl context will be
> >> used. if ssl-enabled-component is something other than "none", but we
> don't
> >> specify any other ssl-* configurations, then we use the default ssl
> context
> >> provided by JDK, any customization to the JDK's ssl context (either by
> >> installing a custom provider or keystore/truststore installed in jdk's
> >> path) will be used this way. But we do specify any other ssl-*
> >> configurations, then we use our usual way of loading the ssl context.
> >>
> >> On Thu, Aug 9, 2018 at 10:33 AM Anthony Baker 
> wrote:
> >>
> >>>
> >>>
> >>> > On Aug 9, 2018, at 10:05 AM, Jacob Barrett 
> >>> wrote:
> >>> >
> >>> >
> >>> >
> >>> > On Aug 9, 2018, at 9:42 AM, Anthony Baker  wrote:
> >>> >
> >>> >>>
> >>> >>>
> >>> >>> I would like to also get consensus on defaulting GEODE's behavior
> to
> >>> always
> >>> >>> use default SSL context instead of introducing a new parameter
> >>> >>> 'ssl-use-default-sslcontext'. If user's have specified any existing
> >>> ssl-*
> >>> >>> props then the current implementation is exercised (ie to configure
> >>> the
> >>> >>> context as per provided properties).
> >>> >>>
> >>> >>
> >>> >> If geode is always configured to use the default SSL context, how do
> >>> we know to when to accept SSL v non-SSL connections?
> >>> >>
> >>> >
> >>> > The enable ssl properties.
> >>> >
> >>>
> >>> Sorry I’m missing something.  If the only time we accept SSL
> connections
> >>> is when you enable geode ssl-* properties, what is the point of
> enabling
> >>> the default SSL context by default?
> >>>
> >>> Anthony
> >>>
> >>>
> >>
> >> --
> >> Cheers
> >>
> >> Jinmei
> >>
> >
>


-- 
Cheers

Jinmei

Re: Proposal to support custom java.security.Provider

[Jens Deppe]

How does this work if the user wants to use the Trust/KeyStoreManager from
the default security provider but still override other SSL properties such
as ciphers or protocols?

--Jens

On Mon, Aug 13, 2018 at 8:32 AM Sai Boorlagadda 
wrote:

> To make it clear about the different options:
>
> 1) if ssl-enabled-component & ssl-use-default-context is configured then
> use default SSL context.
> 2) if ssl-enabled-component & no other ssl-* properties are configured then
> configure SSL context by loading truststore and keystore from user home
> directory.
> 3) if ssl-enabled-component & ssl-* properties are configured then
> configure SSL context as configured by user.
>
> While #2 and #3 are existing behavior, #1 is implemented as part of current
> proposal for GEODE-5338.
>
> On Mon, Aug 13, 2018 at 8:25 AM Sai Boorlagadda  >
> wrote:
>
> > I missed follow up emails on this thread, for some reason my email client
> > didn't show there were new messages on this thread. Like Jinmei said, a
> > user has to first enable SSL by configuring ssl-enable-component and then
> > chose between using default context or using specific
> > keystore/trustsore (existing implementation).
> >
> > Also, I am dropping the idea of making it a new default to use default
> SSL
> > context as it will break backward compatibility.
> >
> > On Thu, Aug 9, 2018 at 10:52 AM Jinmei Liao  wrote:
> >
> >> let me see if my understanding is correct: if ssl-enabled-component is
> >> none, then we would accept non-ssl connections, no ssl context will be
> >> used. if ssl-enabled-component is something other than "none", but we
> don't
> >> specify any other ssl-* configurations, then we use the default ssl
> context
> >> provided by JDK, any customization to the JDK's ssl context (either by
> >> installing a custom provider or keystore/truststore installed in jdk's
> >> path) will be used this way. But we do specify any other ssl-*
> >> configurations, then we use our usual way of loading the ssl context.
> >>
> >> On Thu, Aug 9, 2018 at 10:33 AM Anthony Baker 
> wrote:
> >>
> >>>
> >>>
> >>> > On Aug 9, 2018, at 10:05 AM, Jacob Barrett 
> >>> wrote:
> >>> >
> >>> >
> >>> >
> >>> > On Aug 9, 2018, at 9:42 AM, Anthony Baker  wrote:
> >>> >
> >>> >>>
> >>> >>>
> >>> >>> I would like to also get consensus on defaulting GEODE's behavior
> to
> >>> always
> >>> >>> use default SSL context instead of introducing a new parameter
> >>> >>> 'ssl-use-default-sslcontext'. If user's have specified any existing
> >>> ssl-*
> >>> >>> props then the current implementation is exercised (ie to configure
> >>> the
> >>> >>> context as per provided properties).
> >>> >>>
> >>> >>
> >>> >> If geode is always configured to use the default SSL context, how do
> >>> we know to when to accept SSL v non-SSL connections?
> >>> >>
> >>> >
> >>> > The enable ssl properties.
> >>> >
> >>>
> >>> Sorry I’m missing something.  If the only time we accept SSL
> connections
> >>> is when you enable geode ssl-* properties, what is the point of
> enabling
> >>> the default SSL context by default?
> >>>
> >>> Anthony
> >>>
> >>>
> >>
> >> --
> >> Cheers
> >>
> >> Jinmei
> >>
> >
>

Re: Proposal to support custom java.security.Provider

[Sai Boorlagadda]

To make it clear about the different options:

1) if ssl-enabled-component & ssl-use-default-context is configured then
use default SSL context.
2) if ssl-enabled-component & no other ssl-* properties are configured then
configure SSL context by loading truststore and keystore from user home
directory.
3) if ssl-enabled-component & ssl-* properties are configured then
configure SSL context as configured by user.

While #2 and #3 are existing behavior, #1 is implemented as part of current
proposal for GEODE-5338.

On Mon, Aug 13, 2018 at 8:25 AM Sai Boorlagadda 
wrote:

> I missed follow up emails on this thread, for some reason my email client
> didn't show there were new messages on this thread. Like Jinmei said, a
> user has to first enable SSL by configuring ssl-enable-component and then
> chose between using default context or using specific
> keystore/trustsore (existing implementation).
>
> Also, I am dropping the idea of making it a new default to use default SSL
> context as it will break backward compatibility.
>
> On Thu, Aug 9, 2018 at 10:52 AM Jinmei Liao  wrote:
>
>> let me see if my understanding is correct: if ssl-enabled-component is
>> none, then we would accept non-ssl connections, no ssl context will be
>> used. if ssl-enabled-component is something other than "none", but we don't
>> specify any other ssl-* configurations, then we use the default ssl context
>> provided by JDK, any customization to the JDK's ssl context (either by
>> installing a custom provider or keystore/truststore installed in jdk's
>> path) will be used this way. But we do specify any other ssl-*
>> configurations, then we use our usual way of loading the ssl context.
>>
>> On Thu, Aug 9, 2018 at 10:33 AM Anthony Baker  wrote:
>>
>>>
>>>
>>> > On Aug 9, 2018, at 10:05 AM, Jacob Barrett 
>>> wrote:
>>> >
>>> >
>>> >
>>> > On Aug 9, 2018, at 9:42 AM, Anthony Baker  wrote:
>>> >
>>> >>>
>>> >>>
>>> >>> I would like to also get consensus on defaulting GEODE's behavior to
>>> always
>>> >>> use default SSL context instead of introducing a new parameter
>>> >>> 'ssl-use-default-sslcontext'. If user's have specified any existing
>>> ssl-*
>>> >>> props then the current implementation is exercised (ie to configure
>>> the
>>> >>> context as per provided properties).
>>> >>>
>>> >>
>>> >> If geode is always configured to use the default SSL context, how do
>>> we know to when to accept SSL v non-SSL connections?
>>> >>
>>> >
>>> > The enable ssl properties.
>>> >
>>>
>>> Sorry I’m missing something.  If the only time we accept SSL connections
>>> is when you enable geode ssl-* properties, what is the point of enabling
>>> the default SSL context by default?
>>>
>>> Anthony
>>>
>>>
>>
>> --
>> Cheers
>>
>> Jinmei
>>
>

Re: Proposal to support custom java.security.Provider

[Sai Boorlagadda]

I missed follow up emails on this thread, for some reason my email client
didn't show there were new messages on this thread. Like Jinmei said, a
user has to first enable SSL by configuring ssl-enable-component and then
chose between using default context or using specific
keystore/trustsore (existing implementation).

Also, I am dropping the idea of making it a new default to use default SSL
context as it will break backward compatibility.

On Thu, Aug 9, 2018 at 10:52 AM Jinmei Liao  wrote:

> let me see if my understanding is correct: if ssl-enabled-component is
> none, then we would accept non-ssl connections, no ssl context will be
> used. if ssl-enabled-component is something other than "none", but we don't
> specify any other ssl-* configurations, then we use the default ssl context
> provided by JDK, any customization to the JDK's ssl context (either by
> installing a custom provider or keystore/truststore installed in jdk's
> path) will be used this way. But we do specify any other ssl-*
> configurations, then we use our usual way of loading the ssl context.
>
> On Thu, Aug 9, 2018 at 10:33 AM Anthony Baker  wrote:
>
>>
>>
>> > On Aug 9, 2018, at 10:05 AM, Jacob Barrett  wrote:
>> >
>> >
>> >
>> > On Aug 9, 2018, at 9:42 AM, Anthony Baker  wrote:
>> >
>> >>>
>> >>>
>> >>> I would like to also get consensus on defaulting GEODE's behavior to
>> always
>> >>> use default SSL context instead of introducing a new parameter
>> >>> 'ssl-use-default-sslcontext'. If user's have specified any existing
>> ssl-*
>> >>> props then the current implementation is exercised (ie to configure
>> the
>> >>> context as per provided properties).
>> >>>
>> >>
>> >> If geode is always configured to use the default SSL context, how do
>> we know to when to accept SSL v non-SSL connections?
>> >>
>> >
>> > The enable ssl properties.
>> >
>>
>> Sorry I’m missing something.  If the only time we accept SSL connections
>> is when you enable geode ssl-* properties, what is the point of enabling
>> the default SSL context by default?
>>
>> Anthony
>>
>>
>
> --
> Cheers
>
> Jinmei
>