Taking a decision on remaining Jars in OFBiz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
72 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Taking a decision on remaining Jars in OFBiz

taher
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 what to do next. I would like to propose the
following:

1- Delete all the jars for the cmssite component. Everything compiles and
all tests run.
2- Disable the ebaystore component (or alternatively delete it). The
libraries are hard to find relating to the ebay SDK and none seem to be
published in JCenter
3- delete ./tools/demo-backup/contrast-rO0.jar since it is not used in
Trunk as per my understanding from Jacques.

Also, we need ideas on what to do with the below jars (I'm out of fresh
ideas or solutions).
- ./tools/security/notsoserial/notsoserial-1.0-SNAPSHOT.jar (used in
ofbizSecure and ofbizBackgroundSecure tasks in Gradle)
- ./framework/base/lib/jpim-0.1.jar (used for contacts management)

Appreciate your feedback.

Regards,

Taher Alkhateeb
Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

Jacques Le Roux
Administrator
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 remaining library in framework (jpim)
>
> We need to take a decision on what to do next. I would like to propose the
> following:
>
> 1- Delete all the jars for the cmssite component. Everything compiles and
> all tests run.
> 2- Disable the ebaystore component (or alternatively delete it). The
> libraries are hard to find relating to the ebay SDK and none seem to be
> published in JCenter

For the above I think we need to check, discuss and agree

> 3- delete ./tools/demo-backup/contrast-rO0.jar since it is not used in
> Trunk as per my understanding from Jacques.

Done at revision: 1754606 . This is indeed no longer needed in trunk, only used in R13.07 and R12.04.

>
> Also, we need ideas on what to do with the below jars (I'm out of fresh
> ideas or solutions).
> - ./tools/security/notsoserial/notsoserial-1.0-SNAPSHOT.jar (used in
> ofbizSecure and ofbizBackgroundSecure tasks in Gradle)

This one we need a solution, we can't drop it like that, ultimate security relies on it (so far at Java 8, Java's fault). I suggest we upload it to
jcenter but I wonder why it was not done yet. I heard contrast-rO0.jar as improved, could be a solution but it seems it's not in jcenter as well, did
you check Maven's "repo"?

HTH

Jacques

> - ./framework/base/lib/jpim-0.1.jar (used for contacts management)
>
> Appreciate your feedback.
>
> Regards,
>
> Taher Alkhateeb
>

Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

Nicolas Malin-2
In reply to this post by taher
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 error when the service is call with explain the pb and all
contribution are welcome :)
Nicolas


Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

Nicolas Malin-2
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/ofbiz/sfa/vcard/VCard.java
> with a fixme
> * return error when the service is call with explain the pb and all
> contribution are welcome :)
> Nicolas
>
>
I found ez-vcard :
* https://bintray.com/mangstadt/maven/com.googlecode.ez-vcard%3Aez-vcard
* https://github.com/mangstadt/ez-vcard
I will check if we can replace jdim by this
Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

Jacopo Cappellato-5
In reply to this post by taher
On Fri, Jul 29, 2016 at 1:56 PM, Taher Alkhateeb <[hidden email]
> 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 grasp all the details but I think that it would be
safer, to be sure we adhere to the licensing policies, if we not bundle
these jars in our releases.
Based on the above, my preference is to remove these jars, disable the
component, add a README file to the component to explain how to download
the jars and deploy it.


> - the tools directory
>

In my opinion we should start thinking about moving this folder outside of
the trunk:

trunk
tags
branches
tools

Jacopo
Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

Jacques Le Roux
Administrator
Inline


Le 05/08/2016 à 10:33, Jacopo Cappellato a écrit :

> On Fri, Jul 29, 2016 at 1:56 PM, Taher Alkhateeb <[hidden email]
>> 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 grasp all the details but I think that it would be
> safer, to be sure we adhere to the licensing policies, if we not bundle
> these jars in our releases.
> Based on the above, my preference is to remove these jars, disable the
> component, add a README file to the component to explain how to download
> the jars and deploy it.

+1

>> - the tools directory
>>
> In my opinion we should start thinking about moving this folder outside of
> the trunk:
>
> trunk
> tags
> branches
> tools

+1, using svn:externals tools could be easily embedded in a main OFBiz working copy. BTW, the 2 sub-folders are mostly intended to be used in production

Jacques

>
> Jacopo
>

Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

taher
+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" <[hidden email]>
wrote:

