Re: JGroups vulnerabilty

[Anthony Baker]

Thanks for asking Mario.  Note that if you want to discuss a security topic 
prior to public disclosure you can use priv...@geode.apache.org 
.

Anthony


> On Apr 7, 2020, at 12:04 PM, Mario Kevo  wrote:
> 
> Hi,
> 
> 
> I was trying to understand whether Geode is impacted by a security 
> vulnerability reported on JGroups 
> (CVE-2016-2141). The 
> vulnerability is related to member authentication and communication 
> encryption. What I could learn from this 
> RFC
>  is that geode doesn’t utilize the JGroups membership system, but only the 
> UDP messaging, on top of which a custom encryption system is implemented.
> 
> 
> 
> From this I would say that the reported vulnerability doesn’t really apply to 
> Geode. Nevertheless, I wanted to double-check this.
> 
> 
> BR,
> 
> Mario
> 

[DISCUSS] Adding Google Analytics to our website

[Alexander Murmann]

Hi all,

In promoting our project it might be valuable to get a better idea of where
visitors on our website come from, what they look for and where we lose
them. This should help us improve the website and learn what kind of blogs
articles, videos etc. drive user interest to the website.

To gain those insights I'd like to add Google Analytics (GA). While GA
isn't open source, it is commonly used by other Apache projects. Apache
Cassandra, Kafka, Samza and Spark all have GA trackers on their website.

I've heard rumors that we at some point had it on our website as well. Is
this true? If so, why did we remove it?

Thank you for your thoughts and concerns!

Re: JGroups vulnerabilty

[Bruce Schuchardt]

Thanks Mario -  Geode uses neither the AUTH nor the ENCRYPT JGroups protocols, 
so this doesn't apply.

On 4/7/20, 12:04 PM, "Mario Kevo"  wrote:

Hi,


I was trying to understand whether Geode is impacted by a security 
vulnerability reported on JGroups 
(CVE-2016-2141). The 
vulnerability is related to member authentication and communication encryption. 
What I could learn from this 
RFC
 is that geode doesn’t utilize the JGroups membership system, but only the UDP 
messaging, on top of which a custom encryption system is implemented.



From this I would say that the reported vulnerability doesn’t really apply 
to Geode. Nevertheless, I wanted to double-check this.


BR,

Mario

JGroups vulnerabilty

[Mario Kevo]

Hi,


I was trying to understand whether Geode is impacted by a security 
vulnerability reported on JGroups 
(CVE-2016-2141). The 
vulnerability is related to member authentication and communication encryption. 
What I could learn from this 
RFC
 is that geode doesn’t utilize the JGroups membership system, but only the UDP 
messaging, on top of which a custom encryption system is implemented.



>From this I would say that the reported vulnerability doesn’t really apply to 
>Geode. Nevertheless, I wanted to double-check this.


BR,

Mario

Re: Error while executing dynamic Lucene query

[vas aj]

Hi Dan,

Thanks for the reply.
I moved the Lucene query logic to Geode Function and now the query is
working as expected.

Regards,
Aj

On Tue, Apr 7, 2020 at 12:52 AM Dan Smith  wrote:

