Re: Taking a decision on remaining Jars in OFBiz

I'm not against this way and what proposed Jacopo earlier. I started here: https://cwiki.apache.org/confluence/display/OFBIZ/Keeping+OFBiz+secure Feel free to contribute Jacques Le 09/09/2016 à 08:17, Taher Alkhateeb a écrit : Yes I agree with you completely that we should provide solutions

Re: Taking a decision on remaining Jars in OFBiz

Yes I agree with you completely that we should provide solutions to help our users in their security issues. The only difference in our views is "methodology". To me I think better documentation (wiki, JavaDoc, etc) and cleaning code is a better approach than introducing a library that people migh

Re: Taking a decision on remaining Jars in OFBiz

OK At least I'd have try to convince you that proposing an OOTB solution to protect our users from dangers of Java deserialization is a good thing. We can remove the whole thing, let's go Jacques Le 08/09/2016 à 21:37, Taher Alkhateeb a écrit : In reply to your comments: I did not see any p

Re: Taking a decision on remaining Jars in OFBiz

In reply to your comments: I did not see any point of the ones you mentioned specific to OFBiz. All that I saw is a reference to an article that PayPal was attacked and that using JMX and JNDI might get you exposed with nothing specific to our project and no concrete examples. You want to make a t

Re: Taking a decision on remaining Jars in OFBiz

Le 08/09/2016 à 15:24, Jacopo Cappellato a écrit : On Thu, Sep 8, 2016 at 2:54 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: ... 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 ar

Re: Taking a decision on remaining Jars in OFBiz

> Which classes are you worried about as a vulnerability? You certainly know that we have no serialization vulnerabilities OOTB. Most of the external classes which were still a problem for us one year ago have been fixed. I documented that at https://cwiki.apache.org/confluence/display/OFBIZ/T

Re: Taking a decision on remaining Jars in OFBiz

Le 08/09/2016 à 17:23, Jacopo Cappellato a écrit : On Thu, Sep 8, 2016 at 5:01 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: But the topic is still there, hackers have all their time, and they will bite again... Well, the above is too generic statement and I would prefer you to d

Re: Taking a decision on remaining Jars in OFBiz

On Thu, Sep 8, 2016 at 5:01 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > But the topic is still there, hackers have all their time, and they will > bite again... Well, the above is too generic statement and I would prefer you to describe about specific attacks and weak points in

Re: Taking a decision on remaining Jars in OFBiz

Le 08/09/2016 à 07:17, Jacopo Cappellato a écrit : 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. This is the only thread I'm aware of http://markmail.org/message/5g76

Re: Taking a decision on remaining Jars in OFBiz

On Thu, Sep 8, 2016 at 2:54 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > ... > 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. In my opinion a messag

Re: Taking a decision on remaining Jars in OFBiz

In order to answer your question we have to qualify it. What is your definition within OFBiz of a deserialization attack. Perhaps give an example within this context of exactly what happens and how notsoserial prevents it. Which classes are you worried about as a vulnerability? On Thursday, 8 Sept

Re: Taking a decision on remaining Jars in OFBiz

It's no only about RMI, deserialization driven attacks can be done on vulnerable classes. I think by exposing notsoserial (ie by creating the deserialize-trace.txt and is-deserialized.txt files in tools\security\notsoserial) we offer a good chance to users to we warned about the possible risks

Re: Taking a decision on remaining Jars in OFBiz

Le 08/09/2016 à 12:42, Jacopo Cappellato a écrit : On Thu, Sep 8, 2016 at 12:04 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> 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

Re: Taking a decision on remaining Jars in OFBiz

On Thu, Sep 8, 2016 at 12:04 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> 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. > Configur

Re: Taking a decision on remaining Jars in OFBiz

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 notso

Re: Taking a decision on remaining Jars in OFBiz

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 the

Re: Taking a decision on remaining Jars in OFBiz

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 e

Re: Taking a decision on remaining Jars in OFBiz

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 Inde

Re: Taking a decision on remaining Jars in OFBiz

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

Re: Taking a decision on remaining Jars in OFBiz

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 < jacques.le.r...@les7arts.com> wrote: > OK wait! I think we skipped a step: access the jar from an accessible repo. > > I see 2 solutions: > >

Re: Taking a decision on remaining Jars in OFBiz

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 * r

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 en

Re: Taking a decision on remaining Jars in OFBiz

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 ar

Re: Taking a decision on remaining Jars in OFBiz

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

Re: Taking a decision on remaining Jars in OFBiz

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,

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 wrote: > Hi Jacques, > > First of all the ofbizSecure task is gone instead everything calls the > correct jvm arguments by default to fetch notsoseria

Re: Taking a decision on remaining Jars in OFBiz

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 becaus

Re: Taking a decision on remaining Jars in OFBiz

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

Re: Taking a decision on remaining Jars in OFBiz

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 the

Re: Taking a decision on remaining Jars in OFBiz

On Sat, Aug 20, 2016 at 8:29 AM, Jacopo Cappellato < jacopo.cappell...@hotwaxsystems.com> wrote: > > On Sat, Aug 20, 2016 at 7:57 AM, jler...@apache.org > wrote: > >> ... >> IMO we can delete the cmssite component jars they are only used in >> extensions of Dockbook and AFAIK we don't use them >>

Re: Taking a decision on remaining Jars in OFBiz

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 < jacques.le.r...@les7arts.com> wrote: > Yes that's what I proposed also, I will try that befo

Re: Taking a decision on remaining Jars in OFBiz

On Sat, Aug 20, 2016 at 11:10 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Le 20/08/2016 à 08:28, Jacopo Cappellato a écrit : > >> On Sat, Aug 20, 2016 at 7:57 AM, jler...@apache.org >> wrote: >> >> ... >>> ebaystore component we need to put in Attic? >>> >>> Either attic or (quot

Re: Taking a decision on remaining Jars in OFBiz

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 jpubl

Re: Taking a decision on remaining Jars in OFBiz

Le 20/08/2016 à 08:28, Jacopo Cappellato a écrit : On Sat, Aug 20, 2016 at 7:57 AM, jler...@apache.org 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

Re: Taking a decision on remaining Jars in OFBiz

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 OFBiz based solutions & services OFBiz Extensions Marketpl

Re: Taking a decision on remaining Jars in OFBiz

On Sat, Aug 20, 2016 at 7:57 AM, jler...@apache.org wrote: > ... > IMO we can delete the cmssite component jars they are only used in > extensions of Dockbook and AFAIK we don't use them > > +1 > > notsoserial-1.0-SNAPSHOT.jar we need to keep, maybe we could push it in > jcenter, but would be b

Re: Taking a decision on remaining Jars in OFBiz

On Sat, Aug 20, 2016 at 7:57 AM, jler...@apache.org 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

Re: Taking a decision on remaining Jars in OFBiz

Well done you Gil & Nicolas, great work. The framework is finally clean. Jacques I think requesting publishing in jcenter is a good idea. Worst case scenario might not be pretty (download and compile the jar ourselves as a subproject).

Re: Taking a decision on remaining Jars in OFBiz

Congrats for your work at r1756949 Gil and Nicolas! At r1756984 I have removed the base/lib and its reference in base ofbiz-component.xml So we have no longer any jars but - cmssite component - ebaystore component - the tools directory IMO we can delete the cmssite component jars they are on

Re: Taking a decision on remaining Jars in OFBiz

Le 14/08/2016 à 12:25, Taher Alkhateeb a écrit : Hi Jacques, That is actually a nice idea. debugOfbiz reads like a verb. What does debugOfbiz do? It debugs ofbiz :) I am not sure however, if task shortcuts apply to rule-tasks. Are you sure they work in the short form? I ask because rule tasks a

Re: Taking a decision on remaining Jars in OFBiz

Hi Jacques, That is actually a nice idea. debugOfbiz reads like a verb. What does debugOfbiz do? It debugs ofbiz :) I am not sure however, if task shortcuts apply to rule-tasks. Are you sure they work in the short form? I ask because rule tasks are constructed from regex so it would be weird if t

Re: Taking a decision on remaining Jars in OFBiz

Hi Taher, Inline Le 14/08/2016 à 09:31, Taher Alkhateeb a écrit : Hi Jacques, I removed ofbizSecure and ofbizBackgroundSecure in OFBIZ-7951 at r1756305. You can start working on renaming. When renaming the tasks, please make sure to update StartupCommandUtil.java and README.md to reflect the

Re: Taking a decision on remaining Jars in OFBiz

Hi Jacques, I removed ofbizSecure and ofbizBackgroundSecure in OFBIZ-7951 at r1756305. You can start working on renaming. When renaming the tasks, please make sure to update StartupCommandUtil.java and README.md to reflect the changed names. I think we also need to update the demos to use ofbiz i

Re: Taking a decision on remaining Jars in OFBiz

Hi Taher, I agree, to confirm: I'll revert my local changes (but removing the debug task), there are a breeze to "redo" anyway (not alike of course), it's just plain global S/R Then we will use "background" on trunk demo, when you will have done OFBIZ-7951 and I have renamed the ofbizBackgrou

Re: Taking a decision on remaining Jars in OFBiz

Hi jacques, Okay great thank you for the thorough explanation. So based on your feedback I think that it does not make any difference whether we keep or delete the ofbizSecure and ofbizBackgroundSecure because the work has to be done either way to ensure that the OOTB whitelist is satisfied and wh

Re: Taking a decision on remaining Jars in OFBiz

