Taking a decision on remaining Jars in OFBiz
Locked
1234
1234
Re: Taking a decision on remaining Jars in OFBiz
 
|
On Sat, Aug 20, 2016 at 11:10 AM, Jacques Le Roux <
[hidden email]> wrote: > Le 20/08/2016 à 08:28, Jacopo Cappellato a écrit : > >> On Sat, Aug 20, 2016 at 7:57 AM, [hidden email] <[hidden email]> >> wrote: >> >> ... >>> ebaystore component we need to put in Attic? >>> >>> Either attic or (quoting myself from a previous mail in this thread) >> "remove >> these jars, disable the component, add a README file to the component to >> explain how to download the jars and deploy it". >> > The 2nd option seems better to me, we can then maintain the code > > Jacques > > Jacopo |
Re: Taking a decision on remaining Jars in OFBiz
|
|
In reply to this post by Jacques Le Roux
Jacques, any news from notsoserial?
If not, I think we can proceed by (temporarily) removing the jars until they will publish the jar. Regards, Jacopo On Sat, Aug 20, 2016 at 11:12 AM, Jacques Le Roux < [hidden email]> wrote: > Yes that's what I proposed also, I will try that before the worse solution > as Taher called them, would you help? > > Jacques > > > > Le 20/08/2016 à 08:32, Pierre Smits a écrit : > >> Hi Jacques, >> >> Why not try to convince the people behind notsoserial to have them push >> the >> library to maven central and/or jpublish? In stead of this community doing >> the work? >> >> Best regards, >> >> >> Pierre Smits >> >> ORRTIZ.COM <http://www.orrtiz.com> >> OFBiz based solutions & services >> >> OFBiz Extensions Marketplace >> http://oem.ofbizci.net/oci-2/ >> >> |
Re: Taking a decision on remaining Jars in OFBiz
|
|
In reply to this post by Jacopo Cappellato-5
On Sat, Aug 20, 2016 at 8:29 AM, Jacopo Cappellato <
[hidden email]> wrote: > > On Sat, Aug 20, 2016 at 7:57 AM, [hidden email] <[hidden email]> > wrote: > >> ... >> IMO we can delete the cmssite component jars they are only used in >> extensions of Dockbook and AFAIK we don't use them >> >> This is now done in rev. 1759593 Jacopo |
Re: Taking a decision on remaining Jars in OFBiz
Administrator
|
In reply to this post by Jacopo Cappellato-5
Yes I see no problems with that. I just need to add directions for users before. I'll then remove the jars... very soon...
Jacques Le 07/09/2016 à 13:09, Jacopo Cappellato a écrit : > Jacques, any news from notsoserial? > If not, I think we can proceed by (temporarily) removing the jars until > they will publish the jar. > > Regards, > > Jacopo > > On Sat, Aug 20, 2016 at 11:12 AM, Jacques Le Roux < > [hidden email]> wrote: > >> Yes that's what I proposed also, I will try that before the worse solution >> as Taher called them, would you help? >> >> Jacques >> >> >> >> Le 20/08/2016 à 08:32, Pierre Smits a écrit : >> >>> Hi Jacques, >>> >>> Why not try to convince the people behind notsoserial to have them push >>> the >>> library to maven central and/or jpublish? In stead of this community doing >>> the work? >>> >>> Best regards, >>> >>> >>> Pierre Smits >>> >>> ORRTIZ.COM <http://www.orrtiz.com> >>> OFBiz based solutions & services >>> >>> OFBiz Extensions Marketplace >>> http://oem.ofbizci.net/oci-2/ >>> >>> |
Re: Taking a decision on remaining Jars in OFBiz
|
Administrator
|
Huho, I was too fast on this. Currently the Gradle "ofbizSecure" tasks depends on the notsoserial-1.0-SNAPSHOT.jar
So this would need more work and w/o answers from them I suspect they will not publish the jar. Now it's a serious security but not OOTB. So I see 2 possibilities. 1. Ask the ASF for a derogation (after all it's a Java issue not an OFBiz one) 2. Do what I said before AND change the Gradle "ofbizSecure" tasks Opinions? Jacques Le 07/09/2016 à 14:01, Jacques Le Roux a écrit : > Yes I see no problems with that. I just need to add directions for users before. I'll then remove the jars... very soon... > > Jacques > > > Le 07/09/2016 à 13:09, Jacopo Cappellato a écrit : >> Jacques, any news from notsoserial? >> If not, I think we can proceed by (temporarily) removing the jars until >> they will publish the jar. >> >> Regards, >> >> Jacopo >> >> On Sat, Aug 20, 2016 at 11:12 AM, Jacques Le Roux < >> [hidden email]> wrote: >> >>> Yes that's what I proposed also, I will try that before the worse solution >>> as Taher called them, would you help? >>> >>> Jacques >>> >>> >>> >>> Le 20/08/2016 à 08:32, Pierre Smits a écrit : >>> >>>> Hi Jacques, >>>> >>>> Why not try to convince the people behind notsoserial to have them push >>>> the >>>> library to maven central and/or jpublish? In stead of this community doing >>>> the work? >>>> >>>> Best regards, >>>> >>>> >>>> Pierre Smits >>>> >>>> ORRTIZ.COM <http://www.orrtiz.com> >>>> OFBiz based solutions & services >>>> >>>> OFBiz Extensions Marketplace >>>> http://oem.ofbizci.net/oci-2/ >>>> >>>> > > |
|
Hi Jacques,
First of all the ofbizSecure task is gone instead everything calls the correct jvm arguments by default to fetch notsoserial. The work to remove notsoserial is almost nothing. You just to remove a few jvm args and that's it. Even if you don't remove the jvm args nothing happens because it will just ignore it as missing from the classpath. Taher Alkhateeb On Sep 7, 2016 5:48 PM, "Jacques Le Roux" <[hidden email]> wrote: > Huho, I was too fast on this. Currently the Gradle "ofbizSecure" tasks > depends on the notsoserial-1.0-SNAPSHOT.jar > > So this would need more work and w/o answers from them I suspect they will > not publish the jar. > > Now it's a serious security but not OOTB. So I see 2 possibilities. > > 1. Ask the ASF for a derogation (after all it's a Java issue not an OFBiz > one) > 2. Do what I said before AND change the Gradle "ofbizSecure" tasks > > Opinions? > > Jacques > > > Le 07/09/2016 à 14:01, Jacques Le Roux a écrit : > >> Yes I see no problems with that. I just need to add directions for users >> before. I'll then remove the jars... very soon... >> >> Jacques >> >> >> Le 07/09/2016 à 13:09, Jacopo Cappellato a écrit : >> >>> Jacques, any news from notsoserial? >>> If not, I think we can proceed by (temporarily) removing the jars until >>> they will publish the jar. >>> >>> Regards, >>> >>> Jacopo >>> >>> On Sat, Aug 20, 2016 at 11:12 AM, Jacques Le Roux < >>> [hidden email]> wrote: >>> >>> Yes that's what I proposed also, I will try that before the worse >>>> solution >>>> as Taher called them, would you help? >>>> >>>> Jacques >>>> >>>> >>>> >>>> Le 20/08/2016 à 08:32, Pierre Smits a écrit : >>>> >>>> Hi Jacques, >>>>> >>>>> Why not try to convince the people behind notsoserial to have them push >>>>> the >>>>> library to maven central and/or jpublish? In stead of this community >>>>> doing >>>>> the work? >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> Pierre Smits >>>>> >>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>> OFBiz based solutions & services >>>>> >>>>> OFBiz Extensions Marketplace >>>>> http://oem.ofbizci.net/oci-2/ >>>>> >>>>> >>>>> >> >> > |
Re: Taking a decision on remaining Jars in OFBiz
|
|
Thank you Jacques and Taher.
So it seems we can move on and temporarily remove the jar. Jacopo On Wed, Sep 7, 2016 at 5:11 PM, Taher Alkhateeb <[hidden email]> wrote: > Hi Jacques, > > First of all the ofbizSecure task is gone instead everything calls the > correct jvm arguments by default to fetch notsoserial. > > The work to remove notsoserial is almost nothing. You just to remove a few > jvm args and that's it. Even if you don't remove the jvm args nothing > happens because it will just ignore it as missing from the classpath. > > Taher Alkhateeb > > On Sep 7, 2016 5:48 PM, "Jacques Le Roux" <[hidden email]> > wrote: > > > Huho, I was too fast on this. Currently the Gradle "ofbizSecure" tasks > > depends on the notsoserial-1.0-SNAPSHOT.jar > > > > So this would need more work and w/o answers from them I suspect they > will > > not publish the jar. > > > > Now it's a serious security but not OOTB. So I see 2 possibilities. > > > > 1. Ask the ASF for a derogation (after all it's a Java issue not an OFBiz > > one) > > 2. Do what I said before AND change the Gradle "ofbizSecure" tasks > > > > Opinions? > > > > Jacques > > > > > > Le 07/09/2016 à 14:01, Jacques Le Roux a écrit : > > > >> Yes I see no problems with that. I just need to add directions for users > >> before. I'll then remove the jars... very soon... > >> > >> Jacques > >> > >> > >> Le 07/09/2016 à 13:09, Jacopo Cappellato a écrit : > >> > >>> Jacques, any news from notsoserial? > >>> If not, I think we can proceed by (temporarily) removing the jars until > >>> they will publish the jar. > >>> > >>> Regards, > >>> > >>> Jacopo > >>> > >>> On Sat, Aug 20, 2016 at 11:12 AM, Jacques Le Roux < > >>> [hidden email]> wrote: > >>> > >>> Yes that's what I proposed also, I will try that before the worse > >>>> solution > >>>> as Taher called them, would you help? > >>>> > >>>> Jacques > >>>> > >>>> > >>>> > >>>> Le 20/08/2016 à 08:32, Pierre Smits a écrit : > >>>> > >>>> Hi Jacques, > >>>>> > >>>>> Why not try to convince the people behind notsoserial to have them > push > >>>>> the > >>>>> library to maven central and/or jpublish? In stead of this community > >>>>> doing > >>>>> the work? > >>>>> > >>>>> Best regards, > >>>>> > >>>>> > >>>>> Pierre Smits > >>>>> > >>>>> ORRTIZ.COM <http://www.orrtiz.com> > >>>>> OFBiz based solutions & services > >>>>> > >>>>> OFBiz Extensions Marketplace > >>>>> http://oem.ofbizci.net/oci-2/ > >>>>> > >>>>> > >>>>> > >> > >> > > > |
Re: Taking a decision on remaining Jars in OFBiz
|
Administrator
|
OK Cool, if the JVM arguments are simply ignored, then I will proceed with an addition in the readme and remove the jar, simple
Jacques Le 07/09/2016 à 17:16, Jacopo Cappellato a écrit : > Thank you Jacques and Taher. > > So it seems we can move on and temporarily remove the jar. > > Jacopo > > > On Wed, Sep 7, 2016 at 5:11 PM, Taher Alkhateeb <[hidden email]> > wrote: > >> Hi Jacques, >> >> First of all the ofbizSecure task is gone instead everything calls the >> correct jvm arguments by default to fetch notsoserial. >> >> The work to remove notsoserial is almost nothing. You just to remove a few >> jvm args and that's it. Even if you don't remove the jvm args nothing >> happens because it will just ignore it as missing from the classpath. >> >> Taher Alkhateeb >> >> On Sep 7, 2016 5:48 PM, "Jacques Le Roux" <[hidden email]> >> wrote: >> >>> Huho, I was too fast on this. Currently the Gradle "ofbizSecure" tasks >>> depends on the notsoserial-1.0-SNAPSHOT.jar >>> >>> So this would need more work and w/o answers from them I suspect they >> will >>> not publish the jar. >>> >>> Now it's a serious security but not OOTB. So I see 2 possibilities. >>> >>> 1. Ask the ASF for a derogation (after all it's a Java issue not an OFBiz >>> one) >>> 2. Do what I said before AND change the Gradle "ofbizSecure" tasks >>> >>> Opinions? >>> >>> Jacques >>> >>> >>> Le 07/09/2016 à 14:01, Jacques Le Roux a écrit : >>> >>>> Yes I see no problems with that. I just need to add directions for users >>>> before. I'll then remove the jars... very soon... >>>> >>>> Jacques >>>> >>>> >>>> Le 07/09/2016 à 13:09, Jacopo Cappellato a écrit : >>>> >>>>> Jacques, any news from notsoserial? >>>>> If not, I think we can proceed by (temporarily) removing the jars until >>>>> they will publish the jar. >>>>> >>>>> Regards, >>>>> >>>>> Jacopo >>>>> >>>>> On Sat, Aug 20, 2016 at 11:12 AM, Jacques Le Roux < >>>>> [hidden email]> wrote: >>>>> >>>>> Yes that's what I proposed also, I will try that before the worse >>>>>> solution >>>>>> as Taher called them, would you help? >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> >>>>>> Le 20/08/2016 à 08:32, Pierre Smits a écrit : >>>>>> >>>>>> Hi Jacques, >>>>>>> Why not try to convince the people behind notsoserial to have them >> push >>>>>>> the >>>>>>> library to maven central and/or jpublish? In stead of this community >>>>>>> doing >>>>>>> the work? >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> >>>>>>> Pierre Smits >>>>>>> >>>>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>>>> OFBiz based solutions & services >>>>>>> >>>>>>> OFBiz Extensions Marketplace >>>>>>> http://oem.ofbizci.net/oci-2/ >>>>>>> >>>>>>> >>>>>>> >>>> |
|
|
Scratch that, actually only the -D arguments are ignored, we must remove
the -javaagent argument because it's not a classpath argument and would crash the VM But for consistency's sake, let's remove them all for now. So simply we apply: Index: build.gradle =================================================================== --- build.gradle (revision 1759596) +++ build.gradle (working copy) @@ -31,11 +31,7 @@ ext.os = System.getProperty('os.name').toLowerCase() // java settings -def jvmArguments = ['-Xms128M', '-Xmx1024M', - "-javaagent:${rootDir}/tools/security/notsoserial/notsoserial-1.0-SNAPSHOT.jar", - "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoserial/empty.txt", - "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/is-deserialized.txt", - "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/deserialize-trace.txt"] +def jvmArguments = ['-Xms128M', '-Xmx1024M'] ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start' javadoc.failOnError = false sourceCompatibility = '1.8' On Wed, Sep 7, 2016 at 9:04 PM, Jacques Le Roux < [hidden email]> wrote: > OK Cool, if the JVM arguments are simply ignored, then I will proceed with > an addition in the readme and remove the jar, simple > > Jacques > > > > Le 07/09/2016 à 17:16, Jacopo Cappellato a écrit : > >> Thank you Jacques and Taher. >> >> So it seems we can move on and temporarily remove the jar. >> >> Jacopo >> >> >> On Wed, Sep 7, 2016 at 5:11 PM, Taher Alkhateeb < >> [hidden email]> >> wrote: >> >> Hi Jacques, >>> >>> First of all the ofbizSecure task is gone instead everything calls the >>> correct jvm arguments by default to fetch notsoserial. >>> >>> The work to remove notsoserial is almost nothing. You just to remove a >>> few >>> jvm args and that's it. Even if you don't remove the jvm args nothing >>> happens because it will just ignore it as missing from the classpath. >>> >>> Taher Alkhateeb >>> >>> On Sep 7, 2016 5:48 PM, "Jacques Le Roux" <[hidden email]> >>> wrote: >>> >>> Huho, I was too fast on this. Currently the Gradle "ofbizSecure" tasks >>>> depends on the notsoserial-1.0-SNAPSHOT.jar >>>> >>>> So this would need more work and w/o answers from them I suspect they >>>> >>> will >>> >>>> not publish the jar. >>>> >>>> Now it's a serious security but not OOTB. So I see 2 possibilities. >>>> >>>> 1. Ask the ASF for a derogation (after all it's a Java issue not an >>>> OFBiz >>>> one) >>>> 2. Do what I said before AND change the Gradle "ofbizSecure" tasks >>>> >>>> Opinions? >>>> >>>> Jacques >>>> >>>> >>>> Le 07/09/2016 à 14:01, Jacques Le Roux a écrit : >>>> >>>> Yes I see no problems with that. I just need to add directions for users >>>>> before. I'll then remove the jars... very soon... >>>>> >>>>> Jacques >>>>> >>>>> >>>>> Le 07/09/2016 à 13:09, Jacopo Cappellato a écrit : >>>>> >>>>> Jacques, any news from notsoserial? >>>>>> If not, I think we can proceed by (temporarily) removing the jars >>>>>> until >>>>>> they will publish the jar. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Jacopo >>>>>> >>>>>> On Sat, Aug 20, 2016 at 11:12 AM, Jacques Le Roux < >>>>>> [hidden email]> wrote: >>>>>> >>>>>> Yes that's what I proposed also, I will try that before the worse >>>>>> >>>>>>> solution >>>>>>> as Taher called them, would you help? >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> >>>>>>> >>>>>>> Le 20/08/2016 à 08:32, Pierre Smits a écrit : >>>>>>> >>>>>>> Hi Jacques, >>>>>>> >>>>>>>> Why not try to convince the people behind notsoserial to have them >>>>>>>> >>>>>>> push >>> >>>> the >>>>>>>> library to maven central and/or jpublish? In stead of this community >>>>>>>> doing >>>>>>>> the work? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> >>>>>>>> Pierre Smits >>>>>>>> >>>>>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>>>>> OFBiz based solutions & services >>>>>>>> >>>>>>>> OFBiz Extensions Marketplace >>>>>>>> http://oem.ofbizci.net/oci-2/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>> > |
Re: Taking a decision on remaining Jars in OFBiz
|
Administrator
|
OK, since we have no issues OOTB that can be done.
But IMO documenting the whole thing in our nososerial readme.txt is not enough. We need to make that more prominent. Not sure how yet... Jacques Le 07/09/2016 à 20:09, Taher Alkhateeb a écrit : > Scratch that, actually only the -D arguments are ignored, we must remove > the -javaagent argument because it's not a classpath argument and would > crash the VM > > But for consistency's sake, let's remove them all for now. So simply we > apply: > > Index: build.gradle > =================================================================== > --- build.gradle (revision 1759596) > +++ build.gradle (working copy) > @@ -31,11 +31,7 @@ > ext.os = System.getProperty('os.name').toLowerCase() > > // java settings > -def jvmArguments = ['-Xms128M', '-Xmx1024M', > - > "-javaagent:${rootDir}/tools/security/notsoserial/notsoserial-1.0-SNAPSHOT.jar", > - > "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoserial/empty.txt", > - > "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/is-deserialized.txt", > - > "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/deserialize-trace.txt"] > +def jvmArguments = ['-Xms128M', '-Xmx1024M'] > ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start' > javadoc.failOnError = false > sourceCompatibility = '1.8' > > On Wed, Sep 7, 2016 at 9:04 PM, Jacques Le Roux < > [hidden email]> wrote: > >> OK Cool, if the JVM arguments are simply ignored, then I will proceed with >> an addition in the readme and remove the jar, simple >> >> Jacques >> >> >> >> Le 07/09/2016 à 17:16, Jacopo Cappellato a écrit : >> >>> Thank you Jacques and Taher. >>> >>> So it seems we can move on and temporarily remove the jar. >>> >>> Jacopo >>> >>> >>> On Wed, Sep 7, 2016 at 5:11 PM, Taher Alkhateeb < >>> [hidden email]> >>> wrote: >>> >>> Hi Jacques, >>>> First of all the ofbizSecure task is gone instead everything calls the >>>> correct jvm arguments by default to fetch notsoserial. >>>> >>>> The work to remove notsoserial is almost nothing. You just to remove a >>>> few >>>> jvm args and that's it. Even if you don't remove the jvm args nothing >>>> happens because it will just ignore it as missing from the classpath. >>>> >>>> Taher Alkhateeb >>>> >>>> On Sep 7, 2016 5:48 PM, "Jacques Le Roux" <[hidden email]> >>>> wrote: >>>> >>>> Huho, I was too fast on this. Currently the Gradle "ofbizSecure" tasks >>>>> depends on the notsoserial-1.0-SNAPSHOT.jar >>>>> >>>>> So this would need more work and w/o answers from them I suspect they >>>>> >>>> will >>>> >>>>> not publish the jar. >>>>> >>>>> Now it's a serious security but not OOTB. So I see 2 possibilities. >>>>> >>>>> 1. Ask the ASF for a derogation (after all it's a Java issue not an >>>>> OFBiz >>>>> one) >>>>> 2. Do what I said before AND change the Gradle "ofbizSecure" tasks >>>>> >>>>> Opinions? >>>>> >>>>> Jacques >>>>> >>>>> >>>>> Le 07/09/2016 à 14:01, Jacques Le Roux a écrit : >>>>> >>>>> Yes I see no problems with that. I just need to add directions for users >>>>>> before. I'll then remove the jars... very soon... >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> Le 07/09/2016 à 13:09, Jacopo Cappellato a écrit : >>>>>> >>>>>> Jacques, any news from notsoserial? >>>>>>> If not, I think we can proceed by (temporarily) removing the jars >>>>>>> until >>>>>>> they will publish the jar. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Jacopo >>>>>>> >>>>>>> On Sat, Aug 20, 2016 at 11:12 AM, Jacques Le Roux < >>>>>>> [hidden email]> wrote: >>>>>>> >>>>>>> Yes that's what I proposed also, I will try that before the worse >>>>>>> >>>>>>>> solution >>>>>>>> as Taher called them, would you help? >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Le 20/08/2016 à 08:32, Pierre Smits a écrit : >>>>>>>> >>>>>>>> Hi Jacques, >>>>>>>> >>>>>>>>> Why not try to convince the people behind notsoserial to have them >>>>>>>>> >>>>>>>> push >>>>> the >>>>>>>>> library to maven central and/or jpublish? In stead of this community >>>>>>>>> doing >>>>>>>>> the work? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> >>>>>>>>> Pierre Smits >>>>>>>>> >>>>>>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>>>>>> OFBiz based solutions & services >>>>>>>>> >>>>>>>>> OFBiz Extensions Marketplace >>>>>>>>> http://oem.ofbizci.net/oci-2/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> |
Re: Taking a decision on remaining Jars in OFBiz
|
|
I think we can proceed in the following way:
1) remove the jar and the dependent Gradle code and move on with the release branches and release publication workflow 2) continue the discussion about what, where, how we want to document about nososerial (e.g. a message in our download page would be enough) An important aspect of the discussion at #2 would be to research how other ASF projects, based on Java, are doing about it: we could get some inspiration and ideas from them. Jacopo On Wed, Sep 7, 2016 at 10:37 PM, Jacques Le Roux < [hidden email]> wrote: > OK, since we have no issues OOTB that can be done. > > But IMO documenting the whole thing in our nososerial readme.txt is not > enough. We need to make that more prominent. Not sure how yet... > > Jacques > > > > Le 07/09/2016 à 20:09, Taher Alkhateeb a écrit : > >> Scratch that, actually only the -D arguments are ignored, we must remove >> the -javaagent argument because it's not a classpath argument and would >> crash the VM >> >> But for consistency's sake, let's remove them all for now. So simply we >> apply: >> >> Index: build.gradle >> =================================================================== >> --- build.gradle (revision 1759596) >> +++ build.gradle (working copy) >> @@ -31,11 +31,7 @@ >> ext.os = System.getProperty('os.name').toLowerCase() >> >> // java settings >> -def jvmArguments = ['-Xms128M', '-Xmx1024M', >> - >> "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria >> l-1.0-SNAPSHOT.jar", >> - >> "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoseri >> al/empty.txt", >> - >> "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/ >> is-deserialized.txt", >> - >> "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/ >> deserialize-trace.txt"] >> +def jvmArguments = ['-Xms128M', '-Xmx1024M'] >> ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start' >> javadoc.failOnError = false >> sourceCompatibility = '1.8' >> >> On Wed, Sep 7, 2016 at 9:04 PM, Jacques Le Roux < >> [hidden email]> wrote: >> >> OK Cool, if the JVM arguments are simply ignored, then I will proceed with >>> an addition in the readme and remove the jar, simple >>> >>> Jacques >>> >>> >>> >>> Le 07/09/2016 à 17:16, Jacopo Cappellato a écrit : >>> >>> Thank you Jacques and Taher. >>>> >>>> So it seems we can move on and temporarily remove the jar. >>>> >>>> Jacopo >>>> >>>> >>>> On Wed, Sep 7, 2016 at 5:11 PM, Taher Alkhateeb < >>>> [hidden email]> >>>> wrote: >>>> >>>> Hi Jacques, >>>> >>>>> First of all the ofbizSecure task is gone instead everything calls the >>>>> correct jvm arguments by default to fetch notsoserial. >>>>> >>>>> The work to remove notsoserial is almost nothing. You just to remove a >>>>> few >>>>> jvm args and that's it. Even if you don't remove the jvm args nothing >>>>> happens because it will just ignore it as missing from the classpath. >>>>> >>>>> Taher Alkhateeb >>>>> >>>>> On Sep 7, 2016 5:48 PM, "Jacques Le Roux" < >>>>> [hidden email]> >>>>> wrote: >>>>> >>>>> Huho, I was too fast on this. Currently the Gradle "ofbizSecure" tasks >>>>> >>>>>> depends on the notsoserial-1.0-SNAPSHOT.jar >>>>>> >>>>>> So this would need more work and w/o answers from them I suspect they >>>>>> >>>>>> will >>>>> >>>>> not publish the jar. >>>>>> >>>>>> Now it's a serious security but not OOTB. So I see 2 possibilities. >>>>>> >>>>>> 1. Ask the ASF for a derogation (after all it's a Java issue not an >>>>>> OFBiz >>>>>> one) >>>>>> 2. Do what I said before AND change the Gradle "ofbizSecure" tasks >>>>>> >>>>>> Opinions? >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> Le 07/09/2016 à 14:01, Jacques Le Roux a écrit : >>>>>> >>>>>> Yes I see no problems with that. I just need to add directions for >>>>>> users >>>>>> >>>>>>> before. I'll then remove the jars... very soon... >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> >>>>>>> Le 07/09/2016 à 13:09, Jacopo Cappellato a écrit : >>>>>>> >>>>>>> Jacques, any news from notsoserial? >>>>>>> >>>>>>>> If not, I think we can proceed by (temporarily) removing the jars >>>>>>>> until >>>>>>>> they will publish the jar. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Jacopo >>>>>>>> >>>>>>>> On Sat, Aug 20, 2016 at 11:12 AM, Jacques Le Roux < >>>>>>>> [hidden email]> wrote: >>>>>>>> >>>>>>>> Yes that's what I proposed also, I will try that before the worse >>>>>>>> >>>>>>>> solution >>>>>>>>> as Taher called them, would you help? >>>>>>>>> >>>>>>>>> Jacques >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 20/08/2016 à 08:32, Pierre Smits a écrit : >>>>>>>>> >>>>>>>>> Hi Jacques, >>>>>>>>> >>>>>>>>> Why not try to convince the people behind notsoserial to have them >>>>>>>>>> >>>>>>>>>> push >>>>>>>>> >>>>>>>> the >>>>>> >>>>>>> library to maven central and/or jpublish? In stead of this community >>>>>>>>>> doing >>>>>>>>>> the work? >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Pierre Smits >>>>>>>>>> >>>>>>>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>>>>>>> OFBiz based solutions & services >>>>>>>>>> >>>>>>>>>> OFBiz Extensions Marketplace >>>>>>>>>> http://oem.ofbizci.net/oci-2/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > |
Re: Taking a decision on remaining Jars in OFBiz
|
Administrator
|
In reply to this post by Jacques Le Roux
OK wait! I think we skipped a step: access the jar from an accessible repo.
I see 2 solutions: 1. Push ourselves the notsoserial jar in jcenter => updating a fork now and then, though notsoserial will not need much changes now 2. Use https://jitpack.io/ I prefer 2, though I have still to * resolve the notsoserial.jar path in my hasty proposition below * use|master-SNAPSHOT| instead of last hash (to not break on changes) which may need to refresh dependencies (did not investigate yet: https://jitpack.io/docs/#snapshots) Index: build.gradle =================================================================== --- build.gradle (revision 1759557) +++ build.gradle (working copy) @@ -32,7 +32,7 @@ // java settings def jvmArguments = ['-Xms128M', '-Xmx1024M', - "-javaagent:${rootDir}/tools/security/notsoserial/notsoserial-1.0-SNAPSHOT.jar", + "-javaagent:C:/Users/Jacques/.gradle/caches/modules-2/files-2.1/com.github.kantega/notsoserial/f2baaaa/3646e12f5ce4713f9ad2aa027e3fec81097fcd93/notsoserial-f2baaaa.jar", "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoserial/empty.txt", "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/is-deserialized.txt", "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/deserialize-trace.txt"] @@ -52,6 +52,7 @@ allprojects { repositories{ jcenter() + maven { url "https://jitpack.io" } } } @@ -119,6 +120,7 @@ compile 'org.zapodot:jackson-databind-java-optional:2.4.2' compile 'oro:oro:2.0.8' compile 'wsdl4j:wsdl4j:1.6.2' + compile 'com.github.kantega:notsoserial:f2baaaa' // general framework runtime libs runtime 'de.odysseus.juel:juel-spi:2.2.7' I think you get the idea, it works w/o any other modifications, what to you think? Jacques Le 07/09/2016 à 22:37, Jacques Le Roux a écrit : > OK, since we have no issues OOTB that can be done. > > But IMO documenting the whole thing in our nososerial readme.txt is not enough. We need to make that more prominent. Not sure how yet... > > Jacques > > > Le 07/09/2016 à 20:09, Taher Alkhateeb a écrit : >> Scratch that, actually only the -D arguments are ignored, we must remove >> the -javaagent argument because it's not a classpath argument and would >> crash the VM >> >> But for consistency's sake, let's remove them all for now. So simply we >> apply: >> >> Index: build.gradle >> =================================================================== >> --- build.gradle (revision 1759596) >> +++ build.gradle (working copy) >> @@ -31,11 +31,7 @@ >> ext.os = System.getProperty('os.name').toLowerCase() >> >> // java settings >> -def jvmArguments = ['-Xms128M', '-Xmx1024M', >> - >> "-javaagent:${rootDir}/tools/security/notsoserial/notsoserial-1.0-SNAPSHOT.jar", >> - >> "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoserial/empty.txt", >> - >> "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/is-deserialized.txt", >> - >> "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/deserialize-trace.txt"] >> +def jvmArguments = ['-Xms128M', '-Xmx1024M'] >> ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start' >> javadoc.failOnError = false >> sourceCompatibility = '1.8' >> >> On Wed, Sep 7, 2016 at 9:04 PM, Jacques Le Roux < >> [hidden email]> wrote: >> >>> OK Cool, if the JVM arguments are simply ignored, then I will proceed with >>> an addition in the readme and remove the jar, simple >>> >>> Jacques >>> >>> >>> >>> Le 07/09/2016 à 17:16, Jacopo Cappellato a écrit : >>> >>>> Thank you Jacques and Taher. >>>> >>>> So it seems we can move on and temporarily remove the jar. >>>> >>>> Jacopo >>>> >>>> >>>> On Wed, Sep 7, 2016 at 5:11 PM, Taher Alkhateeb < >>>> [hidden email]> >>>> wrote: >>>> >>>> Hi Jacques, >>>>> First of all the ofbizSecure task is gone instead everything calls the >>>>> correct jvm arguments by default to fetch notsoserial. >>>>> >>>>> The work to remove notsoserial is almost nothing. You just to remove a >>>>> few >>>>> jvm args and that's it. Even if you don't remove the jvm args nothing >>>>> happens because it will just ignore it as missing from the classpath. >>>>> >>>>> Taher Alkhateeb >>>>> >>>>> On Sep 7, 2016 5:48 PM, "Jacques Le Roux" <[hidden email]> >>>>> wrote: >>>>> >>>>> Huho, I was too fast on this. Currently the Gradle "ofbizSecure" tasks >>>>>> depends on the notsoserial-1.0-SNAPSHOT.jar >>>>>> >>>>>> So this would need more work and w/o answers from them I suspect they >>>>>> >>>>> will >>>>> >>>>>> not publish the jar. >>>>>> >>>>>> Now it's a serious security but not OOTB. So I see 2 possibilities. >>>>>> >>>>>> 1. Ask the ASF for a derogation (after all it's a Java issue not an >>>>>> OFBiz >>>>>> one) >>>>>> 2. Do what I said before AND change the Gradle "ofbizSecure" tasks >>>>>> >>>>>> Opinions? >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> Le 07/09/2016 à 14:01, Jacques Le Roux a écrit : >>>>>> >>>>>> Yes I see no problems with that. I just need to add directions for users >>>>>>> before. I'll then remove the jars... very soon... >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> >>>>>>> Le 07/09/2016 à 13:09, Jacopo Cappellato a écrit : >>>>>>> >>>>>>> Jacques, any news from notsoserial? >>>>>>>> If not, I think we can proceed by (temporarily) removing the jars >>>>>>>> until >>>>>>>> they will publish the jar. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Jacopo >>>>>>>> >>>>>>>> On Sat, Aug 20, 2016 at 11:12 AM, Jacques Le Roux < >>>>>>>> [hidden email]> wrote: >>>>>>>> >>>>>>>> Yes that's what I proposed also, I will try that before the worse >>>>>>>> >>>>>>>>> solution >>>>>>>>> as Taher called them, would you help? >>>>>>>>> >>>>>>>>> Jacques >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 20/08/2016 à 08:32, Pierre Smits a écrit : >>>>>>>>> >>>>>>>>> Hi Jacques, >>>>>>>>> >>>>>>>>>> Why not try to convince the people behind notsoserial to have them >>>>>>>>>> >>>>>>>>> push >>>>>> the >>>>>>>>>> library to maven central and/or jpublish? In stead of this community >>>>>>>>>> doing >>>>>>>>>> the work? >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Pierre Smits >>>>>>>>>> >>>>>>>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>>>>>>> OFBiz based solutions & services >>>>>>>>>> >>>>>>>>>> OFBiz Extensions Marketplace >>>>>>>>>> http://oem.ofbizci.net/oci-2/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > > |
|
|
The above patch does not work Jacques, you are hard coding the path. This
needs to be properly developed. On Thu, Sep 8, 2016 at 9:23 AM, Jacques Le Roux < [hidden email]> wrote: > OK wait! I think we skipped a step: access the jar from an accessible repo. > > I see 2 solutions: > > 1. Push ourselves the notsoserial jar in jcenter => updating a fork now > and then, though notsoserial will not need much changes now > 2. Use https://jitpack.io/ > > I prefer 2, though I have still to > > * resolve the notsoserial.jar path in my hasty proposition below > * use|master-SNAPSHOT| instead of last hash (to not break on changes) > which may need to refresh dependencies (did not investigate yet: > https://jitpack.io/docs/#snapshots) > > Index: build.gradle > =================================================================== > --- build.gradle (revision 1759557) > +++ build.gradle (working copy) > @@ -32,7 +32,7 @@ > > // java settings > def jvmArguments = ['-Xms128M', '-Xmx1024M', > - "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria > l-1.0-SNAPSHOT.jar", > + "-javaagent:C:/Users/Jacques/.gradle/caches/modules-2/files- > 2.1/com.github.kantega/notsoserial/f2baaaa/3646e12f5ce4713f9 > ad2aa027e3fec81097fcd93/notsoserial-f2baaaa.jar", > "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoserial/empty.txt", > "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/ > is-deserialized.txt", > "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/ > deserialize-trace.txt"] > @@ -52,6 +52,7 @@ > allprojects { > repositories{ > jcenter() > + maven { url "https://jitpack.io" } > } > } > > @@ -119,6 +120,7 @@ > compile 'org.zapodot:jackson-databind-java-optional:2.4.2' > compile 'oro:oro:2.0.8' > compile 'wsdl4j:wsdl4j:1.6.2' > + compile 'com.github.kantega:notsoserial:f2baaaa' > > // general framework runtime libs > runtime 'de.odysseus.juel:juel-spi:2.2.7' > > I think you get the idea, it works w/o any other modifications, what to > you think? > > Jacques > > > > Le 07/09/2016 à 22:37, Jacques Le Roux a écrit : > >> OK, since we have no issues OOTB that can be done. >> >> But IMO documenting the whole thing in our nososerial readme.txt is not >> enough. We need to make that more prominent. Not sure how yet... >> >> Jacques >> >> >> Le 07/09/2016 à 20:09, Taher Alkhateeb a écrit : >> >>> Scratch that, actually only the -D arguments are ignored, we must remove >>> the -javaagent argument because it's not a classpath argument and would >>> crash the VM >>> >>> But for consistency's sake, let's remove them all for now. So simply we >>> apply: >>> >>> Index: build.gradle >>> =================================================================== >>> --- build.gradle (revision 1759596) >>> +++ build.gradle (working copy) >>> @@ -31,11 +31,7 @@ >>> ext.os = System.getProperty('os.name').toLowerCase() >>> >>> // java settings >>> -def jvmArguments = ['-Xms128M', '-Xmx1024M', >>> - >>> "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria >>> l-1.0-SNAPSHOT.jar", >>> - >>> "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoseri >>> al/empty.txt", >>> - >>> "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/ >>> is-deserialized.txt", >>> - >>> "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/ >>> deserialize-trace.txt"] >>> +def jvmArguments = ['-Xms128M', '-Xmx1024M'] >>> ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start' >>> javadoc.failOnError = false >>> sourceCompatibility = '1.8' >>> >>> On Wed, Sep 7, 2016 at 9:04 PM, Jacques Le Roux < >>> [hidden email]> wrote: >>> >>> OK Cool, if the JVM arguments are simply ignored, then I will proceed >>>> with >>>> an addition in the readme and remove the jar, simple >>>> >>>> Jacques >>>> >>>> >>>> >>>> Le 07/09/2016 à 17:16, Jacopo Cappellato a écrit : >>>> >>>> Thank you Jacques and Taher. >>>>> >>>>> So it seems we can move on and temporarily remove the jar. >>>>> >>>>> Jacopo >>>>> >>>>> >>>>> On Wed, Sep 7, 2016 at 5:11 PM, Taher Alkhateeb < >>>>> [hidden email]> >>>>> wrote: >>>>> >>>>> Hi Jacques, >>>>> >>>>>> First of all the ofbizSecure task is gone instead everything calls the >>>>>> correct jvm arguments by default to fetch notsoserial. >>>>>> >>>>>> The work to remove notsoserial is almost nothing. You just to remove a >>>>>> few >>>>>> jvm args and that's it. Even if you don't remove the jvm args nothing >>>>>> happens because it will just ignore it as missing from the classpath. >>>>>> >>>>>> Taher Alkhateeb >>>>>> >>>>>> On Sep 7, 2016 5:48 PM, "Jacques Le Roux" < >>>>>> [hidden email]> >>>>>> wrote: >>>>>> >>>>>> Huho, I was too fast on this. Currently the Gradle "ofbizSecure" tasks >>>>>> >>>>>>> depends on the notsoserial-1.0-SNAPSHOT.jar >>>>>>> >>>>>>> So this would need more work and w/o answers from them I suspect they >>>>>>> >>>>>>> will >>>>>> >>>>>> not publish the jar. >>>>>>> >>>>>>> Now it's a serious security but not OOTB. So I see 2 possibilities. >>>>>>> >>>>>>> 1. Ask the ASF for a derogation (after all it's a Java issue not an >>>>>>> OFBiz >>>>>>> one) >>>>>>> 2. Do what I said before AND change the Gradle "ofbizSecure" tasks >>>>>>> >>>>>>> Opinions? >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> >>>>>>> Le 07/09/2016 à 14:01, Jacques Le Roux a écrit : >>>>>>> >>>>>>> Yes I see no problems with that. I just need to add directions for >>>>>>> users >>>>>>> >>>>>>>> before. I'll then remove the jars... very soon... >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> >>>>>>>> Le 07/09/2016 à 13:09, Jacopo Cappellato a écrit : >>>>>>>> >>>>>>>> Jacques, any news from notsoserial? >>>>>>>> >>>>>>>>> If not, I think we can proceed by (temporarily) removing the jars >>>>>>>>> until >>>>>>>>> they will publish the jar. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Jacopo >>>>>>>>> >>>>>>>>> On Sat, Aug 20, 2016 at 11:12 AM, Jacques Le Roux < >>>>>>>>> [hidden email]> wrote: >>>>>>>>> >>>>>>>>> Yes that's what I proposed also, I will try that before the worse >>>>>>>>> >>>>>>>>> solution >>>>>>>>>> as Taher called them, would you help? >>>>>>>>>> >>>>>>>>>> Jacques >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Le 20/08/2016 à 08:32, Pierre Smits a écrit : >>>>>>>>>> >>>>>>>>>> Hi Jacques, >>>>>>>>>> >>>>>>>>>> Why not try to convince the people behind notsoserial to have them >>>>>>>>>>> >>>>>>>>>>> push >>>>>>>>>> >>>>>>>>> the >>>>>>> >>>>>>>> library to maven central and/or jpublish? In stead of this community >>>>>>>>>>> doing >>>>>>>>>>> the work? >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Pierre Smits >>>>>>>>>>> >>>>>>>>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>>>>>>>> OFBiz based solutions & services >>>>>>>>>>> >>>>>>>>>>> OFBiz Extensions Marketplace >>>>>>>>>>> http://oem.ofbizci.net/oci-2/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> > |
Re: Taking a decision on remaining Jars in OFBiz
|
|
In reply to this post by Jacques Le Roux
I would feel more comfortable in releasing without it, and then work on the
proposed solutions with more time in order to implement the best solution. We could always bundle it in another release soon: in fact with all the activity in the project, we should consider releasing more often. Jacopo On Thu, Sep 8, 2016 at 8:23 AM, Jacques Le Roux < [hidden email]> wrote: > OK wait! I think we skipped a step: access the jar from an accessible repo. > > I see 2 solutions: > > 1. Push ourselves the notsoserial jar in jcenter => updating a fork now > and then, though notsoserial will not need much changes now > 2. Use https://jitpack.io/ > > I prefer 2, though I have still to > > * resolve the notsoserial.jar path in my hasty proposition below > * use|master-SNAPSHOT| instead of last hash (to not break on changes) > which may need to refresh dependencies (did not investigate yet: > https://jitpack.io/docs/#snapshots) > > Index: build.gradle > =================================================================== > --- build.gradle (revision 1759557) > +++ build.gradle (working copy) > @@ -32,7 +32,7 @@ > > // java settings > def jvmArguments = ['-Xms128M', '-Xmx1024M', > - "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria > l-1.0-SNAPSHOT.jar", > + "-javaagent:C:/Users/Jacques/.gradle/caches/modules-2/files- > 2.1/com.github.kantega/notsoserial/f2baaaa/3646e12f5ce4713f9 > ad2aa027e3fec81097fcd93/notsoserial-f2baaaa.jar", > "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoserial/empty.txt", > "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/ > is-deserialized.txt", > "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/ > deserialize-trace.txt"] > @@ -52,6 +52,7 @@ > allprojects { > repositories{ > jcenter() > + maven { url "https://jitpack.io" } > } > } > > @@ -119,6 +120,7 @@ > compile 'org.zapodot:jackson-databind-java-optional:2.4.2' > compile 'oro:oro:2.0.8' > compile 'wsdl4j:wsdl4j:1.6.2' > + compile 'com.github.kantega:notsoserial:f2baaaa' > > // general framework runtime libs > runtime 'de.odysseus.juel:juel-spi:2.2.7' > > I think you get the idea, it works w/o any other modifications, what to > you think? > > Jacques > > > > Le 07/09/2016 à 22:37, Jacques Le Roux a écrit : > >> OK, since we have no issues OOTB that can be done. >> >> But IMO documenting the whole thing in our nososerial readme.txt is not >> enough. We need to make that more prominent. Not sure how yet... >> >> Jacques >> >> >> Le 07/09/2016 à 20:09, Taher Alkhateeb a écrit : >> >>> Scratch that, actually only the -D arguments are ignored, we must remove >>> the -javaagent argument because it's not a classpath argument and would >>> crash the VM >>> >>> But for consistency's sake, let's remove them all for now. So simply we >>> apply: >>> >>> Index: build.gradle >>> =================================================================== >>> --- build.gradle (revision 1759596) >>> +++ build.gradle (working copy) >>> @@ -31,11 +31,7 @@ >>> ext.os = System.getProperty('os.name').toLowerCase() >>> >>> // java settings >>> -def jvmArguments = ['-Xms128M', '-Xmx1024M', >>> - >>> "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria >>> l-1.0-SNAPSHOT.jar", >>> - >>> "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoseri >>> al/empty.txt", >>> - >>> "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/ >>> is-deserialized.txt", >>> - >>> "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/ >>> deserialize-trace.txt"] >>> +def jvmArguments = ['-Xms128M', '-Xmx1024M'] >>> ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start' >>> javadoc.failOnError = false >>> sourceCompatibility = '1.8' >>> >>> On Wed, Sep 7, 2016 at 9:04 PM, Jacques Le Roux < >>> [hidden email]> wrote: >>> >>> OK Cool, if the JVM arguments are simply ignored, then I will proceed >>>> with >>>> an addition in the readme and remove the jar, simple >>>> >>>> Jacques >>>> >>>> >>>> >>>> Le 07/09/2016 à 17:16, Jacopo Cappellato a écrit : >>>> >>>> Thank you Jacques and Taher. >>>>> >>>>> So it seems we can move on and temporarily remove the jar. >>>>> >>>>> Jacopo >>>>> >>>>> >>>>> On Wed, Sep 7, 2016 at 5:11 PM, Taher Alkhateeb < >>>>> [hidden email]> >>>>> wrote: >>>>> >>>>> Hi Jacques, >>>>> >>>>>> First of all the ofbizSecure task is gone instead everything calls the >>>>>> correct jvm arguments by default to fetch notsoserial. >>>>>> >>>>>> The work to remove notsoserial is almost nothing. You just to remove a >>>>>> few >>>>>> jvm args and that's it. Even if you don't remove the jvm args nothing >>>>>> happens because it will just ignore it as missing from the classpath. >>>>>> >>>>>> Taher Alkhateeb >>>>>> >>>>>> On Sep 7, 2016 5:48 PM, "Jacques Le Roux" < >>>>>> [hidden email]> >>>>>> wrote: >>>>>> >>>>>> Huho, I was too fast on this. Currently the Gradle "ofbizSecure" tasks >>>>>> >>>>>>> depends on the notsoserial-1.0-SNAPSHOT.jar >>>>>>> >>>>>>> So this would need more work and w/o answers from them I suspect they >>>>>>> >>>>>>> will >>>>>> >>>>>> not publish the jar. >>>>>>> >>>>>>> Now it's a serious security but not OOTB. So I see 2 possibilities. >>>>>>> >>>>>>> 1. Ask the ASF for a derogation (after all it's a Java issue not an >>>>>>> OFBiz >>>>>>> one) >>>>>>> 2. Do what I said before AND change the Gradle "ofbizSecure" tasks >>>>>>> >>>>>>> Opinions? >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> >>>>>>> Le 07/09/2016 à 14:01, Jacques Le Roux a écrit : >>>>>>> >>>>>>> Yes I see no problems with that. I just need to add directions for >>>>>>> users >>>>>>> >>>>>>>> before. I'll then remove the jars... very soon... >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> >>>>>>>> Le 07/09/2016 à 13:09, Jacopo Cappellato a écrit : >>>>>>>> >>>>>>>> Jacques, any news from notsoserial? >>>>>>>> >>>>>>>>> If not, I think we can proceed by (temporarily) removing the jars >>>>>>>>> until >>>>>>>>> they will publish the jar. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Jacopo >>>>>>>>> >>>>>>>>> On Sat, Aug 20, 2016 at 11:12 AM, Jacques Le Roux < >>>>>>>>> [hidden email]> wrote: >>>>>>>>> >>>>>>>>> Yes that's what I proposed also, I will try that before the worse >>>>>>>>> >>>>>>>>> solution >>>>>>>>>> as Taher called them, would you help? >>>>>>>>>> >>>>>>>>>> Jacques >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Le 20/08/2016 à 08:32, Pierre Smits a écrit : >>>>>>>>>> >>>>>>>>>> Hi Jacques, >>>>>>>>>> >>>>>>>>>> Why not try to convince the people behind notsoserial to have them >>>>>>>>>>> >>>>>>>>>>> push >>>>>>>>>> >>>>>>>>> the >>>>>>> >>>>>>>> library to maven central and/or jpublish? In stead of this community >>>>>>>>>>> doing >>>>>>>>>>> the work? >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Pierre Smits >>>>>>>>>>> >>>>>>>>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>>>>>>>> OFBiz based solutions & services >>>>>>>>>>> >>>>>>>>>>> OFBiz Extensions Marketplace >>>>>>>>>>> http://oem.ofbizci.net/oci-2/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> > |
Re: Taking a decision on remaining Jars in OFBiz
|
Administrator
|
In reply to this post by taher
Taher,
Yes, as I said in a point below I had still to "resolve the notsoserial.jar path in my hasty proposition below". Defining a notsoerialFileNameWithPath String works. I just had to move the Java setting after the dependencies block to avoid a org.gradle.api.InvalidUserDataException Index: build.gradle =================================================================== --- build.gradle (revision 1759557) +++ build.gradle (working copy) @@ -30,12 +30,6 @@ // operating system property ext.os = System.getProperty('os.name').toLowerCase() -// java settings -def jvmArguments = ['-Xms128M', '-Xmx1024M', - "-javaagent:${rootDir}/tools/security/notsoserial/notsoserial-1.0-SNAPSHOT.jar", - "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoserial/empty.txt", - "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/is-deserialized.txt", - "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/deserialize-trace.txt"] ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start' javadoc.failOnError = false sourceCompatibility = '1.8' @@ -52,6 +46,7 @@ allprojects { repositories{ jcenter() + maven { url "https://jitpack.io" } } } @@ -119,6 +114,7 @@ compile 'org.zapodot:jackson-databind-java-optional:2.4.2' compile 'oro:oro:2.0.8' compile 'wsdl4j:wsdl4j:1.6.2' + compile 'com.github.kantega:notsoserial:f2baaaa' // general framework runtime libs runtime 'de.odysseus.juel:juel-spi:2.2.7' @@ -176,6 +172,16 @@ runtime files("${rootDir}/build/libs/ofbiz-base-test.jar") } +// Java settings, must be after the dependencies block to avoid a: org.gradle.api.InvalidUserDataException: +// Cannot change dependencies of configuration ':compile' after it has been resolved. +def notsoerialFileNameWithPath = project.configurations.compile.find { it.name.startsWith("notsoserial-") } +def jvmArguments = ['-Xms128M', '-Xmx1024M', + "-javaagent:" + notsoerialFileNameWithPath, + "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoserial/empty.txt", + "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/is-deserialized.txt", + "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/deserialize-trace.txt"] + + def excludedJavaSources = [] excludedJavaSources.add 'org/apache/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java' excludedJavaSources.add 'org/apache/ofbiz/accounting/thirdparty/ideal/IdealEvents.java' Jacques Le 08/09/2016 à 08:33, Taher Alkhateeb a écrit : > The above patch does not work Jacques, you are hard coding the path. This > needs to be properly developed. > > On Thu, Sep 8, 2016 at 9:23 AM, Jacques Le Roux < > [hidden email]> wrote: > >> OK wait! I think we skipped a step: access the jar from an accessible repo. >> >> I see 2 solutions: >> >> 1. Push ourselves the notsoserial jar in jcenter => updating a fork now >> and then, though notsoserial will not need much changes now >> 2. Use https://jitpack.io/ >> >> I prefer 2, though I have still to >> >> * resolve the notsoserial.jar path in my hasty proposition below >> * use|master-SNAPSHOT| instead of last hash (to not break on changes) >> which may need to refresh dependencies (did not investigate yet: >> https://jitpack.io/docs/#snapshots) >> >> Index: build.gradle >> =================================================================== >> --- build.gradle (revision 1759557) >> +++ build.gradle (working copy) >> @@ -32,7 +32,7 @@ >> >> // java settings >> def jvmArguments = ['-Xms128M', '-Xmx1024M', >> - "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria >> l-1.0-SNAPSHOT.jar", >> + "-javaagent:C:/Users/Jacques/.gradle/caches/modules-2/files- >> 2.1/com.github.kantega/notsoserial/f2baaaa/3646e12f5ce4713f9 >> ad2aa027e3fec81097fcd93/notsoserial-f2baaaa.jar", >> "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoserial/empty.txt", >> "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/ >> is-deserialized.txt", >> "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/ >> deserialize-trace.txt"] >> @@ -52,6 +52,7 @@ >> allprojects { >> repositories{ >> jcenter() >> + maven { url "https://jitpack.io" } >> } >> } >> >> @@ -119,6 +120,7 @@ >> compile 'org.zapodot:jackson-databind-java-optional:2.4.2' >> compile 'oro:oro:2.0.8' >> compile 'wsdl4j:wsdl4j:1.6.2' >> + compile 'com.github.kantega:notsoserial:f2baaaa' >> >> // general framework runtime libs >> runtime 'de.odysseus.juel:juel-spi:2.2.7' >> >> I think you get the idea, it works w/o any other modifications, what to >> you think? >> >> Jacques >> >> >> >> Le 07/09/2016 à 22:37, Jacques Le Roux a écrit : >> >>> OK, since we have no issues OOTB that can be done. >>> >>> But IMO documenting the whole thing in our nososerial readme.txt is not >>> enough. We need to make that more prominent. Not sure how yet... >>> >>> Jacques >>> >>> >>> Le 07/09/2016 à 20:09, Taher Alkhateeb a écrit : >>> >>>> Scratch that, actually only the -D arguments are ignored, we must remove >>>> the -javaagent argument because it's not a classpath argument and would >>>> crash the VM >>>> >>>> But for consistency's sake, let's remove them all for now. So simply we >>>> apply: >>>> >>>> Index: build.gradle >>>> =================================================================== >>>> --- build.gradle (revision 1759596) >>>> +++ build.gradle (working copy) >>>> @@ -31,11 +31,7 @@ >>>> ext.os = System.getProperty('os.name').toLowerCase() >>>> >>>> // java settings >>>> -def jvmArguments = ['-Xms128M', '-Xmx1024M', >>>> - >>>> "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria >>>> l-1.0-SNAPSHOT.jar", >>>> - >>>> "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoseri >>>> al/empty.txt", >>>> - >>>> "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/ >>>> is-deserialized.txt", >>>> - >>>> "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/ >>>> deserialize-trace.txt"] >>>> +def jvmArguments = ['-Xms128M', '-Xmx1024M'] >>>> ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start' >>>> javadoc.failOnError = false >>>> sourceCompatibility = '1.8' >>>> >>>> On Wed, Sep 7, 2016 at 9:04 PM, Jacques Le Roux < >>>> [hidden email]> wrote: >>>> >>>> OK Cool, if the JVM arguments are simply ignored, then I will proceed >>>>> with >>>>> an addition in the readme and remove the jar, simple >>>>> >>>>> Jacques >>>>> >>>>> >>>>> >>>>> Le 07/09/2016 à 17:16, Jacopo Cappellato a écrit : >>>>> >>>>> Thank you Jacques and Taher. >>>>>> So it seems we can move on and temporarily remove the jar. >>>>>> >>>>>> Jacopo >>>>>> >>>>>> >>>>>> On Wed, Sep 7, 2016 at 5:11 PM, Taher Alkhateeb < >>>>>> [hidden email]> >>>>>> wrote: >>>>>> >>>>>> Hi Jacques, >>>>>> >>>>>>> First of all the ofbizSecure task is gone instead everything calls the >>>>>>> correct jvm arguments by default to fetch notsoserial. >>>>>>> >>>>>>> The work to remove notsoserial is almost nothing. You just to remove a >>>>>>> few >>>>>>> jvm args and that's it. Even if you don't remove the jvm args nothing >>>>>>> happens because it will just ignore it as missing from the classpath. >>>>>>> >>>>>>> Taher Alkhateeb >>>>>>> >>>>>>> On Sep 7, 2016 5:48 PM, "Jacques Le Roux" < >>>>>>> [hidden email]> >>>>>>> wrote: >>>>>>> >>>>>>> Huho, I was too fast on this. Currently the Gradle "ofbizSecure" tasks >>>>>>> >>>>>>>> depends on the notsoserial-1.0-SNAPSHOT.jar >>>>>>>> >>>>>>>> So this would need more work and w/o answers from them I suspect they >>>>>>>> >>>>>>>> will >>>>>>> not publish the jar. >>>>>>>> Now it's a serious security but not OOTB. So I see 2 possibilities. >>>>>>>> >>>>>>>> 1. Ask the ASF for a derogation (after all it's a Java issue not an >>>>>>>> OFBiz >>>>>>>> one) >>>>>>>> 2. Do what I said before AND change the Gradle "ofbizSecure" tasks >>>>>>>> >>>>>>>> Opinions? >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> >>>>>>>> Le 07/09/2016 à 14:01, Jacques Le Roux a écrit : >>>>>>>> >>>>>>>> Yes I see no problems with that. I just need to add directions for >>>>>>>> users >>>>>>>> >>>>>>>>> before. I'll then remove the jars... very soon... >>>>>>>>> >>>>>>>>> Jacques >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 07/09/2016 à 13:09, Jacopo Cappellato a écrit : >>>>>>>>> >>>>>>>>> Jacques, any news from notsoserial? >>>>>>>>> >>>>>>>>>> If not, I think we can proceed by (temporarily) removing the jars >>>>>>>>>> until >>>>>>>>>> they will publish the jar. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Jacopo >>>>>>>>>> >>>>>>>>>> On Sat, Aug 20, 2016 at 11:12 AM, Jacques Le Roux < >>>>>>>>>> [hidden email]> wrote: >>>>>>>>>> >>>>>>>>>> Yes that's what I proposed also, I will try that before the worse >>>>>>>>>> >>>>>>>>>> solution >>>>>>>>>>> as Taher called them, would you help? >>>>>>>>>>> >>>>>>>>>>> Jacques >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Le 20/08/2016 à 08:32, Pierre Smits a écrit : >>>>>>>>>>> >>>>>>>>>>> Hi Jacques, >>>>>>>>>>> >>>>>>>>>>> Why not try to convince the people behind notsoserial to have them >>>>>>>>>>>> push >>>>>>>>>> the >>>>>>>>> library to maven central and/or jpublish? In stead of this community >>>>>>>>>>>> doing >>>>>>>>>>>> the work? >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Pierre Smits >>>>>>>>>>>> >>>>>>>>>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>>>>>>>>> OFBiz based solutions & services >>>>>>>>>>>> >>>>>>>>>>>> OFBiz Extensions Marketplace >>>>>>>>>>>> http://oem.ofbizci.net/oci-2/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>> |
Re: Taking a decision on remaining Jars in OFBiz
|
Administrator
|
In reply to this post by Jacopo Cappellato-5
Jacopo,
I agree about releasing more often. Then we need to prepare things better. Just few words, I have no ideas how to yet. You suggest "to implement the best solution". As I said below I see only 2. I don't expect Kantega will take the burden of pushing their jar to jcenter, even less on each modification, even if I now expect very few, if any. They even did not care to answer me! I don't like much the idea of maintaining a fork, who would do it? I prefer to automate it, and Gradle with JitPackIt can. My last proposition (answer to Taher) resolves the notsoserial problem. If we remove the jar and all the rest, I fear the notsoserial effort will be definitely thrown away, exposing our "naive" users at the risk of using RMI or a vulnerable external classes. BTW, when you say "We could always bundle it in another release soon" do you expect to freeze and release R16 very soon? Jacques Le 08/09/2016 à 08:47, Jacopo Cappellato a écrit : > I would feel more comfortable in releasing without it, and then work on the > proposed solutions with more time in order to implement the best solution. > We could always bundle it in another release soon: in fact with all the > activity in the project, we should consider releasing more often. > > Jacopo > > > > On Thu, Sep 8, 2016 at 8:23 AM, Jacques Le Roux < > [hidden email]> wrote: > >> OK wait! I think we skipped a step: access the jar from an accessible repo. >> >> I see 2 solutions: >> >> 1. Push ourselves the notsoserial jar in jcenter => updating a fork now >> and then, though notsoserial will not need much changes now >> 2. Use https://jitpack.io/ >> >> I prefer 2, though I have still to >> >> * resolve the notsoserial.jar path in my hasty proposition below >> * use|master-SNAPSHOT| instead of last hash (to not break on changes) >> which may need to refresh dependencies (did not investigate yet: >> https://jitpack.io/docs/#snapshots) >> >> Index: build.gradle >> =================================================================== >> --- build.gradle (revision 1759557) >> +++ build.gradle (working copy) >> @@ -32,7 +32,7 @@ >> >> // java settings >> def jvmArguments = ['-Xms128M', '-Xmx1024M', >> - "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria >> l-1.0-SNAPSHOT.jar", >> + "-javaagent:C:/Users/Jacques/.gradle/caches/modules-2/files- >> 2.1/com.github.kantega/notsoserial/f2baaaa/3646e12f5ce4713f9 >> ad2aa027e3fec81097fcd93/notsoserial-f2baaaa.jar", >> "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoserial/empty.txt", >> "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/ >> is-deserialized.txt", >> "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/ >> deserialize-trace.txt"] >> @@ -52,6 +52,7 @@ >> allprojects { >> repositories{ >> jcenter() >> + maven { url "https://jitpack.io" } >> } >> } >> >> @@ -119,6 +120,7 @@ >> compile 'org.zapodot:jackson-databind-java-optional:2.4.2' >> compile 'oro:oro:2.0.8' >> compile 'wsdl4j:wsdl4j:1.6.2' >> + compile 'com.github.kantega:notsoserial:f2baaaa' >> >> // general framework runtime libs >> runtime 'de.odysseus.juel:juel-spi:2.2.7' >> >> I think you get the idea, it works w/o any other modifications, what to >> you think? >> >> Jacques >> >> >> >> Le 07/09/2016 à 22:37, Jacques Le Roux a écrit : >> >>> OK, since we have no issues OOTB that can be done. >>> >>> But IMO documenting the whole thing in our nososerial readme.txt is not >>> enough. We need to make that more prominent. Not sure how yet... >>> >>> Jacques >>> >>> >>> Le 07/09/2016 à 20:09, Taher Alkhateeb a écrit : >>> >>>> Scratch that, actually only the -D arguments are ignored, we must remove >>>> the -javaagent argument because it's not a classpath argument and would >>>> crash the VM >>>> >>>> But for consistency's sake, let's remove them all for now. So simply we >>>> apply: >>>> >>>> Index: build.gradle >>>> =================================================================== >>>> --- build.gradle (revision 1759596) >>>> +++ build.gradle (working copy) >>>> @@ -31,11 +31,7 @@ >>>> ext.os = System.getProperty('os.name').toLowerCase() >>>> >>>> // java settings >>>> -def jvmArguments = ['-Xms128M', '-Xmx1024M', >>>> - >>>> "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria >>>> l-1.0-SNAPSHOT.jar", >>>> - >>>> "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoseri >>>> al/empty.txt", >>>> - >>>> "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/ >>>> is-deserialized.txt", >>>> - >>>> "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/ >>>> deserialize-trace.txt"] >>>> +def jvmArguments = ['-Xms128M', '-Xmx1024M'] >>>> ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start' >>>> javadoc.failOnError = false >>>> sourceCompatibility = '1.8' >>>> >>>> On Wed, Sep 7, 2016 at 9:04 PM, Jacques Le Roux < >>>> [hidden email]> wrote: >>>> >>>> OK Cool, if the JVM arguments are simply ignored, then I will proceed >>>>> with >>>>> an addition in the readme and remove the jar, simple >>>>> >>>>> Jacques >>>>> >>>>> >>>>> >>>>> Le 07/09/2016 à 17:16, Jacopo Cappellato a écrit : >>>>> >>>>> Thank you Jacques and Taher. >>>>>> So it seems we can move on and temporarily remove the jar. >>>>>> >>>>>> Jacopo >>>>>> >>>>>> >>>>>> On Wed, Sep 7, 2016 at 5:11 PM, Taher Alkhateeb < >>>>>> [hidden email]> >>>>>> wrote: >>>>>> >>>>>> Hi Jacques, >>>>>> >>>>>>> First of all the ofbizSecure task is gone instead everything calls the >>>>>>> correct jvm arguments by default to fetch notsoserial. >>>>>>> >>>>>>> The work to remove notsoserial is almost nothing. You just to remove a >>>>>>> few >>>>>>> jvm args and that's it. Even if you don't remove the jvm args nothing >>>>>>> happens because it will just ignore it as missing from the classpath. >>>>>>> >>>>>>> Taher Alkhateeb >>>>>>> >>>>>>> On Sep 7, 2016 5:48 PM, "Jacques Le Roux" < >>>>>>> [hidden email]> >>>>>>> wrote: >>>>>>> >>>>>>> Huho, I was too fast on this. Currently the Gradle "ofbizSecure" tasks >>>>>>> >>>>>>>> depends on the notsoserial-1.0-SNAPSHOT.jar >>>>>>>> >>>>>>>> So this would need more work and w/o answers from them I suspect they >>>>>>>> >>>>>>>> will >>>>>>> not publish the jar. >>>>>>>> Now it's a serious security but not OOTB. So I see 2 possibilities. >>>>>>>> >>>>>>>> 1. Ask the ASF for a derogation (after all it's a Java issue not an >>>>>>>> OFBiz >>>>>>>> one) >>>>>>>> 2. Do what I said before AND change the Gradle "ofbizSecure" tasks >>>>>>>> >>>>>>>> Opinions? >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> >>>>>>>> Le 07/09/2016 à 14:01, Jacques Le Roux a écrit : >>>>>>>> >>>>>>>> Yes I see no problems with that. I just need to add directions for >>>>>>>> users >>>>>>>> >>>>>>>>> before. I'll then remove the jars... very soon... >>>>>>>>> >>>>>>>>> Jacques >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 07/09/2016 à 13:09, Jacopo Cappellato a écrit : >>>>>>>>> >>>>>>>>> Jacques, any news from notsoserial? >>>>>>>>> >>>>>>>>>> If not, I think we can proceed by (temporarily) removing the jars >>>>>>>>>> until >>>>>>>>>> they will publish the jar. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Jacopo >>>>>>>>>> >>>>>>>>>> On Sat, Aug 20, 2016 at 11:12 AM, Jacques Le Roux < >>>>>>>>>> [hidden email]> wrote: >>>>>>>>>> >>>>>>>>>> Yes that's what I proposed also, I will try that before the worse >>>>>>>>>> >>>>>>>>>> solution >>>>>>>>>>> as Taher called them, would you help? >>>>>>>>>>> >>>>>>>>>>> Jacques >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Le 20/08/2016 à 08:32, Pierre Smits a écrit : >>>>>>>>>>> >>>>>>>>>>> Hi Jacques, >>>>>>>>>>> >>>>>>>>>>> Why not try to convince the people behind notsoserial to have them >>>>>>>>>>>> push >>>>>>>>>> the >>>>>>>>> library to maven central and/or jpublish? In stead of this community >>>>>>>>>>>> doing >>>>>>>>>>>> the work? >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Pierre Smits >>>>>>>>>>>> >>>>>>>>>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>>>>>>>>> OFBiz based solutions & services >>>>>>>>>>>> >>>>>>>>>>>> OFBiz Extensions Marketplace >>>>>>>>>>>> http://oem.ofbizci.net/oci-2/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>> |
|
|
I have a question. How many "naive" users will default to using RMI with
OFBiz? I think it was agreed long ago that RMI is a bad idea, and things like DCOM, CORBA and others died for a good reason. If someone is introducing RMI, they should handle the serialization vulnerabilities according to their own implementation, it's a choice. I really don't see a big need for this to be integrated into OFBiz OOTB. Even if you expose notsoserial, people still need to understand how it works and what to put into the configured text files. In fact, the knowledge needed to execute notsoserial correctly is rather high because you need to know which Java files are serializable and then which one of those are exposed in your implementation. So I recommend making this just an optional feature with good documentation in the Wiki where people can use it if they choose to adopt RMI, and we get this Jar out of the framework. On Thu, Sep 8, 2016 at 1:04 PM, Jacques Le Roux < [hidden email]> wrote: > Jacopo, > > I agree about releasing more often. Then we need to prepare things better. > Just few words, I have no ideas how to yet. > > You suggest "to implement the best solution". As I said below I see only > 2. I don't expect Kantega will take the burden of pushing their jar to > jcenter, even less on each modification, even if I now expect very few, if > any. They even did not care to answer me! > > I don't like much the idea of maintaining a fork, who would do it? I > prefer to automate it, and Gradle with JitPackIt can. My last proposition > (answer to Taher) resolves the notsoserial problem. > > If we remove the jar and all the rest, I fear the notsoserial effort will > be definitely thrown away, exposing our "naive" users at the risk of using > RMI or a vulnerable external classes. > > BTW, when you say "We could always bundle it in another release soon" do > you expect to freeze and release R16 very soon? > > Jacques > > > > Le 08/09/2016 à 08:47, Jacopo Cappellato a écrit : > >> I would feel more comfortable in releasing without it, and then work on >> the >> proposed solutions with more time in order to implement the best solution. >> We could always bundle it in another release soon: in fact with all the >> activity in the project, we should consider releasing more often. >> >> Jacopo >> >> >> >> On Thu, Sep 8, 2016 at 8:23 AM, Jacques Le Roux < >> [hidden email]> wrote: >> >> OK wait! I think we skipped a step: access the jar from an accessible >>> repo. >>> >>> I see 2 solutions: >>> >>> 1. Push ourselves the notsoserial jar in jcenter => updating a fork now >>> and then, though notsoserial will not need much changes now >>> 2. Use https://jitpack.io/ >>> >>> I prefer 2, though I have still to >>> >>> * resolve the notsoserial.jar path in my hasty proposition below >>> * use|master-SNAPSHOT| instead of last hash (to not break on changes) >>> which may need to refresh dependencies (did not investigate yet: >>> https://jitpack.io/docs/#snapshots) >>> >>> Index: build.gradle >>> =================================================================== >>> --- build.gradle (revision 1759557) >>> +++ build.gradle (working copy) >>> @@ -32,7 +32,7 @@ >>> >>> // java settings >>> def jvmArguments = ['-Xms128M', '-Xmx1024M', >>> - "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria >>> l-1.0-SNAPSHOT.jar", >>> + "-javaagent:C:/Users/Jacques/.gradle/caches/modules-2/files- >>> 2.1/com.github.kantega/notsoserial/f2baaaa/3646e12f5ce4713f9 >>> ad2aa027e3fec81097fcd93/notsoserial-f2baaaa.jar", >>> "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoseri >>> al/empty.txt", >>> "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/ >>> is-deserialized.txt", >>> "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/ >>> deserialize-trace.txt"] >>> @@ -52,6 +52,7 @@ >>> allprojects { >>> repositories{ >>> jcenter() >>> + maven { url "https://jitpack.io" } >>> } >>> } >>> >>> @@ -119,6 +120,7 @@ >>> compile 'org.zapodot:jackson-databind-java-optional:2.4.2' >>> compile 'oro:oro:2.0.8' >>> compile 'wsdl4j:wsdl4j:1.6.2' >>> + compile 'com.github.kantega:notsoserial:f2baaaa' >>> >>> // general framework runtime libs >>> runtime 'de.odysseus.juel:juel-spi:2.2.7' >>> >>> I think you get the idea, it works w/o any other modifications, what to >>> you think? >>> >>> Jacques >>> >>> >>> >>> Le 07/09/2016 à 22:37, Jacques Le Roux a écrit : >>> >>> OK, since we have no issues OOTB that can be done. >>>> >>>> But IMO documenting the whole thing in our nososerial readme.txt is not >>>> enough. We need to make that more prominent. Not sure how yet... >>>> >>>> Jacques >>>> >>>> >>>> Le 07/09/2016 à 20:09, Taher Alkhateeb a écrit : >>>> >>>> Scratch that, actually only the -D arguments are ignored, we must remove >>>>> the -javaagent argument because it's not a classpath argument and would >>>>> crash the VM >>>>> >>>>> But for consistency's sake, let's remove them all for now. So simply we >>>>> apply: >>>>> >>>>> Index: build.gradle >>>>> =================================================================== >>>>> --- build.gradle (revision 1759596) >>>>> +++ build.gradle (working copy) >>>>> @@ -31,11 +31,7 @@ >>>>> ext.os = System.getProperty('os.name').toLowerCase() >>>>> >>>>> // java settings >>>>> -def jvmArguments = ['-Xms128M', '-Xmx1024M', >>>>> - >>>>> "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria >>>>> l-1.0-SNAPSHOT.jar", >>>>> - >>>>> "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoseri >>>>> al/empty.txt", >>>>> - >>>>> "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/ >>>>> is-deserialized.txt", >>>>> - >>>>> "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/ >>>>> deserialize-trace.txt"] >>>>> +def jvmArguments = ['-Xms128M', '-Xmx1024M'] >>>>> ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start' >>>>> javadoc.failOnError = false >>>>> sourceCompatibility = '1.8' >>>>> >>>>> On Wed, Sep 7, 2016 at 9:04 PM, Jacques Le Roux < >>>>> [hidden email]> wrote: >>>>> >>>>> OK Cool, if the JVM arguments are simply ignored, then I will proceed >>>>> >>>>>> with >>>>>> an addition in the readme and remove the jar, simple >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> >>>>>> Le 07/09/2016 à 17:16, Jacopo Cappellato a écrit : >>>>>> >>>>>> Thank you Jacques and Taher. >>>>>> >>>>>>> So it seems we can move on and temporarily remove the jar. >>>>>>> >>>>>>> Jacopo >>>>>>> >>>>>>> >>>>>>> On Wed, Sep 7, 2016 at 5:11 PM, Taher Alkhateeb < >>>>>>> [hidden email]> >>>>>>> wrote: >>>>>>> >>>>>>> Hi Jacques, >>>>>>> >>>>>>> First of all the ofbizSecure task is gone instead everything calls >>>>>>>> the >>>>>>>> correct jvm arguments by default to fetch notsoserial. >>>>>>>> >>>>>>>> The work to remove notsoserial is almost nothing. You just to >>>>>>>> remove a >>>>>>>> few >>>>>>>> jvm args and that's it. Even if you don't remove the jvm args >>>>>>>> nothing >>>>>>>> happens because it will just ignore it as missing from the >>>>>>>> classpath. >>>>>>>> >>>>>>>> Taher Alkhateeb >>>>>>>> >>>>>>>> On Sep 7, 2016 5:48 PM, "Jacques Le Roux" < >>>>>>>> [hidden email]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Huho, I was too fast on this. Currently the Gradle "ofbizSecure" >>>>>>>> tasks >>>>>>>> >>>>>>>> depends on the notsoserial-1.0-SNAPSHOT.jar >>>>>>>>> >>>>>>>>> So this would need more work and w/o answers from them I suspect >>>>>>>>> they >>>>>>>>> >>>>>>>>> will >>>>>>>>> >>>>>>>> not publish the jar. >>>>>>>> >>>>>>>>> Now it's a serious security but not OOTB. So I see 2 possibilities. >>>>>>>>> >>>>>>>>> 1. Ask the ASF for a derogation (after all it's a Java issue not an >>>>>>>>> OFBiz >>>>>>>>> one) >>>>>>>>> 2. Do what I said before AND change the Gradle "ofbizSecure" tasks >>>>>>>>> >>>>>>>>> Opinions? >>>>>>>>> >>>>>>>>> Jacques >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 07/09/2016 à 14:01, Jacques Le Roux a écrit : >>>>>>>>> >>>>>>>>> Yes I see no problems with that. I just need to add directions for >>>>>>>>> users >>>>>>>>> >>>>>>>>> before. I'll then remove the jars... very soon... >>>>>>>>>> >>>>>>>>>> Jacques >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Le 07/09/2016 à 13:09, Jacopo Cappellato a écrit : >>>>>>>>>> >>>>>>>>>> Jacques, any news from notsoserial? >>>>>>>>>> >>>>>>>>>> If not, I think we can proceed by (temporarily) removing the jars >>>>>>>>>>> until >>>>>>>>>>> they will publish the jar. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Jacopo >>>>>>>>>>> >>>>>>>>>>> On Sat, Aug 20, 2016 at 11:12 AM, Jacques Le Roux < >>>>>>>>>>> [hidden email]> wrote: >>>>>>>>>>> >>>>>>>>>>> Yes that's what I proposed also, I will try that before the worse >>>>>>>>>>> >>>>>>>>>>> solution >>>>>>>>>>> >>>>>>>>>>>> as Taher called them, would you help? >>>>>>>>>>>> >>>>>>>>>>>> Jacques >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Le 20/08/2016 à 08:32, Pierre Smits a écrit : >>>>>>>>>>>> >>>>>>>>>>>> Hi Jacques, >>>>>>>>>>>> >>>>>>>>>>>> Why not try to convince the people behind notsoserial to have >>>>>>>>>>>> them >>>>>>>>>>>> >>>>>>>>>>>>> push >>>>>>>>>>>>> >>>>>>>>>>>> the >>>>>>>>>>> >>>>>>>>>> library to maven central and/or jpublish? In stead of this >>>>>>>>>> community >>>>>>>>>> >>>>>>>>>>> doing >>>>>>>>>>>>> the work? >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Pierre Smits >>>>>>>>>>>>> >>>>>>>>>>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>>>>>>>>>> OFBiz based solutions & services >>>>>>>>>>>>> >>>>>>>>>>>>> OFBiz Extensions Marketplace >>>>>>>>>>>>> http://oem.ofbizci.net/oci-2/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> > |
Re: Taking a decision on remaining Jars in OFBiz
|
Administrator
|
In reply to this post by Jacques Le Roux
Also I see a great opportunity for JitPack, we could use it to maintain our plugins on GitHub...
Jacques Le 08/09/2016 à 11:28, Jacques Le Roux a écrit : > Taher, > > Yes, as I said in a point below I had still to "resolve the notsoserial.jar path in my hasty proposition below". > > Defining a notsoerialFileNameWithPath String works. I just had to move the Java setting after the dependencies block to avoid a > org.gradle.api.InvalidUserDataException > > Index: build.gradle > =================================================================== > --- build.gradle (revision 1759557) > +++ build.gradle (working copy) > @@ -30,12 +30,6 @@ > // operating system property > ext.os = System.getProperty('os.name').toLowerCase() > > -// java settings > -def jvmArguments = ['-Xms128M', '-Xmx1024M', > - "-javaagent:${rootDir}/tools/security/notsoserial/notsoserial-1.0-SNAPSHOT.jar", > - "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoserial/empty.txt", > - "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/is-deserialized.txt", > - "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/deserialize-trace.txt"] > ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start' > javadoc.failOnError = false > sourceCompatibility = '1.8' > @@ -52,6 +46,7 @@ > allprojects { > repositories{ > jcenter() > + maven { url "https://jitpack.io" } > } > } > > @@ -119,6 +114,7 @@ > compile 'org.zapodot:jackson-databind-java-optional:2.4.2' > compile 'oro:oro:2.0.8' > compile 'wsdl4j:wsdl4j:1.6.2' > + compile 'com.github.kantega:notsoserial:f2baaaa' > > // general framework runtime libs > runtime 'de.odysseus.juel:juel-spi:2.2.7' > @@ -176,6 +172,16 @@ > runtime files("${rootDir}/build/libs/ofbiz-base-test.jar") > } > > +// Java settings, must be after the dependencies block to avoid a: org.gradle.api.InvalidUserDataException: > +// Cannot change dependencies of configuration ':compile' after it has been resolved. > +def notsoerialFileNameWithPath = project.configurations.compile.find { it.name.startsWith("notsoserial-") } > +def jvmArguments = ['-Xms128M', '-Xmx1024M', > + "-javaagent:" + notsoerialFileNameWithPath, > + "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoserial/empty.txt", > + "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/is-deserialized.txt", > + "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/deserialize-trace.txt"] > + > + > def excludedJavaSources = [] > excludedJavaSources.add 'org/apache/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java' > excludedJavaSources.add 'org/apache/ofbiz/accounting/thirdparty/ideal/IdealEvents.java' > > Jacques > > > Le 08/09/2016 à 08:33, Taher Alkhateeb a écrit : >> The above patch does not work Jacques, you are hard coding the path. This >> needs to be properly developed. >> >> On Thu, Sep 8, 2016 at 9:23 AM, Jacques Le Roux < >> [hidden email]> wrote: >> >>> OK wait! I think we skipped a step: access the jar from an accessible repo. >>> >>> I see 2 solutions: >>> >>> 1. Push ourselves the notsoserial jar in jcenter => updating a fork now >>> and then, though notsoserial will not need much changes now >>> 2. Use https://jitpack.io/ >>> >>> I prefer 2, though I have still to >>> >>> * resolve the notsoserial.jar path in my hasty proposition below >>> * use|master-SNAPSHOT| instead of last hash (to not break on changes) >>> which may need to refresh dependencies (did not investigate yet: >>> https://jitpack.io/docs/#snapshots) >>> >>> Index: build.gradle >>> =================================================================== >>> --- build.gradle (revision 1759557) >>> +++ build.gradle (working copy) >>> @@ -32,7 +32,7 @@ >>> >>> // java settings >>> def jvmArguments = ['-Xms128M', '-Xmx1024M', >>> - "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria >>> l-1.0-SNAPSHOT.jar", >>> + "-javaagent:C:/Users/Jacques/.gradle/caches/modules-2/files- >>> 2.1/com.github.kantega/notsoserial/f2baaaa/3646e12f5ce4713f9 >>> ad2aa027e3fec81097fcd93/notsoserial-f2baaaa.jar", >>> "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoserial/empty.txt", >>> "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/ >>> is-deserialized.txt", >>> "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/ >>> deserialize-trace.txt"] >>> @@ -52,6 +52,7 @@ >>> allprojects { >>> repositories{ >>> jcenter() >>> + maven { url "https://jitpack.io" } >>> } >>> } >>> >>> @@ -119,6 +120,7 @@ >>> compile 'org.zapodot:jackson-databind-java-optional:2.4.2' >>> compile 'oro:oro:2.0.8' >>> compile 'wsdl4j:wsdl4j:1.6.2' >>> + compile 'com.github.kantega:notsoserial:f2baaaa' >>> >>> // general framework runtime libs >>> runtime 'de.odysseus.juel:juel-spi:2.2.7' >>> >>> I think you get the idea, it works w/o any other modifications, what to >>> you think? >>> >>> Jacques >>> >>> >>> >>> Le 07/09/2016 à 22:37, Jacques Le Roux a écrit : >>> >>>> OK, since we have no issues OOTB that can be done. >>>> >>>> But IMO documenting the whole thing in our nososerial readme.txt is not >>>> enough. We need to make that more prominent. Not sure how yet... >>>> >>>> Jacques >>>> >>>> >>>> Le 07/09/2016 à 20:09, Taher Alkhateeb a écrit : >>>> >>>>> Scratch that, actually only the -D arguments are ignored, we must remove >>>>> the -javaagent argument because it's not a classpath argument and would >>>>> crash the VM >>>>> >>>>> But for consistency's sake, let's remove them all for now. So simply we >>>>> apply: >>>>> >>>>> Index: build.gradle >>>>> =================================================================== >>>>> --- build.gradle (revision 1759596) >>>>> +++ build.gradle (working copy) >>>>> @@ -31,11 +31,7 @@ >>>>> ext.os = System.getProperty('os.name').toLowerCase() >>>>> >>>>> // java settings >>>>> -def jvmArguments = ['-Xms128M', '-Xmx1024M', >>>>> - >>>>> "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria >>>>> l-1.0-SNAPSHOT.jar", >>>>> - >>>>> "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoseri >>>>> al/empty.txt", >>>>> - >>>>> "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/ >>>>> is-deserialized.txt", >>>>> - >>>>> "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/ >>>>> deserialize-trace.txt"] >>>>> +def jvmArguments = ['-Xms128M', '-Xmx1024M'] >>>>> ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start' >>>>> javadoc.failOnError = false >>>>> sourceCompatibility = '1.8' >>>>> >>>>> On Wed, Sep 7, 2016 at 9:04 PM, Jacques Le Roux < >>>>> [hidden email]> wrote: >>>>> >>>>> OK Cool, if the JVM arguments are simply ignored, then I will proceed >>>>>> with >>>>>> an addition in the readme and remove the jar, simple >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> >>>>>> Le 07/09/2016 à 17:16, Jacopo Cappellato a écrit : >>>>>> >>>>>> Thank you Jacques and Taher. >>>>>>> So it seems we can move on and temporarily remove the jar. >>>>>>> >>>>>>> Jacopo >>>>>>> >>>>>>> >>>>>>> On Wed, Sep 7, 2016 at 5:11 PM, Taher Alkhateeb < >>>>>>> [hidden email]> >>>>>>> wrote: >>>>>>> >>>>>>> Hi Jacques, >>>>>>> >>>>>>>> First of all the ofbizSecure task is gone instead everything calls the >>>>>>>> correct jvm arguments by default to fetch notsoserial. >>>>>>>> >>>>>>>> The work to remove notsoserial is almost nothing. You just to remove a >>>>>>>> few >>>>>>>> jvm args and that's it. Even if you don't remove the jvm args nothing >>>>>>>> happens because it will just ignore it as missing from the classpath. >>>>>>>> >>>>>>>> Taher Alkhateeb >>>>>>>> >>>>>>>> On Sep 7, 2016 5:48 PM, "Jacques Le Roux" < >>>>>>>> [hidden email]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Huho, I was too fast on this. Currently the Gradle "ofbizSecure" tasks >>>>>>>> >>>>>>>>> depends on the notsoserial-1.0-SNAPSHOT.jar >>>>>>>>> >>>>>>>>> So this would need more work and w/o answers from them I suspect they >>>>>>>>> >>>>>>>>> will >>>>>>>> not publish the jar. >>>>>>>>> Now it's a serious security but not OOTB. So I see 2 possibilities. >>>>>>>>> >>>>>>>>> 1. Ask the ASF for a derogation (after all it's a Java issue not an >>>>>>>>> OFBiz >>>>>>>>> one) >>>>>>>>> 2. Do what I said before AND change the Gradle "ofbizSecure" tasks >>>>>>>>> >>>>>>>>> Opinions? >>>>>>>>> >>>>>>>>> Jacques >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 07/09/2016 à 14:01, Jacques Le Roux a écrit : >>>>>>>>> >>>>>>>>> Yes I see no problems with that. I just need to add directions for >>>>>>>>> users >>>>>>>>> >>>>>>>>>> before. I'll then remove the jars... very soon... >>>>>>>>>> >>>>>>>>>> Jacques >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Le 07/09/2016 à 13:09, Jacopo Cappellato a écrit : >>>>>>>>>> >>>>>>>>>> Jacques, any news from notsoserial? >>>>>>>>>> >>>>>>>>>>> If not, I think we can proceed by (temporarily) removing the jars >>>>>>>>>>> until >>>>>>>>>>> they will publish the jar. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Jacopo >>>>>>>>>>> >>>>>>>>>>> On Sat, Aug 20, 2016 at 11:12 AM, Jacques Le Roux < >>>>>>>>>>> [hidden email]> wrote: >>>>>>>>>>> >>>>>>>>>>> Yes that's what I proposed also, I will try that before the worse >>>>>>>>>>> >>>>>>>>>>> solution >>>>>>>>>>>> as Taher called them, would you help? >>>>>>>>>>>> >>>>>>>>>>>> Jacques >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Le 20/08/2016 à 08:32, Pierre Smits a écrit : >>>>>>>>>>>> >>>>>>>>>>>> Hi Jacques, >>>>>>>>>>>> >>>>>>>>>>>> Why not try to convince the people behind notsoserial to have them >>>>>>>>>>>>> push >>>>>>>>>>> the >>>>>>>>>> library to maven central and/or jpublish? In stead of this community >>>>>>>>>>>>> doing >>>>>>>>>>>>> the work? >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Pierre Smits >>>>>>>>>>>>> >>>>>>>>>>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>>>>>>>>>> OFBiz based solutions & services >>>>>>>>>>>>> >>>>>>>>>>>>> OFBiz Extensions Marketplace >>>>>>>>>>>>> http://oem.ofbizci.net/oci-2/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> > > |
Re: Taking a decision on remaining Jars in OFBiz
|
|
In reply to this post by Jacques Le Roux
On Thu, Sep 8, 2016 at 12:04 PM, Jacques Le Roux <
[hidden email]> wrote: > ... > If we remove the jar and all the rest, I fear the notsoserial effort will > be definitely thrown away, exposing our "naive" users at the risk of using > RMI or a vulnerable external classes. > Configuring OFBiz for production requires some steps to secure it; "naive" users are not exposed to the risk because RMI is disabled by default; if a more expert user will enable RMI then it would also take care of protecting from deserializazion driven attacks, if warned about them. > BTW, when you say "We could always bundle it in another release soon" do > you expect to freeze and release R16 very soon? I am sorry but I don't get your question. Jacopo |
Re: Taking a decision on remaining Jars in OFBiz
|
Administrator
|
Le 08/09/2016 à 12:42, Jacopo Cappellato a écrit :
> On Thu, Sep 8, 2016 at 12:04 PM, Jacques Le Roux < > [hidden email]> wrote: > >> ... >> If we remove the jar and all the rest, I fear the notsoserial effort will >> be definitely thrown away, exposing our "naive" users at the risk of using >> RMI or a vulnerable external classes. >> > Configuring OFBiz for production requires some steps to secure it; "naive" > users are not exposed to the risk because RMI is disabled by default; if a > more expert user will enable RMI then it would also take care of protecting > from deserializazion driven attacks, if warned about them. How do you expect to warn users about deserialization driven attacks? I mean people can have a such risk w/o using RMI, deserialization driven attacks are not only about RMI. > >> BTW, when you say "We could always bundle it in another release soon" do >> you expect to freeze and release R16 very soon? > I am sorry but I don't get your question. Simpler question: when would expect to bundle it? Jacques > > Jacopo > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |