Re: Taking a decision on remaining Jars in OFBiz

2016-09-09 Thread Jacques Le Roux 

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 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 might or might not use and that does
not have clear technical benefits laid out. Security is a big topic and
there are many areas to improve. Security issues like deserialization, XSS,
SQL injection and others usually reveal themselves in certain parts of the
code under certain conditions within a certain context. So it is always the
"details" that matter and why code is the absolute most important aspect of
security. What's the use of having a firewall for example if the only open
port has a vulnerability because of bad code?

So .. a good approach in my opinion is to have a wiki page up which
discusses among other things:
- How to introduce new libraries
- Explanation of java deserialization (and other security risks) and how to
mitigate it.
- Perhaps we can have a section on tools like notsoserial and others with
some code snippets showing when and how to use and for what reasons.
- best practices on securing ofbiz
- and any thing related to security you think is useful

In addition to that wiki page, we need to dig into the critical components
of the code base and refactor it and clean it up. Good clean code goes
hand-in-hand with secure code. So it is a win-win situation and the reason
why I was pushing hard for code refactoring.

WDYT? If you agree then we can work on a good well documented page all
about security and get help from everyone to have good well documented
material.

Taher Alkhateeb

On Sep 9, 2016 7:08 AM, "Jacques Le Roux" 
wrote:


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 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 technical decision of
having a library based on vague hypothetical grounds with references to
some articles about dangers of Java deserialization. This is like saying
I'm going to buy this lawn mower because it is great while you don't have
any grass in your backyard!

Also based on your feedback, the answer to your question "How do you
expect
to warn users about deserialization driven attacks?" is I don't! I try to
avoid being repetitive but OFBiz suffers from overusing too many
libraries.
It is hardly a good reason to add more because MAYBE some users will
develop software using some library that would expose THEIR system. Too
hypothetical and does not treat all corner cases and definitely does not
make the system more secure because anyone can simply ignore notsoserial,
or might choose a different solution. Personally I would not use it
because
it does not even have a release and the code base is hardly maintained or
touched, the proof of which is that the maintainer did not even reply to
your email.

So, in reference to your point "I wonder why both you and Jacopo reject my
proposed solution, any technical or other reasons?" I will let Jacopo
answer for his reasons, but mine are very simple. I think we should have
less libraries, less bloat, less "stuff" in OFBiz because we have a
problematic code base that needs a lot of pruning and refactoring.

I think if you really want to focus on security then the _real work_ is in
fixing code. Bad code is the biggest source of security problems, not
environment or tools. To make our project more secure is to focus on the
real critical issue... code!


On Thu, Sep 8, 2016 at 8:48 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

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/confl
uence/display/OFBIZ/The+infamous+Java+serialization+vulnerability

But still 6 months later: http://www.pcworld.com/article
/3026678/paypal-is-the-latest-victim-of-java-deserialization
-bugs-in-web-apps.html
So it's only about warning users about deserialization attacks. They are
maybe not totally aware of the issue. How to warn them efficiently? It
seems to me that my proposition does that.

Perhaps give an example within

Re: Taking a decision on remaining Jars in OFBiz

2016-09-09 Thread Taher Alkhateeb 
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 might or might not use and that does
not have clear technical benefits laid out. Security is a big topic and
there are many areas to improve. Security issues like deserialization, XSS,
SQL injection and others usually reveal themselves in certain parts of the
code under certain conditions within a certain context. So it is always the
"details" that matter and why code is the absolute most important aspect of
security. What's the use of having a firewall for example if the only open
port has a vulnerability because of bad code?

So .. a good approach in my opinion is to have a wiki page up which
discusses among other things:
- How to introduce new libraries
- Explanation of java deserialization (and other security risks) and how to
mitigate it.
- Perhaps we can have a section on tools like notsoserial and others with
some code snippets showing when and how to use and for what reasons.
- best practices on securing ofbiz
- and any thing related to security you think is useful

In addition to that wiki page, we need to dig into the critical components
of the code base and refactor it and clean it up. Good clean code goes
hand-in-hand with secure code. So it is a win-win situation and the reason
why I was pushing hard for code refactoring.

WDYT? If you agree then we can work on a good well documented page all
about security and get help from everyone to have good well documented
material.

Taher Alkhateeb

On Sep 9, 2016 7:08 AM, "Jacques Le Roux" 
wrote:

> 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 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 technical decision of
>> having a library based on vague hypothetical grounds with references to
>> some articles about dangers of Java deserialization. This is like saying
>> I'm going to buy this lawn mower because it is great while you don't have
>> any grass in your backyard!
>>
>> Also based on your feedback, the answer to your question "How do you
>> expect
>> to warn users about deserialization driven attacks?" is I don't! I try to
>> avoid being repetitive but OFBiz suffers from overusing too many
>> libraries.
>> It is hardly a good reason to add more because MAYBE some users will
>> develop software using some library that would expose THEIR system. Too
>> hypothetical and does not treat all corner cases and definitely does not
>> make the system more secure because anyone can simply ignore notsoserial,
>> or might choose a different solution. Personally I would not use it
>> because
>> it does not even have a release and the code base is hardly maintained or
>> touched, the proof of which is that the maintainer did not even reply to
>> your email.
>>
>> So, in reference to your point "I wonder why both you and Jacopo reject my
>> proposed solution, any technical or other reasons?" I will let Jacopo
>> answer for his reasons, but mine are very simple. I think we should have
>> less libraries, less bloat, less "stuff" in OFBiz because we have a
>> problematic code base that needs a lot of pruning and refactoring.
>>
>> I think if you really want to focus on security then the _real work_ is in
>> fixing code. Bad code is the biggest source of security problems, not
>> environment or tools. To make our project more secure is to focus on the
>> real critical issue... code!
>>
>>
>> On Thu, Sep 8, 2016 at 8:48 PM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> 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/confl
>>> uence/display/OFBIZ/The+infamous+Java+serialization+vulnerability
>>>
>>> But still 6 months later: http://www.pcworld.com/article
>>> /3026678/paypal-is-the-latest-victim-of-java-deserialization
>>> -bugs-in-web-apps.html
>>> So it's only about warning users about deserialization attacks. They are
>>> maybe not totally aware of the issue. How to warn them efficiently? It
>>> seems to me that my proposition does that.
>>>
>>> Perhaps give an example within this context of exactly what happens and

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread Jacques Le Roux 
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 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 technical decision of
having a library based on vague hypothetical grounds with references to
some articles about dangers of Java deserialization. This is like saying
I'm going to buy this lawn mower because it is great while you don't have
any grass in your backyard!

Also based on your feedback, the answer to your question "How do you expect
to warn users about deserialization driven attacks?" is I don't! I try to
avoid being repetitive but OFBiz suffers from overusing too many libraries.
It is hardly a good reason to add more because MAYBE some users will
develop software using some library that would expose THEIR system. Too
hypothetical and does not treat all corner cases and definitely does not
make the system more secure because anyone can simply ignore notsoserial,
or might choose a different solution. Personally I would not use it because
it does not even have a release and the code base is hardly maintained or
touched, the proof of which is that the maintainer did not even reply to
your email.

So, in reference to your point "I wonder why both you and Jacopo reject my
proposed solution, any technical or other reasons?" I will let Jacopo
answer for his reasons, but mine are very simple. I think we should have
less libraries, less bloat, less "stuff" in OFBiz because we have a
problematic code base that needs a lot of pruning and refactoring.

I think if you really want to focus on security then the _real work_ is in
fixing code. Bad code is the biggest source of security problems, not
environment or tools. To make our project more secure is to focus on the
real critical issue... code!


On Thu, Sep 8, 2016 at 8:48 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


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/confl
uence/display/OFBIZ/The+infamous+Java+serialization+vulnerability

But still 6 months later: http://www.pcworld.com/article
/3026678/paypal-is-the-latest-victim-of-java-deserialization
-bugs-in-web-apps.html
So it's only about warning users about deserialization attacks. They are
maybe not totally aware of the issue. How to warn them efficiently? It
seems to me that my proposition does that.


Perhaps give an example within this context of exactly what happens and

how notsoserial prevents it.
The article about Paypal above states "Security researchers warned at the
time that thousands of Java-based Web applications, *including custom-made
enterprise ones*, are likely vulnerable to this attack"
"[snip] it's likely that this type of  vulnerability exists in other
libraries as well, waiting to be discovered."
This is not FUD (PayPal!) and it's only 6 months old

About RMI, JMX is using it http://engineering.pivotal.io/
post/java-deserialization-jmx/ and if you want to dynamically monitor
things, you will use JMX, won't you?
About JNDI http://zerothoughts.tumblr.com/post/137831000514/spring-fram
ework-deserialization-rce
OK it's not about OFBiz, but those 2 are less than 6 months old. Who can
think that the problems is definitely resolved? It's not, it can't be.

So no, I have no examples to give you. But one thing I can say, is with
notsoserial running in secure mode in the background you will be notified
if any unexpected deserialization attempt happens.
https://github.com/kantega/notsoserial#rejecting-deserialization-entirely
I hope I have somehow answered your question. Can you answer mine?

Also, I wonder why both you and Jacopo reject my proposed solution, any
technical or other reasons?

We decided to use notsoserial by default, I don't see why we should change
now. I'd have a reassured mind if we committed my proposed change. I see no
reasons to not do it.

Jacques


Le 08/09/2016 à 15:16, Taher Alkhateeb a écrit :


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 September 2016, Jacques Le Roux <
jacques.le.r...@les7arts.com>
wrote:

It's no only about RMI, deserialization driven attacks can be done on

vulnerable classes.

I think by exposing notsoserial (ie by creating

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread Taher Alkhateeb 
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 technical decision of
having a library based on vague hypothetical grounds with references to
some articles about dangers of Java deserialization. This is like saying
I'm going to buy this lawn mower because it is great while you don't have
any grass in your backyard!

Also based on your feedback, the answer to your question "How do you expect
to warn users about deserialization driven attacks?" is I don't! I try to
avoid being repetitive but OFBiz suffers from overusing too many libraries.
It is hardly a good reason to add more because MAYBE some users will
develop software using some library that would expose THEIR system. Too
hypothetical and does not treat all corner cases and definitely does not
make the system more secure because anyone can simply ignore notsoserial,
or might choose a different solution. Personally I would not use it because
it does not even have a release and the code base is hardly maintained or
touched, the proof of which is that the maintainer did not even reply to
your email.

So, in reference to your point "I wonder why both you and Jacopo reject my
proposed solution, any technical or other reasons?" I will let Jacopo
answer for his reasons, but mine are very simple. I think we should have
less libraries, less bloat, less "stuff" in OFBiz because we have a
problematic code base that needs a lot of pruning and refactoring.

I think if you really want to focus on security then the _real work_ is in
fixing code. Bad code is the biggest source of security problems, not
environment or tools. To make our project more secure is to focus on the
real critical issue... code!


On Thu, Sep 8, 2016 at 8:48 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> > 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/confl
> uence/display/OFBIZ/The+infamous+Java+serialization+vulnerability
>
> But still 6 months later: http://www.pcworld.com/article
> /3026678/paypal-is-the-latest-victim-of-java-deserialization
> -bugs-in-web-apps.html
> So it's only about warning users about deserialization attacks. They are
> maybe not totally aware of the issue. How to warn them efficiently? It
> seems to me that my proposition does that.
>
> > Perhaps give an example within this context of exactly what happens and
> how notsoserial prevents it.
> The article about Paypal above states "Security researchers warned at the
> time that thousands of Java-based Web applications, *including custom-made
> enterprise ones*, are likely vulnerable to this attack"
> "[snip] it's likely that this type of  vulnerability exists in other
> libraries as well, waiting to be discovered."
> This is not FUD (PayPal!) and it's only 6 months old
>
> About RMI, JMX is using it http://engineering.pivotal.io/
> post/java-deserialization-jmx/ and if you want to dynamically monitor
> things, you will use JMX, won't you?
> About JNDI http://zerothoughts.tumblr.com/post/137831000514/spring-fram
> ework-deserialization-rce
> OK it's not about OFBiz, but those 2 are less than 6 months old. Who can
> think that the problems is definitely resolved? It's not, it can't be.
>
> So no, I have no examples to give you. But one thing I can say, is with
> notsoserial running in secure mode in the background you will be notified
> if any unexpected deserialization attempt happens.
> https://github.com/kantega/notsoserial#rejecting-deserialization-entirely
> I hope I have somehow answered your question. Can you answer mine?
>
> Also, I wonder why both you and Jacopo reject my proposed solution, any
> technical or other reasons?
>
> We decided to use notsoserial by default, I don't see why we should change
> now. I'd have a reassured mind if we committed my proposed change. I see no
> reasons to not do it.
>
> Jacques
>
>
> Le 08/09/2016 à 15:16, Taher Alkhateeb a écrit :
>
>> 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 September 2016, Jacques Le Roux <
>> jacques.le.r...@les7arts.com>
>> wrote:
>>
>> 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

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread Jacques Le Roux 

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 are not only about RMI.


In my opinion a message in the OFBiz README file or in our download page
would be more effective that the current content of
tools/security/notsoserial.


Why not explaining things better (how to, needs to be defined) in both OFBiz main README file (in root folder) and in our download page, while still 
using notsoserial with my proposition (no notsoserial jar bundled in the release, just compiled inline)







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?


Maybe simpler, but still not very clear: anyway, if you are asking about my
expectations for the creation of the release branch release16.09 and for
its subsequent release, then they are based on the output of the thread
with title "Creating a new release branch in preparation for the new
release": please refer to it. But in short I hope to create the branch by
the end of this week and then start the thread about how/when do the
release.


Thanks, that indeed answers my question.

Jacques



Jacopo



Jacques



Jacopo

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread Jacques Le Roux 

> 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/The+infamous+Java+serialization+vulnerability

But still 6 months later: 
http://www.pcworld.com/article/3026678/paypal-is-the-latest-victim-of-java-deserialization-bugs-in-web-apps.html
So it's only about warning users about deserialization attacks. They are maybe not totally aware of the issue. How to warn them efficiently? It seems 
to me that my proposition does that.


> Perhaps give an example within this context of exactly what happens and how 
notsoserial prevents it.
The article about Paypal above states "Security researchers warned at the time that thousands of Java-based Web applications, *including custom-made 
enterprise ones*, are likely vulnerable to this attack"

"[snip] it's likely that this type of  vulnerability exists in other libraries as 
well, waiting to be discovered."
This is not FUD (PayPal!) and it's only 6 months old

About RMI, JMX is using it http://engineering.pivotal.io/post/java-deserialization-jmx/ and if you want to dynamically monitor things, you will use 
JMX, won't you?

About JNDI 
http://zerothoughts.tumblr.com/post/137831000514/spring-framework-deserialization-rce
OK it's not about OFBiz, but those 2 are less than 6 months old. Who can think 
that the problems is definitely resolved? It's not, it can't be.

So no, I have no examples to give you. But one thing I can say, is with notsoserial running in secure mode in the background you will be notified if 
any unexpected deserialization attempt happens. https://github.com/kantega/notsoserial#rejecting-deserialization-entirely

I hope I have somehow answered your question. Can you answer mine?

Also, I wonder why both you and Jacopo reject my proposed solution, any 
technical or other reasons?

We decided to use notsoserial by default, I don't see why we should change now. I'd have a reassured mind if we committed my proposed change. I see no 
reasons to not do it.


Jacques

Le 08/09/2016 à 15:16, Taher Alkhateeb a écrit :

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 September 2016, Jacques Le Roux 
wrote:


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 of
deserialization driven attacks.

It's else difficult for inexperienced users in the security domain to
understand they are at risk and how to cope with it. This is actually the
purpose of the tools\security\notsoserial folder and its content.

I ask you the same question than I asked to Jacopo: "How do you expect to
warn users about deserialization driven attacks?"

Jacques


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


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 <
jacques.le.r...@les7arts.com> 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

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread Jacques Le Roux 

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 describe
about specific attacks and weak points in OFBiz that need to be secured by
notsoserial; and provide other examples of Java frameworks at the ASF and
how they have dealt with them.

Jacopo

As I said in my snipped message, I have no examples of "Java frameworks at the ASF" which are currently endangered and in the wiki page I created 
about that I think I already clearly explained the situation about OFBiz.

https://cwiki.apache.org/confluence/display/OFBIZ/The+infamous+Java+serialization+vulnerability

What can do notsoserial, if you use it rightly, is a bit like an antivirus, it protects you by advance. The principal difference is it knows exactly 
what to protect you against and it does it surely. Developers should always be on their guards about this hazard, why not using notsoserial?


Jacques

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread Jacopo Cappellato 
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 OFBiz that need to be secured by
notsoserial; and provide other examples of Java frameworks at the ASF and
how they have dealt with them.

Jacopo

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread Jacques Le Roux 

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/5g76algian2lhj2i
It seems not much (euphemism) was done after the discussion. But the topic is 
still there, hackers have all their time, and they will bite again...

Jacques

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread Jacopo Cappellato 
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 message in the OFBiz README file or in our download page
would be more effective that the current content of
tools/security/notsoserial.


>
>
>> 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?
>

Maybe simpler, but still not very clear: anyway, if you are asking about my
expectations for the creation of the release branch release16.09 and for
its subsequent release, then they are based on the output of the thread
with title "Creating a new release branch in preparation for the new
release": please refer to it. But in short I hope to create the branch by
the end of this week and then start the thread about how/when do the
release.

Jacopo


>
> Jacques
>
>
>> Jacopo
>>
>>
>

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread Taher Alkhateeb 
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 September 2016, Jacques Le Roux 
wrote:

> 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 of
> deserialization driven attacks.
>
> It's else difficult for inexperienced users in the security domain to
> understand they are at risk and how to cope with it. This is actually the
> purpose of the tools\security\notsoserial folder and its content.
>
> I ask you the same question than I asked to Jacopo: "How do you expect to
> warn users about deserialization driven attacks?"
>
> Jacques
>
>
> Le 08/09/2016 à 12:12, Taher Alkhateeb a écrit :
>
>> 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 <
>> jacques.le.r...@les7arts.com> 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 <
 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:
>
> 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/f2b/3646e12f5ce4713f9
> ad2aa027e3fec81097fcd93/notsoserial-f2b.jar",
>

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread Jacques Le Roux 

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 of deserialization driven attacks.


It's else difficult for inexperienced users in the security domain to understand they are at risk and how to cope with it. This is actually the 
purpose of the tools\security\notsoserial folder and its content.


I ask you the same question than I asked to Jacopo: "How do you expect to warn users 
about deserialization driven attacks?"

Jacques


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

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 <
jacques.le.r...@les7arts.com> 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 <
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:

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/f2b/3646e12f5ce4713f9
ad2aa027e3fec81097fcd93/notsoserial-f2b.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:f2b'

   // 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

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread Jacques Le Roux 

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

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread Jacopo Cappellato 
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.
>

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

2016-09-08 Thread 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:f2b'

 // 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 <
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:

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/f2b/3646e12f5ce4713f9
ad2aa027e3fec81097fcd93/notsoserial-f2b.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:f2b'

  // 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,

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread Taher Alkhateeb 
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 <
jacques.le.r...@les7arts.com> 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 <
>> 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:
>>>
>>> 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/f2b/3646e12f5ce4713f9
>>> ad2aa027e3fec81097fcd93/notsoserial-f2b.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:f2b'
>>>
>>>   // 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
>

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread Jacques Le Roux 

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 <
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:

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/f2b/3646e12f5ce4713f9
ad2aa027e3fec81097fcd93/notsoserial-f2b.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:f2b'

  // 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 <
jacques.le.r...@les7arts.com> 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 <
slidingfilame...@gmail.com>
wrote:

Hi Jacques,

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread Jacques Le Roux 

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:f2b'

 // 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 <
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:

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/f2b/3646e12f5ce4713f9
ad2aa027e3fec81097fcd93/notsoserial-f2b.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:f2b'

  // 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

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread Jacopo Cappellato 
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 <
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:
>
> 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/f2b/3646e12f5ce4713f9
> ad2aa027e3fec81097fcd93/notsoserial-f2b.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:f2b'
>
>  // 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 <
>>> jacques.le.r...@les7arts.com> 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 <
> slidingfilame...@gmail.com>
> 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" <
>> jacques.le.r...@les7arts.com>
>> wrote:
>>
>> Huho, I was too fast on this. Currently the Gradle "ofbizSecure"

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread Taher Alkhateeb 
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:
>
> 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/f2b/3646e12f5ce4713f9
> ad2aa027e3fec81097fcd93/notsoserial-f2b.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:f2b'
>
>  // 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 <
>>> jacques.le.r...@les7arts.com> 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 <
> slidingfilame...@gmail.com>
> 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" <
>> jacques.le.r...@les7arts.com>
>> 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

Re: Taking a decision on remaining Jars in OFBiz

2016-09-08 Thread 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/f2b/3646e12f5ce4713f9ad2aa027e3fec81097fcd93/notsoserial-f2b.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:f2b'

 // 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 <
jacques.le.r...@les7arts.com> 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 <
slidingfilame...@gmail.com>
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" 
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 <
jacques.le.r...@les7arts.com> wrote:

Yes

Re: Taking a decision on remaining Jars in OFBiz

2016-09-07 Thread Jacopo Cappellato 
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 <
jacques.le.r...@les7arts.com> 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 <
>> jacques.le.r...@les7arts.com> 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 <
 slidingfilame...@gmail.com>
 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" <
> jacques.le.r...@les7arts.com>
> 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 <
 jacques.le.r...@les7arts.com> 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

Re: Taking a decision on remaining Jars in OFBiz

2016-09-07 Thread Jacques Le Roux 

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 <
jacques.le.r...@les7arts.com> 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 <
slidingfilame...@gmail.com>
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" 
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 <
jacques.le.r...@les7arts.com> 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 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

Re: Taking a decision on remaining Jars in OFBiz

2016-09-07 Thread Taher Alkhateeb 
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 <
jacques.le.r...@les7arts.com> 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 <
>> slidingfilame...@gmail.com>
>> 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" 
>>> 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 <
>> jacques.le.r...@les7arts.com> 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 
 OFBiz based solutions & services

 OFBiz Extensions Marketplace
 http://oem.ofbizci.net/oci-2/




>
>

Re: Taking a decision on remaining Jars in OFBiz

2016-09-07 Thread Jacques Le Roux 

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 
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" 
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 <
jacques.le.r...@les7arts.com> 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 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

Re: Taking a decision on remaining Jars in OFBiz

2016-09-07 Thread Jacopo Cappellato 
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 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" 
> 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 <
> >>> jacques.le.r...@les7arts.com> 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 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> >
> >
> >>
> >>
> >
>

Re: Taking a decision on remaining Jars in OFBiz

2016-09-07 Thread Taher Alkhateeb 
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" 
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 <
>>> jacques.le.r...@les7arts.com> 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 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
>
>
>>
>>
>

Re: Taking a decision on remaining Jars in OFBiz

2016-09-07 Thread Jacques Le Roux 

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 <
jacques.le.r...@les7arts.com> 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 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

Re: Taking a decision on remaining Jars in OFBiz

2016-09-07 Thread Jacques Le Roux 

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 <
jacques.le.r...@les7arts.com> 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 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

Re: Taking a decision on remaining Jars in OFBiz

2016-09-07 Thread Jacopo Cappellato 
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
>>
>>
This is now done in rev. 1759593

Jacopo

Re: Taking a decision on remaining Jars in OFBiz

2016-09-07 Thread Jacopo Cappellato 
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 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 
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>>

Re: Taking a decision on remaining Jars in OFBiz

2016-09-07 Thread Jacopo Cappellato 
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 (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
>
>
This is now done in rev. 1759583

Jacopo

Re: Taking a decision on remaining Jars in OFBiz

2016-08-20 Thread Jacques Le Roux 

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

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Sat, Aug 20, 2016 at 7:57 AM, jler...@apache.org 
wrote:


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 only used in
extensions of Dockbook and AFAIK we don't use them

ebaystore component we need to put in Attic?

notsoserial-1.0-SNAPSHOT.jar we need to keep, maybe we could push it in
jcenter, but would be better if the author takes care of it, maybe we could
ask him?

Jacques



Le 12/08/2016 à 16:36, Nicolas Malin a écrit :


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 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/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>




--
logoNrd 
 Nicolas Malin
The apache way  : *Openness* Technical
decisions are made publicly
informat...@nereide.fr
8 rue des Déportés 37000 TOURS, 02 47 50 30 54

Apache OFBiz  | The Apache Way <
http://theapacheway.com/> | ofbiz-fr  |
réseau LE

Re: Taking a decision on remaining Jars in OFBiz

2016-08-20 Thread Jacques Le Roux 

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

Re: Taking a decision on remaining Jars in OFBiz

2016-08-20 Thread Pierre Smits 
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 Marketplace
http://oem.ofbizci.net/oci-2/

On Sat, Aug 20, 2016 at 7:57 AM, jler...@apache.org 
wrote:

> 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 only used in
> extensions of Dockbook and AFAIK we don't use them
>
> ebaystore component we need to put in Attic?
>
> notsoserial-1.0-SNAPSHOT.jar we need to keep, maybe we could push it in
> jcenter, but would be better if the author takes care of it, maybe we could
> ask him?
>
> Jacques
>
>
>
> Le 12/08/2016 à 16:36, Nicolas Malin a écrit :
>
>> 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 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/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>
 >
 >
 >
 --
 logoNrd 
 Nicolas Malin
 The apache way  : *Openness* Technical
 decisions are made publicly
 informat...@nereide.fr
 8 rue des Déportés 37000 TOURS, 02 47 50 30 54

 Apache OFBiz  | The Apache Way <
 http://theapacheway.com/> | ofbiz-fr  |
 réseau LE 

>>>
>>>
>>>
>>
>>

Re: Taking a decision on remaining Jars in OFBiz

2016-08-20 Thread Jacopo Cappellato 
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 better if the author takes care of it, maybe we could
> ask him?
>

+1

Re: Taking a decision on remaining Jars in OFBiz

2016-08-20 Thread Jacopo Cappellato 
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 and deploy it".

Jacopo

Re: Taking a decision on remaining Jars in OFBiz

2016-08-20 Thread Taher Alkhateeb 
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

2016-08-19 Thread jler...@apache.org 

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 only used in extensions 
of Dockbook and AFAIK we don't use them

ebaystore component we need to put in Attic?

notsoserial-1.0-SNAPSHOT.jar we need to keep, maybe we could push it in 
jcenter, but would be better if the author takes care of it, maybe we could ask 
him?

Jacques


Le 12/08/2016 à 16:36, Nicolas Malin a écrit :

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 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/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>
>
>
>
--
logoNrd 
Nicolas Malin
The apache way  : *Openness* Technical decisions are 
made publicly
informat...@nereide.fr
8 rue des Déportés 37000 TOURS, 02 47 50 30 54

Apache OFBiz  | The Apache Way  | ofbiz-fr  | réseau LE

Re: Taking a decision on remaining Jars in OFBiz

2016-08-14 Thread Jacques Le Roux 

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 are constructed from
regex so it would be weird if they do work.


Actually I did only try "g ta" for "gradlew tasks" and it worked. Unfortunately 
indeed shortcuts won't work for rule-tasks

So we need to type "gradlew ofbiz", "gradlew ofbizDebug" and "gradlew 
ofbizBackground" when using simplest form

It seems everybody prefer those than using shortcuts, so I prefer to let things 
as they are, I have just removed a dust I left at r1756319

Jacques



Taher Alkhateeb

On Aug 14, 2016 11:29 AM, "Jacques Le Roux" 
wrote:


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 changed names. I think we also need to update
the demos to use ofbiz instead of ofbizSecure right?


Yep, all that's planned



There is one slight disadvantage of renaming ofbizBackground to background
and ofbizDebug to debug in that it does not become obvious to users that
this is an ofbiz server command (they all start with the word ofbiz).
There
is also a small chance of name clashing with plugins that we might
introduce in the future. I'm stating this here in case we face such an
issue in the future to be aware of it and fix it.


Mmm... this is something I did not think about. I'll rather rename them
debugOfbiz and backgroundOfbiz in order to keep the the differentiation.
Still the shortcuts can be used :)

Jacques



Taher Alkhateeb

On Sat, Aug 13, 2016 at 1:23 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

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 ofbizBackground pattern to background

BuildBot is another thing, it notably builds and test so does not need a
secure task, it loads demo data and tests. As a committer you can see the
script here https://svn.apache.org/repos/infra/infrastructure/buildbot/a
egis/buildmaster/master1/projects/ofbiz.conf

I need to update and complete the wiki documentation regarding Gradle and
I trust you about explaining things in the README.MD

I'll make obvious that by default we only trace and not reject
deserialisation

Jacques



Le 13/08/2016 à 00:01, Taher Alkhateeb a écrit :

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
whether
notsoserial is default or not does not affect anyone during development
or
production. So I think we can safely remove these tasks and default them
into the other tasks, the completion of the whitelist is another task
for
another day.

Can I go ahead with the task or are you currently working on
intersecting
work? Would you mind helping out in switching buildbot to ofbiz instead
of
ofbizSecure?

Taher Alkhateeb

On Fri, Aug 12, 2016 at 11:22 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

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 had issues and I planned to complete the list. But then
thought that anyway, since we run it only during a day, it will never
be
complete and I gave up.

Or actually, let me ask you in another why ... When should we prefer
_not_

to have ofbizSecure and why?

When you are sure to not have any deserialization issues. For
instance,


as
soon as you introduce RMI you are at risk. Notsoserial has a list of
know
issues https://github.com/kantega/notsoserial#which-classes-are-rej
ected
Note that we don't have these issues in OFBiz: see OFBIZ-6726,
OFBIZ-6568
and OFBIZ-6942 as explained at https://cwiki.apache.org/confl
uence/display/OFBIZ/The+infamous+Java+serialization+vulnerability

Jacques




Taher Alkhateeb


On Fri, Aug 12, 2016 at 9:42 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

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

Re: Taking a decision on remaining Jars in OFBiz

2016-08-14 Thread Taher Alkhateeb 
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 they do work.

Taher Alkhateeb

On Aug 14, 2016 11:29 AM, "Jacques Le Roux" 
wrote:

> 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 changed names. I think we also need to update
>> the demos to use ofbiz instead of ofbizSecure right?
>>
>
> Yep, all that's planned
>
>
>> There is one slight disadvantage of renaming ofbizBackground to background
>> and ofbizDebug to debug in that it does not become obvious to users that
>> this is an ofbiz server command (they all start with the word ofbiz).
>> There
>> is also a small chance of name clashing with plugins that we might
>> introduce in the future. I'm stating this here in case we face such an
>> issue in the future to be aware of it and fix it.
>>
>
> Mmm... this is something I did not think about. I'll rather rename them
> debugOfbiz and backgroundOfbiz in order to keep the the differentiation.
> Still the shortcuts can be used :)
>
> Jacques
>
>
>> Taher Alkhateeb
>>
>> On Sat, Aug 13, 2016 at 1:23 AM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> 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 ofbizBackground pattern to background
>>>
>>> BuildBot is another thing, it notably builds and test so does not need a
>>> secure task, it loads demo data and tests. As a committer you can see the
>>> script here https://svn.apache.org/repos/infra/infrastructure/buildbot/a
>>> egis/buildmaster/master1/projects/ofbiz.conf
>>>
>>> I need to update and complete the wiki documentation regarding Gradle and
>>> I trust you about explaining things in the README.MD
>>>
>>> I'll make obvious that by default we only trace and not reject
>>> deserialisation
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 13/08/2016 à 00:01, Taher Alkhateeb a écrit :
>>>
>>> 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
 whether
 notsoserial is default or not does not affect anyone during development
 or
 production. So I think we can safely remove these tasks and default them
 into the other tasks, the completion of the whitelist is another task
 for
 another day.

 Can I go ahead with the task or are you currently working on
 intersecting
 work? Would you mind helping out in switching buildbot to ofbiz instead
 of
 ofbizSecure?

 Taher Alkhateeb

 On Fri, Aug 12, 2016 at 11:22 PM, Jacques Le Roux <
 jacques.le.r...@les7arts.com> wrote:

 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 had issues and I planned to complete the list. But then