Le 12/08/2016 à 20:51, Taher Alkhateeb a écrit : Hi Jacques, Ok so I'm a little confused now. If the whitelist is incomplete and we did not exhaust the investigation, then why are we running the demo on ofbizSecure? The main reason is we have no known deserialization issues OOTB. Initially we

Re: Taking a decision on remaining Jars in OFBiz

Hi Jacques, Ok so I'm a little confused now. If the whitelist is incomplete and we did not exhaust the investigation, then why are we running the demo on ofbizSecure? Or actually, let me ask you in another why ... When should we prefer _not_ to have ofbizSecure and why? Taher Alkhateeb On Fri,

Re: Taking a decision on remaining Jars in OFBiz

I conceived the Ant secure target with demo in mind, thinking users would adapt it to their needs. On trunk demo we use an empty whitelist, and trace deserialization. And because it must run w/o manual intervention we don't reject deserialization, we trace them. At https://cwiki.apache.org/confl

Re: Taking a decision on remaining Jars in OFBiz

Hi Taher, I have to re-read the thread and I'll get back to this. Should not be too long now, I'll let you know... Jacqued Le 12/08/2016 à 16:27, Taher Alkhateeb a écrit : Hi Jacques, I created OFBIZ-7951 to remove ofbizSecure and ofbizBackgroundSecure. However, I understand you want to ren

Re: Taking a decision on remaining Jars in OFBiz

To be wait ! the result isn't to my taste ;) I'm currently work on it Nicolas Le 12/08/2016 à 12:27, Jacques Le Roux a écrit : Hi Nicolas, That's good news, what is the situation finally? :) Jacques Le 10/08/2016 à 08:25, Nicolas Malin a écrit : Taher I started with Gil the conversion on

Re: Taking a decision on remaining Jars in OFBiz

Hi Jacques, I created OFBIZ-7951 to remove ofbizSecure and ofbizBackgroundSecure. However, I understand you want to rename the tasks so I do not want to cross wires with you. Are you going to start your task anytime soon? Taher Alkhateeb On Fri, Aug 12, 2016 at 1:27 PM, Jacques Le Roux < jacques

Re: Taking a decision on remaining Jars in OFBiz

Hi Nicolas, That's good news, what is the situation finally? :) Jacques Le 10/08/2016 à 08:25, Nicolas Malin a écrit : Taher I started with Gil the conversion on my github https://github.com/nmalin/ApacheOFBiz/tree/replace-jpin-by-ezvcard work in progress ... ;) Nicolas On 2016-07-30 12:

Re: Taking a decision on remaining Jars in OFBiz

Taher I started with Gil the conversion on my github https://github.com/nmalin/ApacheOFBiz/tree/replace-jpin-by-ezvcard work in progress ... ;) Nicolas On 2016-07-30 12:53 (+0200), Nicolas Malin wrote: > Le 29/07/2016 %uFFFD 13:56, Taher Alkhateeb a %uFFFDcrit :> > > - ./framework/base/lib/jp

Re: Taking a decision on remaining Jars in OFBiz

Hi Scott, Yeah agreed. I think logging for failed serialization might be a bit heavy because you might need to use reflections or custom class loaders to dig around and provide useful messages. If a runtime exceptions bubbles up to main then it will show up in the console and I think this could be

Re: Taking a decision on remaining Jars in OFBiz

I would suggest enabling the whitelist by default, adding whatever classes OFBiz needs OOTB and then having a clear failure message in the logs when a custom class fails serialization. Would that work? Regards Scott On 6/08/2016 23:13, "Jacques Le Roux" wrote: > I'd not be against but we need

Re: Taking a decision on remaining Jars in OFBiz

On Sat, Aug 6, 2016 at 12:49 PM, Taher Alkhateeb wrote: > > [...} I suggest the following: > > - remove ofbizSecure and ofbizBackgroundSecure > - make all other server tasks secure by default (i.e. loading notsoserial > and all other jvm args which are currently used in ofbizSecure). This means >

Re: Taking a decision on remaining Jars in OFBiz

Hi Jacques, Yeah agreed. I guess I'll wait for a few days before starting a JIRA to see if people have an opinion on this. I'll also make sure to coordinate with you on buildbot Taher Alkhateeb On Aug 6, 2016 12:13 PM, "Jacques Le Roux" wrote: > I'd not be against but we need to be clear while

Re: Taking a decision on remaining Jars in OFBiz

I'd not be against but we need to be clear while documenting that it's not enough for security (when needed, users need to refer to the wiki page), a white list is necessary (again only when needed, not OOTB) I guess (at least I hope for them) most sysadmin, devops are aware of the possible iss

Re: Taking a decision on remaining Jars in OFBiz