> Inline
>
>
> Le 05/08/2016 à 10:33, Jacopo Cappellato a écrit :
>
>> On Fri, Jul 29, 2016 at 1:56 PM, Taher Alkhateeb <
>> [hidden email]
>>
>>> 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 grasp all the details but I think that it would be
>> safer, to be sure we adhere to the licensing policies, if we not bundle
>> these jars in our releases.
>> Based on the above, my preference is to remove these jars, disable the
>> component, add a README file to the component to explain how to download
>> the jars and deploy it.
>>
>
> +1
>
> - the tools directory
>>>
>>> In my opinion we should start thinking about moving this folder outside
>> of
>> the trunk:
>>
>> trunk
>> tags
>> branches
>> tools
>>
>
> +1, using svn:externals tools could be easily embedded in a main OFBiz
> working copy. BTW, the 2 sub-folders are mostly intended to be used in
> production
>
> Jacques
>
>
>> Jacopo
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

Jacques Le Roux
Administrator
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"<[hidden email]>
> wrote:

Nope, those are intended to be used in production if ever you need it.

See the warning there https://cwiki.apache.org/confluence/display/OFBIZ/Keeping+OFBiz+secure for details

Jacques

Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

Scott Gray-3
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 <[hidden email]>
wrote:

> 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"<[hidden email]>
>> wrote:
>>
>
> Nope, those are intended to be used in production if ever you need it.
>
> See the warning there https://cwiki.apache.org/confl
> uence/display/OFBIZ/Keeping+OFBiz+secure for details
>
> Jacques
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

taher
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 default (ofbiz, ofbizDebug, ofbizBackground).

Taher Alkhateeb

On Saturday, 6 August 2016, Scott Gray <[hidden email]> wrote:

> 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 <[hidden email]
> <javascript:;>>
> wrote:
>
> > 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"<[hidden email]
> <javascript:;>>
> >> wrote:
> >>
> >
> > Nope, those are intended to be used in production if ever you need it.
> >
> > See the warning there https://cwiki.apache.org/confl
> > uence/display/OFBIZ/Keeping+OFBiz+secure for details
> >
> > Jacques
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

Jacques Le Roux
Administrator
In reply to this post by Scott Gray-3
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

Pattern: ofbizSecure <Commands>: Execute OFBiz startup commands pre-loading the notsoserial Java agent
Pattern: ofbizBackgroundSecure <Commands>: Execute OFBiz startup commands in background (secure mode) and output to console.log

Jacques


Le 06/08/2016 à 03:33, Scott Gray a écrit :

> 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 <[hidden email]>
> wrote:
>
>> 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"<[hidden email]>
>>> wrote:
>>>
>> Nope, those are intended to be used in production if ever you need it.
>>
>> See the warning there https://cwiki.apache.org/confl
>> uence/display/OFBIZ/Keeping+OFBiz+secure for details
>>
>> Jacques
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

taher
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 run, and also
the rc scripts need to be modified to production and might be confusing
(ofbiz, ofbizBackground, ofbizBackgroundSecure, ofbizSecure) might be too
many options to choose from in a production environment.

No strong opinion, but I am suggesting to make it a little easier for
people with a less-is-more kind of approach.

Taher Alkhateeb

On Sat, Aug 6, 2016 at 11:44 AM, Jacques Le Roux <
[hidden email]> wrote:

> 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
>
> Pattern: ofbizSecure <Commands>: Execute OFBiz startup commands
> pre-loading the notsoserial Java agent
> Pattern: ofbizBackgroundSecure <Commands>: Execute OFBiz startup commands
> in background (secure mode) and output to console.log
>
> Jacques
>
>
>
> Le 06/08/2016 à 03:33, Scott Gray a écrit :
>
>> 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 <[hidden email]>
>> wrote:
>>
>> 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"<[hidden email]
>>>> >
>>>> wrote:
>>>>
>>>> Nope, those are intended to be used in production if ever you need it.
>>>
>>> See the warning there https://cwiki.apache.org/confl
>>> uence/display/OFBIZ/Keeping+OFBiz+secure for details
>>>
>>> Jacques
>>>
>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

Jacques Le Roux
Administrator
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 related wiki page

> 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 run, and also
> the rc scripts need to be modified to production and might be confusing
> (ofbiz, ofbizBackground, ofbizBackgroundSecure, ofbizSecure) might be too
> many options to choose from in a production environment.
>
> No strong opinion, but I am suggesting to make it a little easier for
> people with a less-is-more kind of approach.