> thought that anyway, since we run it only during a day, it will never
> be
> complete and I gave up.
>
> Or actually, let me ask you in another why ... When should we prefer
> _not_
>
> to have ofbizSecure and why?
>>
>> When you are sure to not have any deserialization issues. For
>> instance,
>>
> as
> soon as you introduce RMI you are at risk. Notsoserial has a list of
> know
> issues https://github.com/kantega/notsoserial#which-classes-are-rej
> ected
> Note that we don't have these issues in OFBiz: see OFBIZ-6726,
> OFBIZ-6568
> and OFBIZ-6942 as explained at https://cwiki.apache.org/confl
> uence/display/OFBIZ/The+infamous+Java+serialization+vulnerability
>
> Jacques
>
>
>
>
> Taher Alkhateeb
>
>> On Fri, Aug 12, 2016 at 9:42 PM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> I conceived the Ant secure target with demo in mind, thinking users
>> would
>>
>> adapt

Re: Taking a decision on remaining Jars in OFBiz

2016-08-14 Thread Jacques Le Roux 

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 changed names. I think we also need to update
the demos to use ofbiz instead of ofbizSecure right?


Yep, all that's planned



There is one slight disadvantage of renaming ofbizBackground to background
and ofbizDebug to debug in that it does not become obvious to users that
this is an ofbiz server command (they all start with the word ofbiz). There
is also a small chance of name clashing with plugins that we might
introduce in the future. I'm stating this here in case we face such an
issue in the future to be aware of it and fix it.