> Your custom query code does need to be on the server in order for this to
> work. Specifically, this lambda is your LuceneQueryProvider, which needs to
> be serializable in some way (Serializable, DataSerializable, etc.) and the
> code need to be on the server:
> index -> {
>   return IntPoint.newRangeQuery("age", 25, 35);
> }
>
>
> In your case, the lambda is capturing the surrounding class,
> CustomerServiceImplTest, which is why you are getting an error about
> CustomerServiceImplTest not being serializable.
>
> -Dan
>
> On Mon, Apr 6, 2020 at 2:16 PM vas aj  wrote:
>
>> Hi team,
>>
>> Do I need to write & deploy a custom Geode Function in order to run the
>> dynamic Lucene query?
>> Can I get some help, please?
>>
>> I need to somehow execute a dynamic lucene query on Geode cluster.
>> I am able to run successfully a static lucene query using the
>> standard Lucene's StandardQueryParser, though.
>>
>> Regards,
>> Ajay Vasudevan
>>
>> On Sun, Apr 5, 2020 at 5:29 PM vas aj  wrote:
>>
>>> ++ Dev  team
>>>
>>> Hi team,
>>>
>>> I am trying to execute Lucene query from Geode cache-client with the
>>> following  :
>>>
>>> class CustomerServiceImplTest {
   @Inject CustomerServiceGemfireConfiguration
 customerServiceGemfireConfiguration;
   @Test
   void getAllInterestedCustomers() throws Exception {
 LuceneService luceneService =
 CustomerServiceGemfireConfiguration.getLuceneService();
 String title = "John";
 LuceneQuery luceneQuery =
 luceneService
 .createLuceneQueryFactory()
 .setLimit(50)
 .create(
 "customerLuceneIndex",
 "customers",
 index -> {
   return IntPoint.newRangeQuery("age", 25, 35);
 });
 Collection allInterestedCustomers =
 luceneQuery.findValues();
 System.out.println("all Customers => " + allInterestedCustomers);
   }
 }
>>>
>>>
>>> I get the below error at luceneQuery.findValues() while executing it.
>>> Can someone help me?
>>>
>>> org.apache.geode.cache.client.ServerOperationException: remote server on
 192.168.0.3(24550:loner):38432:0d2d154b: While performing a remote
 executeRegionFunction
 at
 org.apache.geode.cache.client.internal.ExecuteRegionFunctionOp$ExecuteRegionFunctionOpImpl.processResponse(ExecuteRegionFunctionOp.java:437)
 at
 org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:222)
 at
 org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:195)
 at
 org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:382)
 at
 org.apache.geode.cache.client.internal.AbstractOpWithTimeout.attempt(AbstractOpWithTimeout.java:45)
 at
 org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:263)
 at
 org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:353)
 at
 org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:750)
 at
 org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:138)
 at
 org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:787)
 at
 org.apache.geode.cache.client.internal.ExecuteRegionFunctionOp.execute(ExecuteRegionFunctionOp.java:90)
 at
 org.apache.geode.cache.client.internal.ServerRegionProxy.executeFunction(ServerRegionProxy.java:687)
 at
 org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:206)
 at
 org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:158)
 at
 org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:390)
 at
 org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:351)
 at
 org.apache.geode.cache.lucene.internal.LuceneQueryImpl.findTopEntries(LuceneQueryImpl.java:121)
 at
 org.apache.geode.cache.lucene.internal.LuceneQueryImpl.findPages(LuceneQueryImpl.java:99)
 at
 org.apache.geode.cache.lucene.internal.LuceneQueryImpl.findResults(LuceneQueryImpl.java:85)
 at
 org.apache.geode.cache.lucene.internal.LuceneQueryImpl.findValues(LuceneQueryImpl.java:78)
 at
 CustomerServiceImplTest.getAllInterestedCustomers(CustomerServiceImplTest.java:35)

 *Caused by: java.lang.ClassNotFoundException: **CustomerServiceImplTest
  Why should 

Re: In progress RFC's?

[Dan Smith]

Replace singleton PoolManager with ClientCache scoped service has been
moved to the icebox.

-Dan

On Thu, Apr 2, 2020 at 9:08 AM Anthony Baker  wrote:

> I was reviewing the list of RFC’s stil under discussion and noticed that
> the following may need to be moved to a different status:
>
> Classloader Isolation [1] - Udo
> Logging to standard out [2] - Jake
> Replace singleton PoolManager with ClientCache scoped service [3] - Dan
> Certificate based authorization [4] - Mario
>
>
> Could the authors check the status and either extend the discussion date
> or move to the correct status?  Thanks!
>
> Anthony
>
>
> [1]
> https://cwiki.apache.org/confluence/display/GEODE/ClassLoader+Isolation
> [2]
> https://cwiki.apache.org/confluence/display/GEODE/Logging+to+Standard+Out
> [3]
> https://cwiki.apache.org/confluence/display/GEODE/Replace+singleton+PoolManager+with+ClientCache+scoped+service
> [4]
> https://cwiki.apache.org/confluence/display/GEODE/Certificate+Based+Authorization
>
>

