please read: geode-3923

[Bruce Schuchardt <bs...@pivotal.io>]

GEODE-3923 changes have been merged to develop life as you know it will 
change a bit.  The merge implements serialization 
white-listing/blacklisting and to insure that we have white-listed the 
correct set of classes, and that no new Geode classes are introduced 
that aren't properly registered, *all unit tests will be run with 
white-listing enabled*.

*What is white-listing?*  It's basically telling Geode to only 
deserialize instances of known classes.  You turn it on with a new cache 
property, validate-serializable-objects.  You white-list a 
java-serializable class by creating a pattern that matches your class 
using the new cache property serializable-object-filter.  There are 
numerous examples of this in the merged test code.

DataSerializable classes do not need to be whitelisted unless they are 
sometimes java-serialized, such as being a value in an array of Objects 
that is serialized with DataSerializer.writeObject().  I've run into a 
few of those.

*Example:*

validate-serializable-objects=true  (default is false except for 
distributedTests)

serializable-object-filter=org.apache.geode.test.query.TestObject;org.apache.geode.test.functions.*


*What happens if you neglect to whitelist your class?*  Your test will 
fail and you will see an InvalidClassException in your test output.  You 
should search for "rejecting" in the output to find the classes that you 
need to whitelist.

*How are Geode classes white-listed?*  Everything that is in 
sanctionedSerializables.txt is automatically white-listed.  The 
AnalyzeSerializablesJUnitTest has new test methods that ensure that all 
classes in the "sanctioned" file can be serialized and deserialized.  It 
also ensures that classes listed in the excludedClasses.txt file can not 
be serialized and deserialized and that none of them are also in the 
sanctionedSerializables.txt white-list.

*Which commit did this to me?*

a2bd5788d0b0728d91d551ddaac878b336d7892a was the merge to develop.  The 
commit message has additional details:

commit a2bd5788d0b0728d91d551ddaac878b336d7892a
Author: Bruce Schuchardt <bs...@pivotal.io>
Date:   Thu Nov 30 14:25:48 2017 -0800

     GEODE-3923 Provide whitelist/blacklist capability for java 
serialization

     This is a squashed and rebased commit of the work from the now-defunct
     whitelist-wip branch.  The work allows you to whitelist and blacklist
     use of Java deserialization for classes matching a pattern you provide.

     All distributedTests are now run with this enabled and with the default
     blacklist pattern of "!*", which blacklists everything not explicitely
     allowed by Geode in the sanctionedSerializables.txt files or by 
your test.

     Each layer needing one now has its own sanctionedSerializables.txt file
     that is a resource in the product tree.  These are installed as 
whitelists
     by a new DistributedSystemService in that layer.

     There are numerous examples of whitelisting classes in the tests.

     If you do not whitelist your class Geode will throw an 
IncompatibleClassException.
     If you happen to run into this look in your logs for "rejecting" 
and you
     can easily find the name of the offending class and add it to your
     whitelist.

     Two new cache properties have been added:

       validate-serializable-objects

     If true checks incoming java serializable objects against a filter 
(allows
     internal Geode classes and any others provided in the
     serializable-object-filter property).

     If you enable this property you must be using Java 8 build 121 or 
later.
     If you are not Geode will throw an exception and refuse to start.

     Default: "false"

       serializable-object-filter

     A user provided whitelist of objects that the system will allow to 
serialize.
     See java.io.ObjectInputFilter.Config for details on the syntax for 
creating filters.

https://docs.oracle.com/javase/9/docs/api/java/io/ObjectInputFilter.Config.html

     Default: "!*"