Mmm... this is something I did not think about. I'll rather rename them debugOfbiz and backgroundOfbiz in order to keep the the differentiation. Still 
the shortcuts can be used :)


Jacques



Taher Alkhateeb

On Sat, Aug 13, 2016 at 1:23 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


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 ofbizBackground pattern to background

BuildBot is another thing, it notably builds and test so does not need a
secure task, it loads demo data and tests. As a committer you can see the
script here https://svn.apache.org/repos/infra/infrastructure/buildbot/a
egis/buildmaster/master1/projects/ofbiz.conf

I need to update and complete the wiki documentation regarding Gradle and
I trust you about explaining things in the README.MD

I'll make obvious that by default we only trace and not reject
deserialisation

Jacques



Le 13/08/2016 à 00:01, Taher Alkhateeb a écrit :


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 whether
notsoserial is default or not does not affect anyone during development or
production. So I think we can safely remove these tasks and default them
into the other tasks, the completion of the whitelist is another task for
another day.

Can I go ahead with the task or are you currently working on intersecting
work? Would you mind helping out in switching buildbot to ofbiz instead of
ofbizSecure?

Taher Alkhateeb

On Fri, Aug 12, 2016 at 11:22 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

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 had issues and I planned to complete the list. But then
thought that anyway, since we run it only during a day, it will never be
complete and I gave up.

Or actually, let me ask you in another why ... When should we prefer
_not_


to have ofbizSecure and why?

When you are sure to not have any deserialization issues. For instance,

as
soon as you introduce RMI you are at risk. Notsoserial has a list of know
issues https://github.com/kantega/notsoserial#which-classes-are-rejected
Note that we don't have these issues in OFBiz: see OFBIZ-6726, OFBIZ-6568
and OFBIZ-6942 as explained at https://cwiki.apache.org/confl
uence/display/OFBIZ/The+infamous+Java+serialization+vulnerability

Jacques




Taher Alkhateeb

On Fri, Aug 12, 2016 at 9:42 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

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/confluence/display/OFBIZ/The+infamo
us+Java+serialization+vulnerability I recommend to reject
deserialization
entirely (ie "just use an empty whitelist")
https://github.com/kantega/not
soserial#rejecting-deserialization-entirely
This is why I picked  notsoserial over all other solutions. If you use
this option you are safe! The idea is to test your code before
production
and to add libs in the whitelist if needed.

It's difficult to set a whitelist OOTB because it depends on so many
things, so far today we hit those on trunk demo (most of the time I saw
only that)
java.util.HashMap
java.lang.Boolean
java.lang.Integer
java.lang.Number
org.apache.derby.iapi.services.io.FormatIdInputStream.readObject

So if we remove ofbizSecure and ofbizBackgroundSecure by including them
by
default

Re: Taking a decision on remaining Jars in OFBiz

2016-08-14 Thread Taher Alkhateeb 
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 instead of ofbizSecure right?

There is one slight disadvantage of renaming ofbizBackground to background
and ofbizDebug to debug in that it does not become obvious to users that
this is an ofbiz server command (they all start with the word ofbiz). There
is also a small chance of name clashing with plugins that we might
introduce in the future. I'm stating this here in case we face such an
issue in the future to be aware of it and fix it.

Taher Alkhateeb

On Sat, Aug 13, 2016 at 1:23 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> 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 ofbizBackground pattern to background
>
> BuildBot is another thing, it notably builds and test so does not need a
> secure task, it loads demo data and tests. As a committer you can see the
> script here https://svn.apache.org/repos/infra/infrastructure/buildbot/a
> egis/buildmaster/master1/projects/ofbiz.conf
>
> I need to update and complete the wiki documentation regarding Gradle and
> I trust you about explaining things in the README.MD
>
> I'll make obvious that by default we only trace and not reject
> deserialisation
>
> Jacques
>
>
>
> Le 13/08/2016 à 00:01, Taher Alkhateeb a écrit :
>
>> 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 whether
>> notsoserial is default or not does not affect anyone during development or
>> production. So I think we can safely remove these tasks and default them
>> into the other tasks, the completion of the whitelist is another task for
>> another day.
>>
>> Can I go ahead with the task or are you currently working on intersecting
>> work? Would you mind helping out in switching buildbot to ofbiz instead of
>> ofbizSecure?
>>
>> Taher Alkhateeb
>>
>> On Fri, Aug 12, 2016 at 11:22 PM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> 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 had issues and I planned to complete the list. But then
>>> thought that anyway, since we run it only during a day, it will never be
>>> complete and I gave up.
>>>
>>> Or actually, let me ask you in another why ... When should we prefer
>>> _not_
>>>
 to have ofbizSecure and why?

 When you are sure to not have any deserialization issues. For instance,
>>> as
>>> soon as you introduce RMI you are at risk. Notsoserial has a list of know
>>> issues https://github.com/kantega/notsoserial#which-classes-are-rejected
>>> Note that we don't have these issues in OFBiz: see OFBIZ-6726, OFBIZ-6568
>>> and OFBIZ-6942 as explained at https://cwiki.apache.org/confl
>>> uence/display/OFBIZ/The+infamous+Java+serialization+vulnerability
>>>
>>> Jacques
>>>
>>>
>>>
>>>
>>> Taher Alkhateeb

 On Fri, Aug 12, 2016 at 9:42 PM, Jacques Le Roux <
 jacques.le.r...@les7arts.com> wrote:

 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/confluence/display/OFBIZ/The+infamo
> us+Java+serialization+vulnerability I recommend to reject
> deserialization
> entirely (ie "just use an empty whitelist")
> https://github.com/kantega/not
> soserial#rejecting-deserialization-entirely
> This is why I picked  notsoserial over all other solutions. If you use
> this option you are safe! The idea is to test your code before
> production
> and to add libs in the whitelist if needed.
>
> It's difficult to set a whitelist OOTB because it depends on so many
> things, so far today we hit those on trunk demo (most of the time I saw
> only that)
> java.util.HashMap
> java.lang.Boolean
> java.lang.Integer
> java.lang.Number
>

Re: Taking a decision on remaining Jars in OFBiz

2016-08-12 Thread Jacques Le Roux 

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 ofbizBackground pattern to background

BuildBot is another thing, it notably builds and test so does not need a secure task, it loads demo data and tests. As a committer you can see the 
script here https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/ofbiz.conf


I need to update and complete the wiki documentation regarding Gradle and I 
trust you about explaining things in the README.MD

I'll make obvious that by default we only trace and not reject deserialisation

Jacques


Le 13/08/2016 à 00:01, Taher Alkhateeb a écrit :

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 whether
notsoserial is default or not does not affect anyone during development or
production. So I think we can safely remove these tasks and default them
into the other tasks, the completion of the whitelist is another task for
another day.

Can I go ahead with the task or are you currently working on intersecting
work? Would you mind helping out in switching buildbot to ofbiz instead of
ofbizSecure?

Taher Alkhateeb

On Fri, Aug 12, 2016 at 11:22 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


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 had issues and I planned to complete the list. But then
thought that anyway, since we run it only during a day, it will never be
complete and I gave up.

Or actually, let me ask you in another why ... When should we prefer _not_

to have ofbizSecure and why?


When you are sure to not have any deserialization issues. For instance, as
soon as you introduce RMI you are at risk. Notsoserial has a list of know
issues https://github.com/kantega/notsoserial#which-classes-are-rejected
Note that we don't have these issues in OFBiz: see OFBIZ-6726, OFBIZ-6568
and OFBIZ-6942 as explained at https://cwiki.apache.org/confl
uence/display/OFBIZ/The+infamous+Java+serialization+vulnerability

Jacques





Taher Alkhateeb

On Fri, Aug 12, 2016 at 9:42 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

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/confluence/display/OFBIZ/The+infamo
us+Java+serialization+vulnerability I recommend to reject
deserialization
entirely (ie "just use an empty whitelist")
https://github.com/kantega/not
soserial#rejecting-deserialization-entirely
This is why I picked  notsoserial over all other solutions. If you use
this option you are safe! The idea is to test your code before production
and to add libs in the whitelist if needed.

It's difficult to set a whitelist OOTB because it depends on so many
things, so far today we hit those on trunk demo (most of the time I saw
only that)
java.util.HashMap
java.lang.Boolean
java.lang.Integer
java.lang.Number
org.apache.derby.iapi.services.io.FormatIdInputStream.readObject

So if we remove ofbizSecure and ofbizBackgroundSecure by including them
by
default we indeed need to create an as far as possible complete OOTB
whitelist
This needs some work I can't do, even if the trunk demo could be used
appropriately by reporting each day the deserializations done.

If we want to complete the list using the trunk demo we would still need
a
mean to trace the deserializations there. I see 2 options
1) a specific Gradle task using the notsoserial tracing and report about
it. It's easier but defeats the purpose of removing ofbizSecure and
ofbizBackgroundSecure
2) simply using the daily logs and look for "|Deserialization not allowed
for class"|. It's not that more work, in both cases we need to fetch the
info and parse. Most of the time, this should have a limited impact on
the
demo usability.
|||
|We could also decide to neglect this aspect, create an OOTB reputed to
be
incomplete whitelist and benefit from adopters researches to complete it.
Then we need to carefully document what we are doing for adopters to
easily
be safe.

Jacques

Le 07/08/2016 à 11:44, Taher Alkhateeb a écrit :

Hi Scott,

Yeah agreed. I think logging for failed serialization might be a bit
heavy because you

Re: Taking a decision on remaining Jars in OFBiz

2016-08-12 Thread Taher Alkhateeb 
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 whether
notsoserial is default or not does not affect anyone during development or
production. So I think we can safely remove these tasks and default them
into the other tasks, the completion of the whitelist is another task for
another day.

Can I go ahead with the task or are you currently working on intersecting
work? Would you mind helping out in switching buildbot to ofbiz instead of
ofbizSecure?

Taher Alkhateeb