What would you suggest? It seems to me that removing these options would degrade the information about rare but possible vulnerabilities

Jacques

>
> Taher Alkhateeb
>
> On Sat, Aug 6, 2016 at 11:44 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> 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
>>
>> Pattern: ofbizSecure <Commands>: Execute OFBiz startup commands
>> pre-loading the notsoserial Java agent
>> Pattern: ofbizBackgroundSecure <Commands>: Execute OFBiz startup commands
>> in background (secure mode) and output to console.log
>>
>> Jacques
>>
>>
>>
>> Le 06/08/2016 à 03:33, Scott Gray a écrit :
>>
>>> 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 <[hidden email]>
>>> wrote:
>>>
>>> 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"<[hidden email]
>>>>> wrote:
>>>>>
>>>>> Nope, those are intended to be used in production if ever you need it.
>>>> See the warning there https://cwiki.apache.org/confl
>>>> uence/display/OFBIZ/Keeping+OFBiz+secure for details
>>>>
>>>> Jacques
>>>>
>>>>
>>>>

Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

taher
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
- update the documentation so that users need not worry about calling any
secure tasks. So they only need to do custom work such as the whitelist,
etc ...

I am not sure but I think there is no performance penalty right? That is
why I suggest lumping them together.

Taher Alkhateeb

On Aug 6, 2016 11:40 AM, "Jacques Le Roux" <[hidden email]>
wrote:

> 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 related wiki page
>
> 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 run, and also
>> the rc scripts need to be modified to production and might be confusing
>> (ofbiz, ofbizBackground, ofbizBackgroundSecure, ofbizSecure) might be too
>> many options to choose from in a production environment.
>>
>> No strong opinion, but I am suggesting to make it a little easier for
>> people with a less-is-more kind of approach.
>>
>
> What would you suggest? It seems to me that removing these options would
> degrade the information about rare but possible vulnerabilities
>
> Jacques
>
>
>> Taher Alkhateeb
>>
>> On Sat, Aug 6, 2016 at 11:44 AM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>> 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
>>>
>>> Pattern: ofbizSecure <Commands>: Execute OFBiz startup commands
>>> pre-loading the notsoserial Java agent
>>> Pattern: ofbizBackgroundSecure <Commands>: Execute OFBiz startup commands
>>> in background (secure mode) and output to console.log
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 06/08/2016 à 03:33, Scott Gray a écrit :
>>>
>>> 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 <
>>>> [hidden email]>
>>>> wrote:
>>>>
>>>> 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"<jacques.le.roux@les7arts
>>>>>> .com
>>>>>> wrote:
>>>>>>
>>>>>> Nope, those are intended to be used in production if ever you need it.
>>>>>>
>>>>> See the warning there https://cwiki.apache.org/confl
>>>>> uence/display/OFBIZ/Keeping+OFBiz+secure for details
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

Jacques Le Roux
Administrator
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 issue, but simpler users need to be warned...

Jacques

Le 06/08/2016 à 12:49, Taher Alkhateeb a écrit :

> 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
> - update the documentation so that users need not worry about calling any
> secure tasks. So they only need to do custom work such as the whitelist,
> etc ...
>
> I am not sure but I think there is no performance penalty right? That is
> why I suggest lumping them together.
>
> Taher Alkhateeb
>
> On Aug 6, 2016 11:40 AM, "Jacques Le Roux" <[hidden email]>
> wrote:
>
>> 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 related wiki page
>>
>> 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 run, and also
>>> the rc scripts need to be modified to production and might be confusing
>>> (ofbiz, ofbizBackground, ofbizBackgroundSecure, ofbizSecure) might be too
>>> many options to choose from in a production environment.
>>>
>>> No strong opinion, but I am suggesting to make it a little easier for
>>> people with a less-is-more kind of approach.
>>>
>> What would you suggest? It seems to me that removing these options would
>> degrade the information about rare but possible vulnerabilities
>>
>> Jacques
>>
>>
>>> Taher Alkhateeb
>>>
>>> On Sat, Aug 6, 2016 at 11:44 AM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>> 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
>>>>
>>>> Pattern: ofbizSecure <Commands>: Execute OFBiz startup commands
>>>> pre-loading the notsoserial Java agent
>>>> Pattern: ofbizBackgroundSecure <Commands>: Execute OFBiz startup commands
>>>> in background (secure mode) and output to console.log
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> Le 06/08/2016 à 03:33, Scott Gray a écrit :
>>>>
>>>> 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 <
>>>>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>> 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"<jacques.le.roux@les7arts
>>>>>>> .com
>>>>>>> wrote:
>>>>>>>
>>>>>>> Nope, those are intended to be used in production if ever you need it.
>>>>>>>
>>>>>> See the warning there https://cwiki.apache.org/confl
>>>>>> uence/display/OFBIZ/Keeping+OFBiz+secure for details
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>>

Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