Re: [DISCUSS] Replacing singleton PoolManager

[Dan Smith]

It looks like we never came to a consensus on this thread, and meanwhile
the urgency for this fix has gone away. The original urgency was to give
spring data geode a way to avoid using internal APIs, but that has been
fixed a different way in SDG.

I still think this would be a good change to make to get away from needing
singletons in the future, but for now I've moved this to the icebox.

-Dan

On Mon, Dec 9, 2019 at 5:20 PM Dan Smith  wrote:

> On Fri, Dec 6, 2019 at 10:45 AM Dale Emery  wrote:
>
>>
>> > Dale - are you suggesting a ConnectionPoolService that returns
>> ConnectionPool instances?
>>
>> Yes.
>>
>> > Would that mean ConnectionPool would extend Pool and we would deprecate
>> Pool itself?
>>
>> Maybe extend. I worry about extending, for two reasons.
>>
>> First, extending would make the new interface depend on the deprecated
>> one. That feels awkward for reasons I can’t articulate
>>
>> Second, extending would mean that the new interface gets all the methods
>> of the deprecated one whether we want them or not. I don’t know enough
>> about Pool to have an opinion about whether we want to carry all of its
>> method signatures forward.
>>
>> An alternative to consider: Each ConnectionPool implementation delegates
>> to a Pool. I suspect that this would make it harder to migrate existing
>> uses from Pool to ConnectionPool.
>>
>
> We could flip what extends what - Have Pool extend ConnectionPool.
> Deprecate Pool. This would affect the following public APIs:
>
> Pool: Would need to extend a new parent interface called ConnectionPool
> PoolFactory: Would also need a new parent interface called
> ConnectionPoolFactory
> FunctionService: Would need to take ConnectionPool instead of Pool
> ClientCacheFactory: Deprecate all the  setPoolXXX methods and add
> setConnectionPoolXXX?
> ClientCache: Deprecate getDefaultPool and add getDefaultConnectionPool?
> RegionFactory and RegionAttributes: Deprecate setPoolName and add
> setConnectionPoolName
> cache-1.0.xsd : Deprecate the  elements and add 
> elements instead.
> This will also affect downstream projects that use a pool such as Spring
> Data Geode - that project will maybe want to rename PoolFactoryBean, etc.
>
> I guess I'm not sold that making all these name changes is worth it to
> users. Just removing the singleton as the current proposal stands is a much
> smaller scope of change. What do you all think?
>
> -Dan
>

Re: [DISCUSS] Replace UDP messaging for membership with TCP

[Dan Smith]

It looks like we have consensus to move forward with this proposal. Thanks
all for your comments! I've moved it into "In Development"

Thanks,
-Dan

On Fri, Apr 3, 2020 at 4:47 PM Aaron Lindsey 
wrote:

> This proposal sounds good to me. +1 to using standard security
> implementation based on TLS
>
> > On Apr 1, 2020, at 3:20 PM, Dan Smith  wrote:
> >
> >> When we move from a reliable UDP implementation to one based on TCP, we
> >> need to think about how to provide reliability on top of TCP.  If you
> dig
> >> into TCP, you’ll find that it tries really hard (sometimes up to 15
> >> minutes!!) but doesn’t guarantee message delivery.  Does this matter in
> >> practice?  Yes it does--I’ve worked on geode issues where a faulty
> network
> >> cable eventually caused a cluster hang because of a dropped TCP packet.
> >>
> >
> > +1. Yes, we are proposing that the new messenger needs to be able to
> > recreate the TCP connection and resend any unacked messages.
> >
> > -Dan
>
>

Re: Error while executing dynamic Lucene query

[Dan Smith]

Great, glad to hear it!

-Dan

On Tue, Apr 7, 2020 at 10:01 AM vas aj  wrote:

> Hi Dan,
>
> Thanks for the reply.
> I moved the Lucene query logic to Geode Function and now the query is
> working as expected.
>
> Regards,
> Aj
>
> On Tue, Apr 7, 2020 at 12:52 AM Dan Smith  wrote:
>
>> Your custom query code does need to be on the server in order for this to
>> work. Specifically, this lambda is your LuceneQueryProvider, which needs to
>> be serializable in some way (Serializable, DataSerializable, etc.) and the
>> code need to be on the server:
>> index -> {
>>   return IntPoint.newRangeQuery("age", 25, 35);
>> }
>>
>>
>> In your case, the lambda is capturing the surrounding class,
>> CustomerServiceImplTest, which is why you are getting an error about
>> CustomerServiceImplTest not being serializable.
>>
>> -Dan
>>
>> On Mon, Apr 6, 2020 at 2:16 PM vas aj  wrote:
>>
>>> Hi team,
>>>
>>> Do I need to write & deploy a custom Geode Function in order to run the
>>> dynamic Lucene query?
>>> Can I get some help, please?
>>>
>>> I need to somehow execute a dynamic lucene query on Geode cluster.
>>> I am able to run successfully a static lucene query using the
>>> standard Lucene's StandardQueryParser, though.
>>>
>>> Regards,
>>> Ajay Vasudevan
>>>
>>> On Sun, Apr 5, 2020 at 5:29 PM vas aj  wrote:
>>>
 ++ Dev  team

 Hi team,

 I am trying to execute Lucene query from Geode cache-client with the
 following  :

 class CustomerServiceImplTest {
>   @Inject CustomerServiceGemfireConfiguration
> customerServiceGemfireConfiguration;
>   @Test
>   void getAllInterestedCustomers() throws Exception {
> LuceneService luceneService =
> CustomerServiceGemfireConfiguration.getLuceneService();
> String title = "John";
> LuceneQuery luceneQuery =
> luceneService
> .createLuceneQueryFactory()
> .setLimit(50)
> .create(
> "customerLuceneIndex",
> "customers",
> index -> {
>   return IntPoint.newRangeQuery("age", 25, 35);
> });
> Collection allInterestedCustomers =
> luceneQuery.findValues();
> System.out.println("all Customers => " + allInterestedCustomers);
>   }
> }


 I get the below error at luceneQuery.findValues() while executing it.
 Can someone help me?

 org.apache.geode.cache.client.ServerOperationException: remote server
> on 192.168.0.3(24550:loner):38432:0d2d154b: While performing a remote
> executeRegionFunction
> at
> org.apache.geode.cache.client.internal.ExecuteRegionFunctionOp$ExecuteRegionFunctionOpImpl.processResponse(ExecuteRegionFunctionOp.java:437)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:222)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:195)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:382)
> at
> org.apache.geode.cache.client.internal.AbstractOpWithTimeout.attempt(AbstractOpWithTimeout.java:45)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:263)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:353)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:750)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:138)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:787)
> at
> org.apache.geode.cache.client.internal.ExecuteRegionFunctionOp.execute(ExecuteRegionFunctionOp.java:90)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.executeFunction(ServerRegionProxy.java:687)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:206)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:158)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:390)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:351)
> at
> org.apache.geode.cache.lucene.internal.LuceneQueryImpl.findTopEntries(LuceneQueryImpl.java:121)
> at
> org.apache.geode.cache.lucene.internal.LuceneQueryImpl.findPages(LuceneQueryImpl.java:99)
> at
> org.apache.geode.cache.lucene.internal.LuceneQueryImpl.findResults(LuceneQueryImpl.java:85)
> at
>