On Fri, Aug 12, 2016 at 11:22 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> 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 had issues and I planned to complete the list. But then
> thought that anyway, since we run it only during a day, it will never be
> complete and I gave up.
>
> Or actually, let me ask you in another why ... When should we prefer _not_
>> to have ofbizSecure and why?
>>
>
> When you are sure to not have any deserialization issues. For instance, as
> soon as you introduce RMI you are at risk. Notsoserial has a list of know
> issues https://github.com/kantega/notsoserial#which-classes-are-rejected
> Note that we don't have these issues in OFBiz: see OFBIZ-6726, OFBIZ-6568
> and OFBIZ-6942 as explained at https://cwiki.apache.org/confl
> uence/display/OFBIZ/The+infamous+Java+serialization+vulnerability
>
> Jacques
>
>
>
>
>> Taher Alkhateeb
>>
>> On Fri, Aug 12, 2016 at 9:42 PM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> 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/confluence/display/OFBIZ/The+infamo
>>> us+Java+serialization+vulnerability I recommend to reject
>>> deserialization
>>> entirely (ie "just use an empty whitelist")
>>> https://github.com/kantega/not
>>> soserial#rejecting-deserialization-entirely
>>> This is why I picked  notsoserial over all other solutions. If you use
>>> this option you are safe! The idea is to test your code before production
>>> and to add libs in the whitelist if needed.
>>>
>>> It's difficult to set a whitelist OOTB because it depends on so many
>>> things, so far today we hit those on trunk demo (most of the time I saw
>>> only that)
>>> java.util.HashMap
>>> java.lang.Boolean
>>> java.lang.Integer
>>> java.lang.Number
>>> org.apache.derby.iapi.services.io.FormatIdInputStream.readObject
>>>
>>> So if we remove ofbizSecure and ofbizBackgroundSecure by including them
>>> by
>>> default we indeed need to create an as far as possible complete OOTB
>>> whitelist
>>> This needs some work I can't do, even if the trunk demo could be used
>>> appropriately by reporting each day the deserializations done.
>>>
>>> If we want to complete the list using the trunk demo we would still need
>>> a
>>> mean to trace the deserializations there. I see 2 options
>>> 1) a specific Gradle task using the notsoserial tracing and report about
>>> it. It's easier but defeats the purpose of removing ofbizSecure and
>>> ofbizBackgroundSecure
>>> 2) simply using the daily logs and look for "|Deserialization not allowed
>>> for class"|. It's not that more work, in both cases we need to fetch the
>>> info and parse. Most of the time, this should have a limited impact on
>>> the
>>> demo usability.
>>> |||
>>> |We could also decide to neglect this aspect, create an OOTB reputed to
>>> be
>>> incomplete whitelist and benefit from adopters researches to complete it.
>>> Then we need to carefully document what we are doing for adopters to
>>> easily
>>> be safe.
>>>
>>> Jacques
>>>
>>> Le 07/08/2016 à 11:44, Taher Alkhateeb a écrit :
>>>
>>> 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
 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

Re: Taking a decision on remaining Jars in OFBiz

2016-08-12 Thread Jacques Le Roux 

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 had issues and I planned to complete the list. But then thought that anyway, since we run it only during a day, it will never be complete 
and I gave up.



Or actually, let me ask you in another why ... When should we prefer _not_
to have ofbizSecure and why?


When you are sure to not have any deserialization issues. For instance, as soon as you introduce RMI you are at risk. Notsoserial has a list of know 
issues https://github.com/kantega/notsoserial#which-classes-are-rejected
Note that we don't have these issues in OFBiz: see OFBIZ-6726, OFBIZ-6568  and OFBIZ-6942 as explained at 
https://cwiki.apache.org/confluence/display/OFBIZ/The+infamous+Java+serialization+vulnerability


Jacques




Taher Alkhateeb

On Fri, Aug 12, 2016 at 9:42 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


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/confluence/display/OFBIZ/The+infamo
us+Java+serialization+vulnerability I recommend to reject deserialization
entirely (ie "just use an empty whitelist") https://github.com/kantega/not
soserial#rejecting-deserialization-entirely
This is why I picked  notsoserial over all other solutions. If you use
this option you are safe! The idea is to test your code before production
and to add libs in the whitelist if needed.

It's difficult to set a whitelist OOTB because it depends on so many
things, so far today we hit those on trunk demo (most of the time I saw
only that)
java.util.HashMap
java.lang.Boolean
java.lang.Integer
java.lang.Number
org.apache.derby.iapi.services.io.FormatIdInputStream.readObject

So if we remove ofbizSecure and ofbizBackgroundSecure by including them by
default we indeed need to create an as far as possible complete OOTB
whitelist
This needs some work I can't do, even if the trunk demo could be used
appropriately by reporting each day the deserializations done.

If we want to complete the list using the trunk demo we would still need a
mean to trace the deserializations there. I see 2 options
1) a specific Gradle task using the notsoserial tracing and report about
it. It's easier but defeats the purpose of removing ofbizSecure and
ofbizBackgroundSecure
2) simply using the daily logs and look for "|Deserialization not allowed
for class"|. It's not that more work, in both cases we need to fetch the
info and parse. Most of the time, this should have a limited impact on the
demo usability.
|||
|We could also decide to neglect this aspect, create an OOTB reputed to be
incomplete whitelist and benefit from adopters researches to complete it.
Then we need to carefully document what we are doing for adopters to easily
be safe.

Jacques

Le 07/08/2016 à 11:44, Taher Alkhateeb a écrit :


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
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" > 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" <

Re: Taking a decision on remaining Jars in OFBiz

2016-08-12 Thread Taher Alkhateeb 
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, Aug 12, 2016 at 9:42 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> 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/confluence/display/OFBIZ/The+infamo
> us+Java+serialization+vulnerability I recommend to reject deserialization
> entirely (ie "just use an empty whitelist") https://github.com/kantega/not
> soserial#rejecting-deserialization-entirely
> This is why I picked  notsoserial over all other solutions. If you use
> this option you are safe! The idea is to test your code before production
> and to add libs in the whitelist if needed.
>
> It's difficult to set a whitelist OOTB because it depends on so many
> things, so far today we hit those on trunk demo (most of the time I saw
> only that)
> java.util.HashMap
> java.lang.Boolean
> java.lang.Integer
> java.lang.Number
> org.apache.derby.iapi.services.io.FormatIdInputStream.readObject
>
> So if we remove ofbizSecure and ofbizBackgroundSecure by including them by
> default we indeed need to create an as far as possible complete OOTB
> whitelist
> This needs some work I can't do, even if the trunk demo could be used
> appropriately by reporting each day the deserializations done.
>
> If we want to complete the list using the trunk demo we would still need a
> mean to trace the deserializations there. I see 2 options
> 1) a specific Gradle task using the notsoserial tracing and report about
> it. It's easier but defeats the purpose of removing ofbizSecure and
> ofbizBackgroundSecure
> 2) simply using the daily logs and look for "|Deserialization not allowed
> for class"|. It's not that more work, in both cases we need to fetch the
> info and parse. Most of the time, this should have a limited impact on the
> demo usability.
> |||
> |We could also decide to neglect this aspect, create an OOTB reputed to be
> incomplete whitelist and benefit from adopters researches to complete it.
> Then we need to carefully document what we are doing for adopters to easily
> be safe.
>
> Jacques
>
> Le 07/08/2016 à 11:44, Taher Alkhateeb a écrit :
>
>> 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
>> 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" >> > 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" <
>
 jacques.le.r...@les7arts.com  >
>>>
>>> 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

Re: Taking a decision on remaining Jars in OFBiz

2016-08-12 Thread Jacques Le Roux 

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/confluence/display/OFBIZ/The+infamous+Java+serialization+vulnerability I recommend to reject deserialization entirely (ie 
"just use an empty whitelist") https://github.com/kantega/notsoserial#rejecting-deserialization-entirely
This is why I picked  notsoserial over all other solutions. If you use this option you are safe! The idea is to test your code before production and 
to add libs in the whitelist if needed.


It's difficult to set a whitelist OOTB because it depends on so many things, so 
far today we hit those on trunk demo (most of the time I saw only that)
java.util.HashMap
java.lang.Boolean
java.lang.Integer
java.lang.Number
org.apache.derby.iapi.services.io.FormatIdInputStream.readObject

So if we remove ofbizSecure and ofbizBackgroundSecure by including them by 
default we indeed need to create an as far as possible complete OOTB whitelist
This needs some work I can't do, even if the trunk demo could be used 
appropriately by reporting each day the deserializations done.

If we want to complete the list using the trunk demo we would still need a mean 
to trace the deserializations there. I see 2 options
1) a specific Gradle task using the notsoserial tracing and report about it. It's easier but defeats the purpose of removing ofbizSecure and 
ofbizBackgroundSecure
2) simply using the daily logs and look for "|Deserialization not allowed for class"|. It's not that more work, in both cases we need to fetch the 
info and parse. Most of the time, this should have a limited impact on the demo usability.

