Re: Proposal to support custom java.security.Provider

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 (exist

Re: Proposal to support custom java.security.Provider

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 direct

Re: Proposal to support custom java.security.Provider

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

Re: Proposal to support custom java.security.Provider

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. >

Re: Proposal to support custom java.security.Provider

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

Re: Proposal to support custom java.security.Provider

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

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

--- Spring Data GemFire > Nightly-ApacheGeode > #1008 was successful. --- Scheduled 2425 tests in total. https://build.spring.io/browse/SGF-NAG-1008/ -- Thi

[DISCUSS] Streamline return value from RemoteQuery

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 remo

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

See