taher
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" <[hidden email]>
wrote:

> 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 issue, but simpler users need to be warned...
>
> Jacques
>
> Le 06/08/2016 à 12:49, Taher Alkhateeb a écrit :
>
>> 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
>> - update the documentation so that users need not worry about calling any
>> secure tasks. So they only need to do custom work such as the whitelist,
>> etc ...
>>
>> I am not sure but I think there is no performance penalty right? That is
>> why I suggest lumping them together.
>>
>> Taher Alkhateeb
>>
>> On Aug 6, 2016 11:40 AM, "Jacques Le Roux" <[hidden email]>
>> wrote:
>>
>> 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 related wiki page
>>>
>>> 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 run, and
>>>> also
>>>> the rc scripts need to be modified to production and might be confusing
>>>> (ofbiz, ofbizBackground, ofbizBackgroundSecure, ofbizSecure) might be
>>>> too
>>>> many options to choose from in a production environment.
>>>>
>>>> No strong opinion, but I am suggesting to make it a little easier for
>>>> people with a less-is-more kind of approach.
>>>>
>>>> What would you suggest? It seems to me that removing these options would
>>> degrade the information about rare but possible vulnerabilities
>>>
>>> Jacques
>>>
>>>
>>> Taher Alkhateeb
>>>>
>>>> On Sat, Aug 6, 2016 at 11:44 AM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>> 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
>>>>>
>>>>> Pattern: ofbizSecure <Commands>: Execute OFBiz startup commands
>>>>> pre-loading the notsoserial Java agent
>>>>> Pattern: ofbizBackgroundSecure <Commands>: Execute OFBiz startup
>>>>> commands
>>>>> in background (secure mode) and output to console.log
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>> Le 06/08/2016 à 03:33, Scott Gray a écrit :
>>>>>
>>>>> 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 <
>>>>>> [hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>> 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"<jacques.le.roux@les7arts
>>>>>>>> .com
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Nope, those are intended to be used in production if ever you need
>>>>>>>> it.
>>>>>>>>
>>>>>>>> See the warning there https://cwiki.apache.org/confl
>>>>>>> uence/display/OFBIZ/Keeping+OFBiz+secure for details
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

Jacopo Cappellato-5
In reply to this post by taher
On Sat, Aug 6, 2016 at 12:49 PM, Taher Alkhateeb <[hidden email]

> 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
> ofbiz, ofbizBackground and ofbizDebug
> - update the documentation so that users need not worry about calling any
> secure tasks. So they only need to do custom work such as the whitelist,
> etc ...
>
>
+1

Jacopo
Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

Scott Gray-3
In reply to this post by Jacques Le Roux
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" <[hidden email]> wrote:

> 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 issue, but simpler users need to be warned...
>
> Jacques
>
> Le 06/08/2016 à 12:49, Taher Alkhateeb a écrit :
>
>> 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
>> - update the documentation so that users need not worry about calling any
>> secure tasks. So they only need to do custom work such as the whitelist,
>> etc ...
>>
>> I am not sure but I think there is no performance penalty right? That is
>> why I suggest lumping them together.
>>
>> Taher Alkhateeb
>>
>> On Aug 6, 2016 11:40 AM, "Jacques Le Roux" <[hidden email]>
>> wrote:
>>
>> 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 related wiki page
>>>
>>> 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 run, and
>>>> also
>>>> the rc scripts need to be modified to production and might be confusing
>>>> (ofbiz, ofbizBackground, ofbizBackgroundSecure, ofbizSecure) might be
>>>> too
>>>> many options to choose from in a production environment.
>>>>
>>>> No strong opinion, but I am suggesting to make it a little easier for
>>>> people with a less-is-more kind of approach.
>>>>
>>>> What would you suggest? It seems to me that removing these options would
>>> degrade the information about rare but possible vulnerabilities
>>>
>>> Jacques
>>>
>>>
>>> Taher Alkhateeb
>>>>
>>>> On Sat, Aug 6, 2016 at 11:44 AM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>> 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
>>>>>
>>>>> Pattern: ofbizSecure <Commands>: Execute OFBiz startup commands
>>>>> pre-loading the notsoserial Java agent
>>>>> Pattern: ofbizBackgroundSecure <Commands>: Execute OFBiz startup
>>>>> commands
>>>>> in background (secure mode) and output to console.log
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>> Le 06/08/2016 à 03:33, Scott Gray a écrit :
>>>>>
>>>>> 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 <
>>>>>> [hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>> 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"<jacques.le.roux@les7arts
>>>>>>>> .com
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Nope, those are intended to be used in production if ever you need
>>>>>>>> it.
>>>>>>>>
>>>>>>>> See the warning there https://cwiki.apache.org/confl
>>>>>>> uence/display/OFBIZ/Keeping+OFBiz+secure for details
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

taher
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 enough for developers to investigate.

On Sunday, 7 August 2016, Scott Gray <[hidden email]> wrote:

> 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" <[hidden email]
> <javascript:;>> wrote:
>
> > 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 issue, but simpler users need to be warned...
> >
> > Jacques
> >
> > Le 06/08/2016 à 12:49, Taher Alkhateeb a écrit :
> >
> >> 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
> >> - update the documentation so that users need not worry about calling
> any
> >> secure tasks. So they only need to do custom work such as the whitelist,
> >> etc ...
> >>
> >> I am not sure but I think there is no performance penalty right? That is
> >> why I suggest lumping them together.
> >>
> >> Taher Alkhateeb
> >>
> >> On Aug 6, 2016 11:40 AM, "Jacques Le Roux" <
> [hidden email] <javascript:;>>
> >> wrote:
> >>
> >> 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 related wiki page
> >>>
> >>> 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 run, and
> >>>> also
> >>>> the rc scripts need to be modified to production and might be
> confusing
> >>>> (ofbiz, ofbizBackground, ofbizBackgroundSecure, ofbizSecure) might be
> >>>> too
> >>>> many options to choose from in a production environment.
> >>>>
> >>>> No strong opinion, but I am suggesting to make it a little easier for
> >>>> people with a less-is-more kind of approach.
> >>>>
> >>>> What would you suggest? It seems to me that removing these options
> would
> >>> degrade the information about rare but possible vulnerabilities
> >>>
> >>> Jacques
> >>>
> >>>
> >>> Taher Alkhateeb
> >>>>
> >>>> On Sat, Aug 6, 2016 at 11:44 AM, Jacques Le Roux <
> >>>> [hidden email] <javascript:;>> wrote:
> >>>>
> >>>> 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
> >>>>>
> >>>>> Pattern: ofbizSecure <Commands>: Execute OFBiz startup commands
> >>>>> pre-loading the notsoserial Java agent
> >>>>> Pattern: ofbizBackgroundSecure <Commands>: Execute OFBiz startup
> >>>>> commands
> >>>>> in background (secure mode) and output to console.log
> >>>>>
> >>>>> Jacques
> >>>>>
> >>>>>
> >>>>>
> >>>>> Le 06/08/2016 à 03:33, Scott Gray a écrit :
> >>>>>
> >>>>> 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 <
> >>>>>> [hidden email] <javascript:;>>
> >>>>>> wrote:
> >>>>>>
> >>>>>> 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"<jacques.le.roux@les7arts
> >>>>>>>> .com
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Nope, those are intended to be used in production if ever you need
> >>>>>>>> it.
> >>>>>>>>
> >>>>>>>> See the warning there https://cwiki.apache.org/confl
> >>>>>>> uence/display/OFBIZ/Keeping+OFBiz+secure for details
> >>>>>>>
> >>>>>>> Jacques
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Taking a decision on remaining Jars in OFBiz

Nicolas Malin-2
In reply to this post by Nicolas Malin-2
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 [hidden email] wrote:
> Le 29/07/2016 %uFFFD 13:56, Taher Alkhateeb a %uFFFDcrit :>
> > - ./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 error when the service is call with explain the pb and all >
> contribution are welcome :)>
> Nicolas>
>
>
>
--

Nicolas Malin
The apache way : Openness Technical decisions are made publicly
[hidden email]

8 rue des Déportés 37000 TOURS, 02 47 50 30 54
Apache OFBiz |  The Apache Way |  ofbiz-fr |  réseau LE
1234