Hi Jacques, As I referred to earlier I suggest the following: - remove ofbizSecure and ofbizBackgroundSecure - make all other server tasks secure by default (i.e. loading notsoserial and all other jvm args which are currently used in ofbizSecure). This means ofbiz, ofbizBackground and ofbizDebug

Re: Taking a decision on remaining Jars in OFBiz

Le 06/08/2016 à 11:43, Taher Alkhateeb a écrit : Hi Jacques, I think that filling the white list ,etc ... might be something to keep in the page on securing OFBiz (documentation). I prefer to have a direct link to notsoserial documentation to be sure it's up to date. That's what I did on the

Re: Taking a decision on remaining Jars in OFBiz

Hi Jacques, I think that filling the white list ,etc ... might be something to keep in the page on securing OFBiz (documentation). I understand your point about making it more "explicit" which makes sense, it has, however, the downside of making the users aware that there are different tasks to ru

Re: Taking a decision on remaining Jars in OFBiz

The idea is that by default the task does not do much. You have to follow the advices they give to make it really effective (filling a white list is the better way) That's why I separated it from the rest to make it more obvious for users. Currently "gradlew tasks" gives you this information P

Re: Taking a decision on remaining Jars in OFBiz

Hi Scott, Great idea! We would reduce the number of tasks for one thing (less is more). I doubt the notsoserial lib has any effect on performance, It just makes a few core classes in Java not serializable. I suggest we delete ofbizSecure and ofbizBackgroundSecure and make all the others secure by

Re: Taking a decision on remaining Jars in OFBiz

Why isn't whatever functionality 'ofbizSecure' provides, just included as part of the regular 'ofbiz' task? On 5 August 2016 at 21:35, Jacques Le Roux wrote: > Le 05/08/2016 à 11:21, Taher Alkhateeb a écrit : > >> +1 makes sense >> >> Should we also remove the tasks ofbizSecure and ofbizBackgrou

Re: Taking a decision on remaining Jars in OFBiz

Le 05/08/2016 à 11:21, Taher Alkhateeb a écrit : +1 makes sense Should we also remove the tasks ofbizSecure and ofbizBackgroundSecure and replace them with some scripts in /tools if people are not using them? (I assume we only use them with demos?) On Aug 5, 2016 10:07 AM, "Jacques Le Roux" wro

Re: Taking a decision on remaining Jars in OFBiz

+1 makes sense Should we also remove the tasks ofbizSecure and ofbizBackgroundSecure and replace them with some scripts in /tools if people are not using them? (I assume we only use them with demos?) On Aug 5, 2016 10:07 AM, "Jacques Le Roux" wrote: > Inline > > > Le 05/08/2016 à 10:33, Jacopo

Re: Taking a decision on remaining Jars in OFBiz

Inline Le 05/08/2016 à 10:33, Jacopo Cappellato a écrit : On Fri, Jul 29, 2016 at 1:56 PM, Taher Alkhateeb wrote: ... - ebaystore component The jars in the ebaystore components are licensed under the CDDL licence, that is addressed by the following ASF licensing rules: http://www.apache.o

Re: Taking a decision on remaining Jars in OFBiz

On Fri, Jul 29, 2016 at 1:56 PM, Taher Alkhateeb wrote: > ... - ebaystore component > The jars in the ebaystore components are licensed under the CDDL licence, that is addressed by the following ASF licensing rules: http://www.apache.org/legal/resolved.html#category-b I am not sure I fully gr

Re: Taking a decision on remaining Jars in OFBiz

Le 30/07/2016 à 12:53, Nicolas Malin a écrit : Le 29/07/2016 à 13:56, Taher Alkhateeb a écrit : - ./framework/base/lib/jpim-0.1.jar (used for contacts management) I propose to : * open an issue * remove the lib * comment the related break code applications/marketing/src/main/java/org/apache/of

Re: Taking a decision on remaining Jars in OFBiz

Le 29/07/2016 à 13:56, Taher Alkhateeb a écrit : - ./framework/base/lib/jpim-0.1.jar (used for contacts management) I propose to : * open an issue * remove the lib * comment the related break code applications/marketing/src/main/java/org/apache/ofbiz/sfa/vcard/VCard.java with a fixme * return

Re: Taking a decision on remaining Jars in OFBiz

Hi Taher, Inline Le 29/07/2016 à 13:56, Taher Alkhateeb a écrit : Hello Everyone, The total number of remaining jars in OFBiz is 13. We worked as hard as we can to remove everything but hit this limit. The jars belong to: - cmssite component - ebaystore component - the tools directory - one re

Taking a decision on remaining Jars in OFBiz

Hello Everyone, The total number of remaining jars in OFBiz is 13. We worked as hard as we can to remove everything but hit this limit. The jars belong to: - cmssite component - ebaystore component - the tools directory - one remaining library in framework (jpim) We need to take a decision on wha