|||
|We could also decide to neglect this aspect, create an OOTB reputed to be incomplete whitelist and benefit from adopters researches to complete it. 
Then we need to carefully document what we are doing for adopters to easily be safe.


Jacques

Le 07/08/2016 à 11:44, Taher Alkhateeb a écrit :

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  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" > 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" <

jacques.le.r...@les7arts.com  >

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 <

Re: Taking a decision on remaining Jars in OFBiz

2016-08-12 Thread Jacques Le Roux 

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 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.le.r...@les7arts.com> wrote:


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:53 (+0200), Nicolas Malin  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>




--
logoNrd 
 Nicolas Malin
The apache way  : *Openness* Technical
decisions are made publicly
informat...@nereide.fr
8 rue des Déportés 37000 TOURS, 02 47 50 30 54

Apache OFBiz  | The Apache Way <
http://theapacheway.com/> | ofbiz-fr  | réseau
LE

Re: Taking a decision on remaining Jars in OFBiz

2016-08-12 Thread Nicolas Malin 

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 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/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>
>
>
>
--
logoNrd 
Nicolas Malin
The apache way  : *Openness* Technical 
decisions are made publicly

informat...@nereide.fr
8 rue des Déportés 37000 TOURS, 02 47 50 30 54

Apache OFBiz  | The Apache Way 
 | ofbiz-fr  | 
réseau LE

Re: Taking a decision on remaining Jars in OFBiz

2016-08-12 Thread Taher Alkhateeb 
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.le.r...@les7arts.com> wrote:

> 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:53 (+0200), Nicolas Malin  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>
>> >
>> >
>> >
>> --
>> logoNrd 
>> Nicolas Malin
>> The apache way  : *Openness* Technical
>> decisions are made publicly
>> informat...@nereide.fr
>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>
>> Apache OFBiz  | The Apache Way <
>> http://theapacheway.com/> | ofbiz-fr  | réseau
>> LE 
>>
>
>

Re: Taking a decision on remaining Jars in OFBiz

2016-08-12 Thread Jacques Le Roux 

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:53 (+0200), Nicolas Malin  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>
>
>
>
--
logoNrd 
Nicolas Malin
The apache way  : *Openness* Technical decisions are 
made publicly
informat...@nereide.fr
8 rue des Déportés 37000 TOURS, 02 47 50 30 54

Apache OFBiz  | The Apache Way  | ofbiz-fr  | réseau LE

Re: Taking a decision on remaining Jars in OFBiz

2016-08-10 Thread Nicolas Malin 

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/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>
>
>
>
--
logoNrd 
Nicolas Malin
The apache way  : *Openness* Technical 
decisions are made publicly

informat...@nereide.fr
8 rue des Déportés 37000 TOURS, 02 47 50 30 54

Apache OFBiz  | The Apache Way 
 | ofbiz-fr  | 
réseau LE

Re: Taking a decision on remaining Jars in OFBiz

2016-08-07 Thread Taher Alkhateeb 
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  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"  > 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" <
> jacques.le.r...@les7arts.com >
> >> 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 <
>  jacques.le.r...@les7arts.com > 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 : Execute OFBiz startup commands
> > pre-loading the notsoserial Java agent
> > Pattern: ofbizBackgroundSecure : 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 <
> >> jacques.le.r...@les7arts.com >
> >> 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"  .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
> >>>

Re: Taking a decision on remaining Jars in OFBiz

2016-08-06 Thread Scott Gray 
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 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" 
>> 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 <
 jacques.le.r...@les7arts.com> 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 : Execute OFBiz startup commands
> pre-loading the notsoserial Java agent
> Pattern: ofbizBackgroundSecure : 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 <
>> jacques.le.r...@les7arts.com>
>> 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">> uence/display/OFBIZ/Keeping+OFBiz+secure for details
>>>
>>> Jacques
>>>
>>>
>>>
>>>
>>>
>

Re: Taking a decision on remaining Jars in OFBiz

2016-08-06 Thread Jacopo Cappellato 
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
> 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

Re: Taking a decision on remaining Jars in OFBiz

2016-08-06 Thread Taher Alkhateeb 
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 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" 
>> 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 <
 jacques.le.r...@les7arts.com> 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 : Execute OFBiz startup commands
> pre-loading the notsoserial Java agent
> Pattern: ofbizBackgroundSecure : 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 <
>> jacques.le.r...@les7arts.com>
>> 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">> uence/display/OFBIZ/Keeping+OFBiz+secure for details
>>>
>>> Jacques
>>>
>>>
>>>
>>>
>>>
>

Re: Taking a decision on remaining Jars in OFBiz

2016-08-06 Thread Jacques Le Roux 
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" 
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 <
jacques.le.r...@les7arts.com> 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 : Execute OFBiz startup commands
pre-loading the notsoserial Java agent
Pattern: ofbizBackgroundSecure : 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 <
jacques.le.r...@les7arts.com>
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"

Re: Taking a decision on remaining Jars in OFBiz

2016-08-06 Thread Taher Alkhateeb 
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" 
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 <
>> jacques.le.r...@les7arts.com> 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 : Execute OFBiz startup commands
>>> pre-loading the notsoserial Java agent
>>> Pattern: ofbizBackgroundSecure : 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 <
 jacques.le.r...@les7arts.com>
 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"> .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
>
>
>
>
>

Re: Taking a decision on remaining Jars in OFBiz

2016-08-06 Thread Jacques Le Roux 

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 <
jacques.le.r...@les7arts.com> 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 : Execute OFBiz startup commands
pre-loading the notsoserial Java agent
Pattern: ofbizBackgroundSecure : 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 
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"

Re: Taking a decision on remaining Jars in OFBiz

2016-08-06 Thread Taher Alkhateeb 
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 <
jacques.le.r...@les7arts.com> 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 : Execute OFBiz startup commands
> pre-loading the notsoserial Java agent
> Pattern: ofbizBackgroundSecure : 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 
>> 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"
 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
>>>
>>>
>>>
>

Re: Taking a decision on remaining Jars in OFBiz

2016-08-06 Thread Jacques Le Roux 
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 : Execute OFBiz startup commands pre-loading the 
notsoserial Java agent
Pattern: ofbizBackgroundSecure : 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 
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"
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

Re: Taking a decision on remaining Jars in OFBiz

2016-08-06 Thread Taher Alkhateeb 
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  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  >
> 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" >
> >> 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
> >
> >
>

Re: Taking a decision on remaining Jars in OFBiz

2016-08-05 Thread Scott Gray 
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 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:
>>
>
> 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
>
>

Re: Taking a decision on remaining Jars in OFBiz

2016-08-05 Thread Jacques Le Roux 

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"
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

Re: Taking a decision on remaining Jars in OFBiz

2016-08-05 Thread Taher Alkhateeb 
+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 Cappellato a écrit :
>
>> On Fri, Jul 29, 2016 at 1:56 PM, Taher Alkhateeb <
>> slidingfilame...@gmail.com
>>
>>> 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
>>
>>
>

Re: Taking a decision on remaining Jars in OFBiz

2016-08-05 Thread Jacques Le Roux 

Inline


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

On Fri, Jul 29, 2016 at 1:56 PM, Taher Alkhateeb

Re: Taking a decision on remaining Jars in OFBiz

2016-08-05 Thread Jacopo Cappellato 
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 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

Re: Taking a decision on remaining Jars in OFBiz

2016-07-30 Thread Nicolas Malin 

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

Re: Taking a decision on remaining Jars in OFBiz

2016-07-30 Thread Nicolas Malin 

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

Re: Taking a decision on remaining Jars in OFBiz

2016-07-30 Thread Jacques Le Roux 

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