[ANNOUNCE] Apache OFBiz 17.12 End-Of-Life (EOL) announcement

[jler...@apache.org]

The Apache OFBiz Project Team would like to inform you that OFBiz 17.12.09
is the last release of the 17.12 branch, which has reached its end of life and
won't be longer officially supported.

https://ofbiz.apache.org/release-notes-17.12.09.html

This announcement takes place on 2022-01-21 and starting from today
we will only support Apache OFBiz 18.12.x in case of security
vulnerabilities.

Questions and Answers:

With the announcement of OFBiz 17.12.09 EOL, what happens to
OFBiz 17.12.09 resources?

All resources will stay where they are. The documentation will still
be accessible from the Apache OFBiz homepage[1], as well as the
downloads for last released OFBiz versions[2]. All of the OFBiz
17.12.09 source code can be found in the Apache OFBiz Git repository
under branch release17.12, now and in future. This concerns the
framework[3] and the plugins[4].

[1] [https://ofbiz.apache.org/]
[2] [https://downloads.apache.org/ofbiz]
[3] [https://github.com/apache/ofbiz-framework]
[4] [https://github.com/apache/ofbiz-plugins]

Is there an immediate need to upgrade from OFBiz 17.12.09 in my projects?

If you are using a release between 17.12.01 and 17.12.08 you should immediately
upgrade to 17.12.09, because there are several Log4j vulnerabilities present in 
all
OFBiz releases before 17.12.09.
As today, there aren't known vulnerabilities affecting OFBiz 17.12.09;
however, considering that the 17.12.09 is the last release in this branch,
you should plan to migrate to the latest version of 18.12.x as soon as possible.

My friends / colleagues and I would like to see OFBiz 17.12.x being
maintained again. What can we do?

You may fork the existing source and support it on your own.

Kind regards
-
The Apache OFBiz Team

Fwd: Returned post for annou...@apache.org

[jler...@apache.org]

Hi,

I see no reasons why this message did not pass, is there one?

TIA

Jacques



 Message transféré 
Sujet : Returned post for annou...@apache.org
Date :  20 Jan 2022 14:49:21 -
De :announce-h...@apache.org
Pour :  jler...@apache.org




Hi! This is the ezmlm program. I'm managing the
annou...@apache.org mailing list.

I'm working for my owner, who can be reached
at announce-ow...@apache.org.

I'm sorry, the list moderators for the announce list
have failed to act on your post. Thus, I'm returning it to you.
If you feel that this is in error, please repost the message
or contact a list moderator directly.

--- Enclosed, please find the message you sent.


--- Begin Message ---

The Apache OFBiz Project Team would like to inform you that OFBiz 17.12.09
is the last release of the 17.12 branch, which has reached its end of life and
won’t be longer officially supported.

https://ofbiz.apache.org/release-notes-17.12.09.html

This announcement takes place on 2022-01-15 and starting from today
we will only support Apache OFBiz 18.12.x in case of security
vulnerabilities.

Questions and Answers:

With the announcement of OFBiz 17.12.09 EOL, what happens to
OFBiz 17.12.09 resources?

All resources will stay where they are. The documentation will still
be accessible from the Apache OFBiz homepage [*], as well as the
downloads for all released OFBiz 17.12.xx versions. All of the OFBiz
17.12.09 source code can be found in the Apache OFBiz Git repository
under branch release17.12, now and in future. This concerns the
framework [**] and the plugins [***].

[*] [https://ofbiz.apache.org/]
[**] [https://github.com/apache/ofbiz-framework]
[***] [https://github.com/apache/ofbiz-plugins]

Is there an immediate need to upgrade from OFBiz 17.12.09 in my projects?

If you are using a release between 17.12.01 and 17.12.08 you should immediately
upgrade to 17.12.09, because there are several Log4j vulnerabilities present in 
all
OFBiz releases before 17.12.09.
As today, there aren't known vulnerabilities affecting OFBiz 17.12.09;
however, considering that the 17.12.09 is the last release in this branch,
you should plan to migrate to the latest version of 18.12.x as soon as possible.

My friends / colleagues and I would like to see OFBiz 17.12.x being
maintained again. What can we do?

You may fork the existing source and support it on your own.

Kind regards
–
The Apache OFBiz Team



--- End Message ---

[ANNOUNCE] Apache OFBiz 17.12 End-Of-Life (EOL) announcement

[jler...@apache.org]

The Apache OFBiz Project Team would like to inform you that OFBiz 17.12.09
is the last release of the 17.12 branch, which has reached its end of life and
won’t be longer officially supported.

https://ofbiz.apache.org/release-notes-17.12.09.html

This announcement takes place on 2022-01-15 and starting from today
we will only support Apache OFBiz 18.12.x in case of security
vulnerabilities.

Questions and Answers:

With the announcement of OFBiz 17.12.09 EOL, what happens to
OFBiz 17.12.09 resources?

All resources will stay where they are. The documentation will still
be accessible from the Apache OFBiz homepage [*], as well as the
downloads for all released OFBiz 17.12.xx versions. All of the OFBiz
17.12.09 source code can be found in the Apache OFBiz Git repository
under branch release17.12, now and in future. This concerns the
framework [**] and the plugins [***].

[*] [https://ofbiz.apache.org/]
[**] [https://github.com/apache/ofbiz-framework]
[***] [https://github.com/apache/ofbiz-plugins]

Is there an immediate need to upgrade from OFBiz 17.12.09 in my projects?

If you are using a release between 17.12.01 and 17.12.08 you should immediately
upgrade to 17.12.09, because there are several Log4j vulnerabilities present in 
all
OFBiz releases before 17.12.09.
As today, there aren't known vulnerabilities affecting OFBiz 17.12.09;
however, considering that the 17.12.09 is the last release in this branch,
you should plan to migrate to the latest version of 18.12.x as soon as possible.

My friends / colleagues and I would like to see OFBiz 17.12.x being
maintained again. What can we do?

You may fork the existing source and support it on your own.

Kind regards
–
The Apache OFBiz Team

Re: [ofbiz-framework] branch trunk updated: Fixed: [SECURITY] CVE-2021-44832: Apache Log4j2 (OFBIZ-12475)

[jler...@apache.org]

Hi Jacopo, All,

Ready to release 18.12.05?

Also it'd be good to ASAP freeze 22.01. Then I'll adapt BuildBot config and ask Infra to restart the demos. We will need to also trivially update 
README.adoc. I'll put that in the freeze part of the release plan page in wiki.


TIA

Happy holidays :)

Jacques

Le 29/12/2021 à 09:05, jler...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git


The following commit(s) were added to refs/heads/trunk by this push:
  new a744965  Fixed: [SECURITY] CVE-2021-44832: Apache Log4j2 (OFBIZ-12475)
a744965 is described below

commit a7449655678460ecd84ce6c04f7cc90bb55d1ea5
Author: Jacques Le Roux 
AuthorDate: Wed Dec 29 08:51:55 2021 +0100

 Fixed: [SECURITY] CVE-2021-44832: Apache Log4j2 (OFBIZ-12475)
 
 See complete explanation at https://issues.apache.org/jira/browse/OFBIZ-12475

---
  build.gradle | 14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/build.gradle b/build.gradle
index 99206c3..0dc7486 100644
--- a/build.gradle
+++ b/build.gradle
@@ -217,8 +217,8 @@ dependencies {
  implementation 'org.apache.geronimo.components:geronimo-transaction:3.1.4'
  implementation 'org.apache.geronimo.specs:geronimo-jms_1.1_spec:1.1.1'
  implementation 'org.apache.httpcomponents:httpclient-cache:4.5.13'
-implementation 'org.apache.logging.log4j:log4j-api:2.17.0' // the API of 
log4j 2
-implementation 'org.apache.logging.log4j:log4j-core:2.17.0' // Somehow 
needed by Buildbot to compile OFBizDynamicThresholdFilter.java
+implementation 'org.apache.logging.log4j:log4j-api:2.17.1' // the API of 
log4j 2
+implementation 'org.apache.logging.log4j:log4j-core:2.17.1' // Somehow 
needed by Buildbot to compile OFBizDynamicThresholdFilter.java
  implementation 'org.apache.poi:poi:4.1.2' // 
poi-ooxml-schemas-5.0.0.pom'. Received status code 401 from server
  implementation 'org.apache.pdfbox:pdfbox:2.0.24'
  implementation 'org.apache.shiro:shiro-core:1.8.0'
@@ -256,11 +256,11 @@ dependencies {
  runtimeOnly 'org.apache.axis2:axis2-transport-local:1.7.9' // Above: 
SOAPEventHandler.java:42: error: package org.apache.axiom.om.impl.builder does 
not exist
  runtimeOnly 'org.apache.derby:derby:10.14.2.0'  // So far we did not 
update from 10.14.2.0 because of a compile issue. You may try w/ a newer 
version than 10.15.1.3
  runtimeOnly 'org.apache.geronimo.specs:geronimo-jaxrpc_1.1_spec:2.1'
-runtimeOnly 'org.apache.logging.log4j:log4j-1.2-api:2.17.0' // for 
external jars using the old log4j1.2: routes logging to log4j 2
-runtimeOnly 'org.apache.logging.log4j:log4j-jul:2.17.0' // for external 
jars using the java.util.logging: routes logging to log4j 2
-runtimeOnly 'org.apache.logging.log4j:log4j-slf4j-impl:2.17.0' // for 
external jars using slf4j: routes logging to log4j 2
-runtimeOnly 'org.apache.logging.log4j:log4j-web:2.17.0' //???
-runtimeOnly 'org.apache.logging.log4j:log4j-jcl:2.17.0' // need to 
constrain to version to avoid classpath conflict (ReflectionUtil)
+runtimeOnly 'org.apache.logging.log4j:log4j-1.2-api:2.17.1' // for 
external jars using the old log4j1.2: routes logging to log4j 2
+runtimeOnly 'org.apache.logging.log4j:log4j-jul:2.17.1' // for external 
jars using the java.util.logging: routes logging to log4j 2
+runtimeOnly 'org.apache.logging.log4j:log4j-slf4j-impl:2.17.1' // for 
external jars using slf4j: routes logging to log4j 2
+runtimeOnly 'org.apache.logging.log4j:log4j-web:2.17.1' //???
+runtimeOnly 'org.apache.logging.log4j:log4j-jcl:2.17.1' // need to 
constrain to version to avoid classpath conflict (ReflectionUtil)
  runtimeOnly 
'org.codeartisans.thirdparties.swing:batik-all:1.8pre-r1084380'
  
  // Dependencies defined by the plugins

Re: [ofbiz-framework] branch trunk updated: Improved: Fix some bugs Spotbugs reports (OFBIZ-12386)

[jler...@apache.org]

There are issues with OfbizControlServlet, I'll work on it soon... or will 
revert...

Jacques

Le 05/12/2021 à 13:48, jler...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git


The following commit(s) were added to refs/heads/trunk by this push:
  new aab412b  Improved:  Fix some bugs Spotbugs reports (OFBIZ-12386)
aab412b is described below

commit aab412b94827e4fcc8c79f7d6ecb528f8695862b
Author: Jacques Le Roux 
AuthorDate: Sun Dec 5 13:03:50 2021 +0100

 Improved:  Fix some bugs Spotbugs reports (OFBIZ-12386)
 
 Renames ControlServlet class to OfbizControlServlet, because it shadowed the

 simple name of it superclass
 It can be exceptionally confusing, create lots of situations in which you 
have
 to look at import statements to resolve references and creates many
 opportunities to accidentally define methods that do not override methods
 in their superclasses.
 
 Same for XmlRpcClient.java

---
  .../apache/ofbiz/product/category/CatalogUrlSeoFilter.java   |  2 +-
  .../{ControlServlet.java => OfbizControlServlet.java}| 12 +---
  .../ofbiz/base/util/collections/FlexibleServletAccessor.java |  3 ++-
  .../org/apache/ofbiz/service/engine/XMLRPCClientEngine.java  |  8 
  .../apache/ofbiz/service/test/AbstractXmlRpcTestCase.java|  6 +++---
  .../xmlrpc/{XmlRpcClient.java => OfbizXmlRpcClient.java} |  8 
  6 files changed, 19 insertions(+), 20 deletions(-)

diff --git 
a/applications/product/src/main/java/org/apache/ofbiz/product/category/CatalogUrlSeoFilter.java
 
b/applications/product/src/main/java/org/apache/ofbiz/product/category/CatalogUrlSeoFilter.java
index 72683aa..b1cb981 100644
--- 
a/applications/product/src/main/java/org/apache/ofbiz/product/category/CatalogUrlSeoFilter.java
+++ 
b/applications/product/src/main/java/org/apache/ofbiz/product/category/CatalogUrlSeoFilter.java
@@ -60,7 +60,7 @@ public class CatalogUrlSeoFilter extends CatalogUrlFilter {
  
  // set the ServletContext in the request for future use

  httpRequest.setAttribute("servletContext", 
getConfig().getServletContext());
-if (CatalogUrlSeoTransform.forwardUri(httpRequest, httpResponse, 
delegator, ControlServlet.getControlServlet())) {
+if (CatalogUrlSeoTransform.forwardUri(httpRequest, httpResponse, 
delegator, OfbizControlServlet.getControlServlet())) {
  return;
  }
  super.doFilter(httpRequest, httpResponse, chain);
diff --git 
a/applications/product/src/main/java/org/apache/ofbiz/product/category/ControlServlet.java
 
b/applications/product/src/main/java/org/apache/ofbiz/product/category/OfbizControlServlet.java
similarity index 89%
rename from 
applications/product/src/main/java/org/apache/ofbiz/product/category/ControlServlet.java
rename to 
applications/product/src/main/java/org/apache/ofbiz/product/category/OfbizControlServlet.java
index 99d1dde..d514bd2 100644
--- 
a/applications/product/src/main/java/org/apache/ofbiz/product/category/ControlServlet.java
+++ 
b/applications/product/src/main/java/org/apache/ofbiz/product/category/OfbizControlServlet.java
@@ -28,15 +28,13 @@ import org.apache.ofbiz.base.util.UtilValidate;
   * ControlServlet.java - Master servlet for the web application.
   */
  @SuppressWarnings("serial")
-public class ControlServlet extends 
org.apache.ofbiz.webapp.control.ControlServlet {
-
-private static final String MODULE = ControlServlet.class.getName();
+public class OfbizControlServlet extends 
org.apache.ofbiz.webapp.control.ControlServlet {
  
  private static String defaultPage = null;

  private static String pageNotFound = null;
  private static String controlServlet = null;
  
-public ControlServlet() {

+public OfbizControlServlet() {
  super();
  }
  
@@ -69,7 +67,7 @@ public class ControlServlet extends org.apache.ofbiz.webapp.control.ControlServl

  }
  
  public static void setDefaultPage(String defaultPage) {

-ControlServlet.defaultPage = defaultPage;
+OfbizControlServlet.defaultPage = defaultPage;
  }
  
  public static String getPageNotFound() {

@@ -77,7 +75,7 @@ public class ControlServlet extends 
org.apache.ofbiz.webapp.control.ControlServl
  }
  
  public static void setPageNotFound(String pageNotFound) {

-ControlServlet.pageNotFound = pageNotFound;
+OfbizControlServlet.pageNotFound = pageNotFound;
  }
  
  public static String getControlServlet() {

@@ -85,7 +83,7 @@ public class ControlServlet extends 
org.apache.ofbiz.webapp.control.ControlServl
  }
  
  public static void setControlServlet(String controlServlet) {

-ControlServlet.controlServlet = controlServlet;
+OfbizControlServlet.controlServlet = controlServlet;

Re: [ofbiz-framework] branch release18.12 updated: Improved: modifies GH workflows to run on all branches

[jler...@apache.org]

Did not work either, asked at 
https://github.com/github/codeql-action/issues/462#issuecomment-968304521

Le 14/11/2021 à 15:39, jler...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a commit to branch release18.12
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git


The following commit(s) were added to refs/heads/release18.12 by this push:
  new 91357bb  Improved: modifies GH workflows to run on all branches
91357bb is described below

commit 91357bbf0eabd147b87385fd94cb0b139058fa12
Author: Jacques Le Roux 
AuthorDate: Sun Nov 14 15:39:02 2021 +0100

 Improved: modifies GH workflows to run on all branches
 
 I followed this answer: https://github.com/github/codeql-action/issues/462

 Too bad, it does not seem to work
 
https://github.com/apache/ofbiz-framework/actions/workflows/codeql-analysis.yml?query=branch%3Arelease18.12
 (OK for trunk: 
https://github.com/apache/ofbiz-framework/actions/workflows/codeql-analysis.yml?query=)
 
 I try the other syntax, ie '**'

---
  .github/workflows/codeql-analysis.yml | 1 +
  1 file changed, 1 insertion(+)

diff --git a/.github/workflows/codeql-analysis.yml 
b/.github/workflows/codeql-analysis.yml
index 35d32c7..f4205f4 100644
--- a/.github/workflows/codeql-analysis.yml
+++ b/.github/workflows/codeql-analysis.yml
@@ -25,6 +25,7 @@ name: "CodeQL"
  
  on:

push:
+branches: [ '**' ]
  paths:
  - '**.java'
  - '**.js'

[CVE-2021-37608] Arbitrary file upload vulnerability in OFBiz

[jler...@apache.org]

Severity:
High, possible RCE

Vendor:
The Apache Software Foundation

Versions Affected:
OFBiz versions prior to 17.12.08

Description:
Apache OFBiz has unsafe deserialization prior to 17.12.08 version

Mitigation:
Upgrade to at least 17.12.08
or apply patches at https://issues.apache.org/jira/browse/OFBIZ-12297

Credit:
Zhujie from galaxylab 

References:
http://ofbiz.apache.org/download.html#vulnerabilities

Re: [ofbiz-framework] branch trunk updated: Improved: Handle remaining checkstyle errors (OFBIZ-12169)

[jler...@apache.org]

Hi Team,

I have been working on 
https://checkstyle.sourceforge.io/config_whitespace.html#MethodParamPad

I could fix few issues in code. But there are still some cases that can't be 
handled by changing code, notably when a casting is necessary, and not only.

I believe there is an error in checkstyle code. If you look at the URL above and the errors reported, you will see that the errors don't belong to the 
tokens to check.


We can use this solution 
https://stackoverflow.com/questions/45109089/checkstyle-can-i-change-the-should-be-on-the-previous-line-rule-of-meth#answer-45109414

But I believe we should rather discuss with checkstyle team if a report is not 
appropriate.

What do you think?

Thanks

Jacques

Le 04/05/2021 à 10:36, jler...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git


The following commit(s) were added to refs/heads/trunk by this push:
  new 45f50c9  Improved: Handle remaining checkstyle errors (OFBIZ-12169)
45f50c9 is described below

commit 45f50c910d64c12a2601164fbc64a4a02ef1d833
Author: Jacques Le Roux 
AuthorDate: Tue May 4 10:34:52 2021 +0200

 Improved: Handle remaining checkstyle errors (OFBIZ-12169)
 
 This handles the "'(' should be on the previous line?" rule of MethodParamPad
 
 Actually not completely, because there are still some cases that can't be

 handled by changing code, notably when a casting is necessary. I believe 
there
 is an error in checkstyle code. I'll discuss that in dev ML before sending
 checkstyle team a report.
---
  .../java/org/apache/ofbiz/accounting/invoice/InvoiceServices.java  | 4 ++--
  .../java/org/apache/ofbiz/order/order/OrderReturnServices.java | 3 ++-
  .../java/org/apache/ofbiz/order/shoppingcart/ShoppingCart.java | 4 ++--
  build.gradle   | 2 +-
  .../common/src/main/java/org/apache/ofbiz/common/CommonEvents.java | 7 +++
  .../main/java/org/apache/ofbiz/webapp/control/ContextFilter.java   | 2 +-
  .../src/main/java/org/apache/ofbiz/webtools/WebToolsServices.java  | 2 +-
  7 files changed, 12 insertions(+), 12 deletions(-)

diff --git 
a/applications/accounting/src/main/java/org/apache/ofbiz/accounting/invoice/InvoiceServices.java
 
b/applications/accounting/src/main/java/org/apache/ofbiz/accounting/invoice/InvoiceServices.java
index 9c956e8..7ee585a 100644
--- 
a/applications/accounting/src/main/java/org/apache/ofbiz/accounting/invoice/InvoiceServices.java
+++ 
b/applications/accounting/src/main/java/org/apache/ofbiz/accounting/invoice/InvoiceServices.java
@@ -457,8 +457,8 @@ public class InvoiceServices {
  Map createInvoiceItemContext = new 
HashMap<>();
  createInvoiceItemContext.put("invoiceId", invoiceId);
  createInvoiceItemContext.put("invoiceItemSeqId", 
invoiceItemSeqId);
-createInvoiceItemContext.put("invoiceItemTypeId", 
getInvoiceItemType(delegator, (orderItem.getString("orderItemTypeId")),
-(product == null ? null : product.getString("productTypeId")), 
invoiceType, "INV_FPROD_ITEM"));
+createInvoiceItemContext.put("invoiceItemTypeId", 
getInvoiceItemType(delegator, orderItem.getString("orderItemTypeId"),
+product == null ? null : product.getString("productTypeId"), 
invoiceType, "INV_FPROD_ITEM"));
  createInvoiceItemContext.put("description", 
orderItem.get("itemDescription"));
  createInvoiceItemContext.put("quantity", billingQuantity);
  createInvoiceItemContext.put("amount", billingAmount);
diff --git 
a/applications/order/src/main/java/org/apache/ofbiz/order/order/OrderReturnServices.java
 
b/applications/order/src/main/java/org/apache/ofbiz/order/order/OrderReturnServices.java
index d8b469b..17f43b2 100644
--- 
a/applications/order/src/main/java/org/apache/ofbiz/order/order/OrderReturnServices.java
+++ 
b/applications/order/src/main/java/org/apache/ofbiz/order/order/OrderReturnServices.java
@@ -1325,7 +1325,8 @@ public class OrderReturnServices {
  orderPayPrefDetails.put("orderPaymentPreference", 
orderPayPref);
  orderPayPrefDetails.put("availableTotal", 
orderPayPrefAvailableTotal);
  if (prefSplitMap.containsKey(paymentMethodTypeId)) {
-
(prefSplitMap.get(paymentMethodTypeId)).add(orderPayPrefDetails);
+List> paymentMethodTypeIds = 
prefSplitMap.get(paymentMethodTypeId);
+paymentMethodTypeIds.add(orderPayPrefDetails);
  } else {
   

[CVE-2021-30128] Unsafe deserialization in OFBiz

[jler...@apache.org]

Severity:
High, possible RCE

Vendor:
The Apache Software Foundation

Versions Affected:
OFBiz versions prior to 17.12.07

Description:
Apache OFBiz has unsafe deserialization prior to 17.12.07 version

Mitigation:
Upgrade to at least 17.12.07
or apply patches at https://issues.apache.org/jira/browse/OFBIZ-12212 & 
OFBIZ-12221

Credit:
Litch1 from the Security Team of Alibaba Cloud 

References:
http://ofbiz.apache.org/download.html#vulnerabilities

[CVE-2021-29200] RCE vulnerability in latest Apache OFBiz due to Java serialisation using RMI

[jler...@apache.org]

Severity:
High, possible RCE

Vendor:
The Apache Software Foundation

Versions Affected:
OFBiz versions prior to 17.12.07

Description:
Apache OFBiz has unsafe deserialization prior to 17.12.07 version
An unauthenticated user can perform a RCE attack

Mitigation:
Upgrade to at least 17.12.07
or apply one of the patches at https://issues.apache.org/jira/browse/OFBIZ-12216

Credit:
r00t4dm at Cloud-Penetrating Arrow Lab 
asd of MoyunSec V-Lab 
赖涵 <1044309...@qq.com>

References:
http://ofbiz.apache.org/download.html#vulnerabilities

Re: [ofbiz-framework] branch release17.12 updated: Improved: Replace Bintray by a new place to upload the Gradle Wrapper (OFBIZ-12192)

[jler...@apache.org]

Hi,

I think we should at least discuss the 2 points below before releasing 17.12.07

Thanks

Jacques

Le 10/04/2021 à 14:10, jler...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a commit to branch release17.12
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git


The following commit(s) were added to refs/heads/release17.12 by this push:
  new 564b605  Improved: Replace Bintray by a new place to upload the 
Gradle Wrapper (OFBIZ-12192)
564b605 is described below

commit 564b605d5509cd85f8d7b6355b4ebe62280e5686
Author: Jacques Le Roux 
AuthorDate: Sat Apr 10 14:10:43 2021 +0200

 Improved: Replace Bintray by a new place to upload the Gradle Wrapper 
(OFBIZ-12192)
 
 The checksum part was missing in Windows init-gradle-wrapper.ps1 script
 
 I have noticed 2 points:

 1. We should use SHA256, not SHA1
 2. The unix-like shell script in OFBiz misses checksum verification in case
 shasum command is not installed. In other words, if I launch the script it 
would
 fail with "shasum not found, the downloaded files could not be verified".
 However, the file will be kept there, so the user could launch unverified 
jar.
 
 Last point was reported by Vladimir Sitnikov at LEGAL-288

---
  gradle/init-gradle-wrapper.ps1 | 8 
  1 file changed, 8 insertions(+)

diff --git a/gradle/init-gradle-wrapper.ps1 b/gradle/init-gradle-wrapper.ps1
index c4911bd..2401147 100644
--- a/gradle/init-gradle-wrapper.ps1
+++ b/gradle/init-gradle-wrapper.ps1
@@ -25,6 +25,14 @@ If ($ExecutionContext.SessionState.LanguageMode -eq 
"ConstrainedLanguage") {
  Invoke-WebRequest -outf gradle\wrapper\gradle-wrapper.jar 
https://github.com/gradle/gradle/raw/v4.5.1/gradle/wrapper/gradle-wrapper.jar
  }
  
+$expected = "00d0743607178962f8b120da4ccad2c64c698aec"

+$actual = (Get-FileHash gradle\wrapper\gradle-wrapper.jar -Algorithm 
SHA1).Hash.ToLower()
+@{$true = 'OK: Checksum match'; $false = "ERROR: Checksum mismatch!`nExpected: 
$expected`nActual: $actual"}[$actual -eq $expected]
+
+if (!$true)  {
+Remove-Item gradle\wrapper\gradle-wrapper.jar
+}
+
  #Write-Host $ExecutionContext.SessionState.LanguageMode
  
  Start-Sleep -s 3

Subject: [CVE-2021-26295] RCE vulnerability in latest Apache OFBiz due to Java serialisation using RMI

[jler...@apache.org]

Severity:
High

Vendor:
The Apache Software Foundation

Versions Affected:
OFBiz versions prior to 17.12.06

Description:
Apache OFBiz has unsafe deserialization prior to 17.12.06.
An unauthenticated attacker can use this vulnerability to successfully take 
over Apache OFBiz.

Mitigation:
Upgrade to at least 17.12.06
or apply the patch at https://github.com/apache/ofbiz-framework/commit/af9ed4e/

Credit:
r00t4dm at Cloud-Penetrating Arrow Lab 
MagicZero from SGLAB of Legendsec at Qi'anxin Group.
Longofo at Knownsec 404 Team

References:
http://ofbiz.apache.org/download.html#vulnerabilities

Re: buildbot failure in on ofbizBranch17FrameworkPlugins

[jler...@apache.org]

Thanks Deepak!

Jacques

Le 04/01/2021 à 11:30, Jacopo Cappellato a écrit :

thank you, it works fine now!
I am going to start a new vote.

Jacopo


On Mon, Jan 4, 2021 at 10:01 AM Deepak Dixit  wrote:


Hi All,

Here [1] is the PR for the fix, Updated the lucene and solr dependencies,
took reference from [2]
I merged this MR and now buildbot success in on
ofbizBranch17FrameworkPlugins [3]

[1] https://github.com/apache/ofbiz-plugins/pull/48/files
[2]

https://github.com/apache/ofbiz-plugins/commit/4f19b762f3d9fc7988a347a896997f49196427e9
[3]
https://ci.apache.org/builders/ofbizBranch17FrameworkPlugins/builds/622


Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org


On Mon, Jan 4, 2021 at 12:09 PM Deepak Dixit  wrote:


We can update the solr and lucene dependency as well to latest,  let me
check

Kind Regards,
Deepak Dixit


On Sun, Jan 3, 2021 at 3:32 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Though one clue is perhaps that it works in trunk

Le 03/01/2021 à 10:15, Jacques Le Roux a écrit :

That makes sense Jacopo, how to solve the conundrum is less obvious. I

have reopened OFBIZ-12100 as a blocker.

Jacques

Le 03/01/2021 à 09:44, Jacopo Cappellato a écrit :

I suspect that the new version of the tika libraries are dependent

on a

version of Guava that is not compatible with the one required by the

solr

component.

Jacopo


On Sun, Jan 3, 2021 at 9:40 AM Jacopo Cappellato <
jacopo.cappell...@gmail.com> wrote:


I am actually getting the same error on R17.
The error is the one reported in:
https://issues.apache.org/jira/browse/OFBIZ-9444
In fact disabling the "solr" component resolves the issue.

Jacopo


On Sun, Jan 3, 2021 at 9:22 AM jler...@apache.org <

jler...@apache.org

wrote:


Hi Deepak, All,

The same error (not failure) exists in both R17 and R18. I

reproduce

locally with R18. It seems related to OFBIZ-9442 and OFBIZ-9444

Reverting the change allows

  gradlew "ofbiz --test component=solr --test

suitename=solrtests"

to pass

I believe this is a blocker for the releases.

HTH

Jacques


Le 31/12/2020 à 14:33, Deepak Dixit a écrit :

I don't think this build failure due to dependency update

solrTests is failing


/=/

/2020-12-31 11:58:34,947 |main |TestRunContainer |I| [JUNIT] Pass:

false | # Tests: 5 | # Failed: 0 # Errors: 1 2020-12-31

11:58:34,947

|main

|TestRunContainer |I| [JUNIT] - ERRORS

- [JUNIT] 2020-12-31 11:58:34,947 |main

|TestRunContainer |I| -->

testAddProductToIndex(org.apache.ofbiz.solr.test.SolrTests): Could

not

commit transaction for service [solrProductsSearch]

call: Roll back error, could not commit transaction, was rolled

back

instead because of: Error in Service [runSolrQuery]:

org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:

Error from server at https://localhost:8443/solr/solrdefault

<https://localhost:8443/solr/solrdefault>:

java.lang.NoSuchMethodError:


com.google.common.base.Objects.firstNonNull(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;

2020-12-31 11:58:34,948 |main |TestRunContainer

|I| org.apache.ofbiz.service.GenericServiceException: Could not

commit

transaction for service [solrProductsSearch] call: Roll back error,

could

not

commit transaction, was rolled back instead because of: Error in

Service [runSolrQuery]:

org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:

Error from server at https://localhost:8443/solr/solrdefault

<https://localhost:8443/solr/solrdefault>:

java.lang.NoSuchMethodError:


com.google.common.base.Objects.firstNonNull(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;

at


org.apache.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:563)

/

/
/


/=/

Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org <http://ofbiz.apache.org>


  The Buildbot has detected a new failure on builder

ofbizBranch17FrameworkPlugins while building ofbiz-framework. Full

details

are available at:


https://ci.apache.org/builders/ofbizBranch17FrameworkPlugins/builds/621

<

https://ci.apache.org/builders/ofbizBranch17FrameworkPlugins/builds/621

  Buildbot URL: https://ci.apache.org/ <https://ci.apache.org/
  Buildslave for this Build: asf946_ubuntu

  Build Reason: downstream
  Build Source Stamp: [branch release17.12]

24d9328cdf6489ba0e4c2d9b849f08c66658a5e2

  Blamelist: Deepak Dixit 
deepak.di...@hotwax.co>>

  BUILD FAILED: failed shell_7

  Sincerely,
   -The Buildbot

Re: buildbot failure in on ofbizBranch17FrameworkPlugins

[jler...@apache.org]

Hi Deepak, All,

The same error (not failure) exists in both R17 and R18. I reproduce locally 
with R18. It seems related to OFBIZ-9442 and OFBIZ-9444

Reverting the change allows

   gradlew "ofbiz --test component=solr --test suitename=solrtests"

to pass

I believe this is a blocker for the releases.

HTH

Jacques


Le 31/12/2020 à 14:33, Deepak Dixit a écrit :

I don't think this build failure due to dependency update

solrTests is failing
/=/
/2020-12-31 11:58:34,947 |main |TestRunContainer |I| [JUNIT] Pass: false | # Tests: 5 | # Failed: 0 # Errors: 1 2020-12-31 11:58:34,947 |main 
|TestRunContainer |I| [JUNIT] - ERRORS - [JUNIT] 2020-12-31 11:58:34,947 |main 
|TestRunContainer |I| --> testAddProductToIndex(org.apache.ofbiz.solr.test.SolrTests): Could not commit transaction for service [solrProductsSearch] 
call: Roll back error, could not commit transaction, was rolled back instead because of: Error in Service [runSolrQuery]: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://localhost:8443/solr/solrdefault 
: java.lang.NoSuchMethodError: 
com.google.common.base.Objects.firstNonNull(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; 2020-12-31 11:58:34,948 |main |TestRunContainer 
|I| org.apache.ofbiz.service.GenericServiceException: Could not commit transaction for service [solrProductsSearch] call: Roll back error, could not 
commit transaction, was rolled back instead because of: Error in Service [runSolrQuery]: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://localhost:8443/solr/solrdefault 
: java.lang.NoSuchMethodError: 
com.google.common.base.Objects.firstNonNull(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; at 
org.apache.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:563) /

/
/
/=/

Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org 


The Buildbot has detected a new failure on builder 
ofbizBranch17FrameworkPlugins while building ofbiz-framework. Full details are 
available at:
https://ci.apache.org/builders/ofbizBranch17FrameworkPlugins/builds/621 


Buildbot URL: https://ci.apache.org/ 

Buildslave for this Build: asf946_ubuntu

Build Reason: downstream
Build Source Stamp: [branch release17.12] 
24d9328cdf6489ba0e4c2d9b849f08c66658a5e2
Blamelist: Deepak Dixit mailto:deepak.di...@hotwax.co>>

BUILD FAILED: failed shell_7

Sincerely,
 -The Buildbot

Re: Releasing 17.12.05, 18.12.01 and freezing R20

[jler...@apache.org]

Le 21/12/2020 à 14:57, Michael Brohl a écrit :
It seems a bit outdated to read that r18 is released in 2021... 


Sincerely I think we need to release R18, even at the end of 2020. Waiting one 
year more is too long...

Jacques

Re: Releasing 17.12.05, 18.12.01 and freezing R20

[jler...@apache.org]

Thanks Jacopo,

Looking forward and ready to help

Cheers

Jacques

PS: sent 5h ago but b.barracudacentral.org has a dent against me (hard to 
change that)

Le 21/12/2020 à 10:21, Jacopo Cappellato a écrit :

Hi Jacques,

It sounds like a good plan to me and I can prepare the artifacts as soon as
we are ready.
We could first publish 17.12.05 and then start the process for 18.12.01; in
the meantime we could tag the new R20 branch.

Thanks,

Jacopo


On Sun, Dec 20, 2020 at 2:08 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi All,

We have no longer any pending security issues, even post-auth ones (those
with no CVE). As Marj J. Cox  - VP of ASF security - said once to me: <<"No
CVE" is a great outcome>> ;)

I propose that

   * we release 17.12.05 as the last release of R17.
   * We release 18.12.01 as the first release of R18.
   * That we make R18 our current stable branch, and so R17 the old one.
   * And finally that we freeze a new R20 branch.

What do you people think?

If it's OK with everybody could you handle it, or part of it if we don't
agree on all, Jacopo?

Thanks

Jaques

Re: buildbot exception in on ofbizTrunkFramework

[jler...@apache.org]

FYI: I created https://issues.apache.org/jira/browse/INFRA-21209 for that

Le 18/12/2020 à 17:42, jler...@apache.org a écrit :

Fixed, the trunk demo is accessible again

Sorry for the quirk

Le 18/12/2020 à 16:18, Jacques Le Roux a écrit :

OK, it's a Shiro version issue, checking that

Exception in thread "main" org.apache.shiro.crypto.CryptoException: Unable to 
execute 'doFinal' with cipher instance [javax.crypto.Cipher@299ddfff].
    at 
org.apache.shiro.crypto.JcaCipherService.crypt(JcaCipherService.java:462)
    at 
org.apache.shiro.crypto.JcaCipherService.crypt(JcaCipherService.java:445)
    at 
org.apache.shiro.crypto.JcaCipherService.encrypt(JcaCipherService.java:336)
    at 
org.apache.shiro.crypto.JcaCipherService.encrypt(JcaCipherService.java:313)
    at 
org.apache.ofbiz.entity.util.EntityCrypto$ShiroStorageHandler.encryptValue(EntityCrypto.java:293)

Jacques

Le 18/12/2020 à 14:41, Jacques Le Roux a écrit :

Hi,

This does not make sense at all. As it works locally I thought 
https://github.com/apache/ofbiz-framework/commit/6c34142b60cebdd0b64d31d917a7fa4b0cd476ec/ would fix it.


But it does not, though it works in demo too. But I see an issue with some data (credentials for instance) not loaded there, checking that. I need 
to restart the demos...


Jacques

Le 17/12/2020 à 18:51, build...@apache.org a écrit :

The Buildbot has detected a build exception on builder ofbizTrunkFramework 
while building ofbiz-framework. Full details are available at:
https://ci.apache.org/builders/ofbizTrunkFramework/builds/2012

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf947_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'onTrunkFrameworkCommit' 
triggered this build
Build Source Stamp: [branch trunk] f016e5da2309a775090a71d2f679746260ec6f09
Blamelist: Jacques Le Roux 

BUILD FAILED: exception build upload test-results part 1

Sincerely,
  -The Buildbot

Re: buildbot exception in on ofbizTrunkFramework

[jler...@apache.org]

Fixed, the trunk demo is accessible again

Sorry for the quirk

Le 18/12/2020 à 16:18, Jacques Le Roux a écrit :

OK, it's a Shiro version issue, checking that

Exception in thread "main" org.apache.shiro.crypto.CryptoException: Unable to 
execute 'doFinal' with cipher instance [javax.crypto.Cipher@299ddfff].
    at 
org.apache.shiro.crypto.JcaCipherService.crypt(JcaCipherService.java:462)
    at 
org.apache.shiro.crypto.JcaCipherService.crypt(JcaCipherService.java:445)
    at 
org.apache.shiro.crypto.JcaCipherService.encrypt(JcaCipherService.java:336)
    at 
org.apache.shiro.crypto.JcaCipherService.encrypt(JcaCipherService.java:313)
    at 
org.apache.ofbiz.entity.util.EntityCrypto$ShiroStorageHandler.encryptValue(EntityCrypto.java:293)

Jacques

Le 18/12/2020 à 14:41, Jacques Le Roux a écrit :

Hi,

This does not make sense at all. As it works locally I thought 
https://github.com/apache/ofbiz-framework/commit/6c34142b60cebdd0b64d31d917a7fa4b0cd476ec/ would fix it.


But it does not, though it works in demo too. But I see an issue with some data (credentials for instance) not loaded there, checking that. I need 
to restart the demos...


Jacques

Le 17/12/2020 à 18:51, build...@apache.org a écrit :

The Buildbot has detected a build exception on builder ofbizTrunkFramework 
while building ofbiz-framework. Full details are available at:
https://ci.apache.org/builders/ofbizTrunkFramework/builds/2012

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf947_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'onTrunkFrameworkCommit' 
triggered this build
Build Source Stamp: [branch trunk] f016e5da2309a775090a71d2f679746260ec6f09
Blamelist: Jacques Le Roux 

BUILD FAILED: exception build upload test-results part 1

Sincerely,
  -The Buildbot

Even more Github features added to .asf.yaml

[jler...@apache.org]

Hi,

As you may know we have a .asf.yaml file and there are new features: 
https://blogs.apache.org/infra/entry/even-more-github-features-added

It's well explained at: 
https://github.com/apache/infrastructure-puppet/pull/1678

I had a look, maybe?

   <>

Not sure it's needed, I think the community care enough

Jacques

Re: buildbot exception in on ofbizTrunkFramework

[jler...@apache.org]

Thanks Michael,

I just needed batik:batik-svg-dom:1.6-1 so simply replaced 
org.apache.xmlgraphics:batik:1.13

Cheers

Jacques

Re: [ofbiz-site] branch master updated: Makes API names consistent and durable Users know what they are using

[jler...@apache.org]

Hi,

We can add a global version heading using the Gradle title Javadoc option:

https://docs.gradle.org/current/dsl/org.gradle.api.tasks.javadoc.Javadoc.html

I'll create a Jira for that

Jacques

Le 12/08/2020 à 08:59, jler...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/ofbiz-site.git


The following commit(s) were added to refs/heads/master by this push:
  new a6a71fb  Makes API names consistent and durable Users know what they 
are using
a6a71fb is described below

commit a6a71fb3093de48cd1be5aecc67a1bb1ff84ab49
Author: Jacques Le Roux 
AuthorDate: Wed Aug 12 08:58:53 2020 +0200

 Makes API names consistent and durable
 Users know what they are using
---
  404.html |  8 
  about-ofbiz.html |  8 
  business-users.html  |  8 
  developers.html  | 20 ++--
  download.html|  8 
  faqs.html|  8 
  getting-involved.html|  8 
  index.html   |  8 
  mailing-lists.html   |  8 
  ofbiz-demos.html |  8 
  release-notes-12.04.06.html  |  8 
  release-notes-13.07.01.html  |  8 
  release-notes-13.07.02.html  |  8 
  release-notes-13.07.03.html  |  8 
  release-notes-16.11.01.html  |  8 
  release-notes-16.11.02.html  |  8 
  release-notes-16.11.03.html  |  8 
  release-notes-16.11.04.html  |  8 
  release-notes-16.11.05.html  |  8 
  release-notes-16.11.06.html  |  8 
  release-notes-16.11.07.html  |  8 
  release-notes-17.12.01.html  |  8 
  release-notes-17.12.03.html  |  8 
  release-notes-17.12.04.html  |  8 
  security.html|  8 
  service-providers.html   |  8 
  source-repositories.html |  8 
  template/page/developers.tpl.php | 12 ++--
  template/region/header.tpl.php   |  8 
  user-stories.html|  8 
  30 files changed, 128 insertions(+), 128 deletions(-)

diff --git a/404.html b/404.html
index bf3a06a..3165d85 100644
--- a/404.html
+++ b/404.html
@@ -67,13 +67,13 @@
  Wiki
  API Reference

-
+
Trunk API
  
-
-  Release 17.12 API
+
+  Stable Release API
  
-
+
Next Release API
  

diff --git a/about-ofbiz.html b/about-ofbiz.html
index aaafea4..2489fac 100644
--- a/about-ofbiz.html
+++ b/about-ofbiz.html
@@ -67,13 +67,13 @@
  Wiki
  API Reference

-
+
Trunk API
  
-
-  Release 17.12 API
+
+  Stable Release API
  
-
+
Next Release API
  

diff --git a/business-users.html b/business-users.html
index d74ed8c..f4cc2d0 100644
--- a/business-users.html
+++ b/business-users.html
@@ -67,13 +67,13 @@
  Wiki
  API Reference

-
+
Trunk API
  
-
-  Release 17.12 API
+
+  Stable Release API
  
-
+
Next Release API
  

diff --git a/developers.html b/developers.html
index a2e72f9..b69c276 100644
--- a/developers.html
+++ b/developers.html
@@ -67,13 +67,13 @@
  Wiki
  API Reference

-
+
Trunk API
  
-
-  Release 17.12 API
+
+  Stable Release API
  
-
+
Next Release API
  

@@ -269,14 +269,14 @@
  
  OFBiz API Reference
  
-  
- Trunk API Reference
+  
+ Trunk API

-  
- Release 17.12 API Reference
+  
+ Stable release API

-  
- Next

Re: [ofbiz-site] branch master updated: Info about disabling demos

[jler...@apache.org]

BTW we have this report:

https://github.com/apache/ofbiz-site/network/alerts

I did not check details, maybe we need to update Bootstrap?

Jacques

Le 11/08/2020 à 13:53, jler...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/ofbiz-site.git


The following commit(s) were added to refs/heads/master by this push:
  new 6b46338  Info about disabling demos
6b46338 is described below

commit 6b4633867a6042f3facbe6939c392f6c55fd1791
Author: Jacques Le Roux 
AuthorDate: Tue Aug 11 13:53:31 2020 +0200

 Info about disabling demos
---
  ofbiz-demos.html  | 2 +-
  template/page/ofbiz-demos.tpl.php | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/ofbiz-demos.html b/ofbiz-demos.html
index 00fdffd..5efbe2a 100644
--- a/ofbiz-demos.html
+++ b/ofbiz-demos.html
@@ -137,7 +137,7 @@

  

-About our Demos
+About our Demos  Our demos are currently disabled for 
security reason
  
  We have several online OFBiz demos that you can try out. Each demo is 
split into two areas:
  
diff --git a/template/page/ofbiz-demos.tpl.php 
b/template/page/ofbiz-demos.tpl.php
index 0dd158b..135c98c 100644
--- a/template/page/ofbiz-demos.tpl.php
+++ b/template/page/ofbiz-demos.tpl.php
@@ -27,7 +27,7 @@

  

-About our Demos
+About our Demos  Our demos are currently disabled for 
security reason
  
  We have several online OFBiz demos that you can try out. Each demo is 
split into two areas:
  

Re: [ofbiz-framework] 02/03: Improved: Put the AsciiDoc files in main repo under the web site (OFBIZ-11879)

[jler...@apache.org]

Hi,

There is a warning saying:

> Task :generateReadmeFiles
juil. 11, 2020 9:29:14 AM 
uri:classloader:/gems/asciidoctor-pdf-1.5.3/lib/asciidoctor/pdf/converter.rb 
resolve_image_path
AVERTISSEMENT: allow-uri-read is not enabled; cannot embed remote image: 
https://img.shields.io/badge/License-Apache%202.0-blue.svg
allow-uri-read is not enabled; cannot embed remote image: https://img.shields.io/badge/License-Apache%202.0-blue.svg 
(uri:classloader:/gems/asciidoctor-pdf-1.5.3/lib/asciidoctor/pdf/converter.rb:resolve_image_path)


But it actually works, the image is in the files.

I'll also create a Jira to check AsciiDoc errors I found while running and an 
initial not committed version of generateReadmeFiles

Jacques

Le 11/07/2020 à 09:58, jler...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a commit to branch release18.12
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git

commit fd3667b6f7479a13f2a2ffd04378f53677b7cd3d
Author: Jacques Le Roux 
AuthorDate: Sat Jul 11 09:45:49 2020 +0200

 Improved: Put the AsciiDoc files in main repo under the web site 
(OFBIZ-11879)
 
 We have AsciiDoc files in main repo and it would be better to have them also in

 HTML format under the web site: https://ci.apache.org/projects/ofbiz/site
 
 For that a new generateReadmeFiles is needed and new "readme" locations under

 each of https://ci.apache.org/projects/ofbiz/site "sub-dirs".
 We can create those from Buildbot like we did with INFRA-20311
---
  build.gradle | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/build.gradle b/build.gradle
index 03355cf..e2ceeac 100644
--- a/build.gradle
+++ b/build.gradle
@@ -549,6 +549,16 @@ task deleteAllPluginsDocumentation {
  }
  
  
+task generateReadmeFiles(group: docsGroup, type: AsciidoctorTask) {

+doFirst { delete "${buildDir}/asciidoc/readme" }
+description 'Generate OFBiz README files'
+sourceDir "${rootDir}"
+sources {
+include 'README.adoc', 'CHANGELOG.adoc', 'CONTRIBUTING.adoc'
+  }
+outputDir file("${buildDir}/asciidoc/readme/")
+}
+
  task generateOfbizDocumentation(group: docsGroup, type: AsciidoctorTask) {
  dependsOn deleteOfbizDocumentation
  description 'Generate OFBiz documentation manuals'

[CVE-2019-0235 ] Apache OFBiz multiple CSRF vulnerabilities

[jler...@apache.org]

Severity:
Important

Vendor:
The Apache Software Foundation

Versions Affected:
OFBiz 17.12.01

Description:
Apache OFBiz is vulnerable to CSRF attacks

Mitigation:
Upgrade to 17.12.03 or manually apply the commits at OFBIZ-11470


Credit:
Initially known by the OFBiz security team (OFBIZ-10427),
also reported later by
Man Yue Mo via RT 
Shuibo Ye 
Vikash Patnaik 
Sonali Agrahari 
Girish Vasmatkar 
Dinesh Kumar Mohanty 
Jason Nordenstam 
Pradeep Jairamani 
Faiz Zaidi 

References:
https://ofbiz.apache.org/security.html

Re: [ofbiz-framework] branch trunk updated: Improved: no functional change

[jler...@apache.org]

I have finally decided to backport this (low) security issue.

It's easy to do so, better to be safe than sorry.

Jacques

Le 20/03/2020 à 10:51, jler...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git


The following commit(s) were added to refs/heads/trunk by this push:
  new b6a796c  Improved: no functional change
b6a796c is described below

commit b6a796cbdfc662459a4b52a01f0a9b67c18e7c30
Author: Jacques Le Roux 
AuthorDate: Fri Mar 20 10:51:49 2020 +0100

 Improved: no functional change
 
 Adds "Content-Security-Policy" frame-ancestors="self" in ErrorPage.ftl

 Because this page is used as a HTTP 500 error it's more susceptible to
 clickjacking
 
 Quoting OWASP ZAP:

 This problem still applies to error-type pages (401, 403, 500, etc.), as 
these
 pages are still often affected by injection problems, in which case it is 
still
 possible that browsers may interpret pages differently from their actual 
content
 type.
 
 I tried to work on other file types that were also reported but it's complicated

 adn I believe it's not worth it
---
  themes/common-theme/template/ErrorPage.ftl | 1 +
  1 file changed, 1 insertion(+)

diff --git a/themes/common-theme/template/ErrorPage.ftl 
b/themes/common-theme/template/ErrorPage.ftl
index 47f7caf..9be67b0 100644
--- a/themes/common-theme/template/ErrorPage.ftl
+++ b/themes/common-theme/template/ErrorPage.ftl
@@ -19,6 +19,7 @@ under the License.
  
  
  
+
  500 Internal error
  

Re: [ofbiz-framework] 01/03: Improved: Implemented: Documented: Completed: Reverted: Fixed: Improved: no functional change (OFBIZ-) Explanation Thanks:

[jler...@apache.org]

Sometimes things get complicated when cherry-pick fails and you forget 
something. Here I forgot the commit comment.

I prefer to let it like that, it's too late to amend :/

It was for OFBIZ-11407

Le 25/02/2020 à 15:57, jler...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a commit to branch release17.12
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git

commit fee85b4a4212c9cd8a9f722481f17f498ba67a5f
Author: Jacques Le Roux 
AuthorDate: Tue Feb 25 15:50:19 2020 +0100

 Improved:
 Implemented:
 Documented:
 Completed:
 Reverted:
 Fixed:
 Improved: no functional change
 (OFBIZ-)
 Explanation
 Thanks:
---
  build.gradle | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/build.gradle b/build.gradle
index f0449bf..3af6173 100644
--- a/build.gradle
+++ b/build.gradle
@@ -141,10 +141,10 @@ dependencies {
  compile 'org.apache.tika:tika-core:1.20'
  compile 'org.apache.tika:tika-parsers:1.20'
  compile 'org.apache.poi:poi:3.17'
-compile 'org.apache.tomcat:tomcat-catalina-ha:9.0.19'
-compile 'org.apache.tomcat:tomcat-catalina:9.0.19'
-compile 'org.apache.tomcat:tomcat-jasper:9.0.19'
-compile 'org.apache.tomcat:tomcat-tribes:9.0.19'
+compile 'org.apache.tomcat:tomcat-catalina-ha:9.0.31'
+compile 'org.apache.tomcat:tomcat-catalina:9.0.31'
+compile 'org.apache.tomcat:tomcat-jasper:9.0.31'
+compile 'org.apache.tomcat:tomcat-tribes:9.0.31'
  compile 'org.apache.xmlgraphics:fop:2.2'
  compile 'org.apache.xmlrpc:xmlrpc-client:3.1.3'
  compile 'org.apache.xmlrpc:xmlrpc-server:3.1.3'

Re: [ofbiz-framework] branch pr/13 created (now ae98498)

[jler...@apache.org]

Not sure how and why this happened and what it's for...

Do we need to document that?

Le 12/02/2020 à 12:11, jler...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a change to branch pr/13
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git.


   at ae98498  Implemented: Add 'controlPath' attribute

No new revisions were added by this update.

Re: [ofbiz-framework] branch trunk updated: Fixed: Cannot run ComponentContainerTest on windows (OFBIZ-11331)

[jler...@apache.org]

Le 28/01/2020 à 18:36, jler...@apache.org a écrit :

commit c672c3a30453039b8b724ff8d604b244a4dde19f
[...]
 PR created: #8
 
 Thanks: Daniel WatfordNina Simone - My Baby Just Cares For Me.mp3


Maybe some noticed, of course "Nina Simone" as nothing to do w/ that.

Just a C/P which inadvertently slipped in, while my machine was busy following 
me :D

Jacques

Re: [ofbiz-framework] branch trunk updated (6f39741 -> 6d194cf)

[jler...@apache.org]

This is in relation with "Github PRs and Jira" thread 
(https://markmail.org/message/s422zuivbmzglph4)

Below is my 1st experience of GitHub PR merge in the context of ASF dual 
hosting with GitBox. So I somehow made a jump in the void...

After reviewing the change I picked "squash and merge PR" among the 3 GitHub PR merge options. Because I did not want to break the linear Git flow, it 
seemed the best option. But despite "squashing" we got  3 commits; 2 from Daniel Watford and one from I. I don't know if it's possible to do otherwise 
with the 2 other options. Maybe it's good to know that Daniel contributed...


Also I expected that my comment in GitHub would be used as the final commit comment. So I then tried to amend the commit by modifying ONLY the 
comment, and then push comment after a pull. But I got a fast-forward issue and after trying several pull and push tricks I understood I'll never pass 
over this issue:


   "[remote rejected]   trunk -> trunk (pre-receive hook declined)"

Because it's related to having "receive.denynonfastforwards" set to true on GitBox server[1] and I don't want to annoy Infra to temporary set it true 
for a such change.


But I really wanted to change the commit comment to follow our template. So I decided to pull rebase, slightly change the ComponentContainerTest 
class, commit and push. Hence I created a new commit, somehow a duplicate of the PR merge, at least with a correctly formatted comment.


This was an awkward experience, I don't know if i could have done it better, 
ideas, advices?
Maybe advising contributors to use our template in commit comments used by 
GitHub PRs?
Also we can ask our contributors to use in the PRs title the format of our 
commit template. For instance in[2] instead of

   OFBIZ-11331: Allow ComponentContainerTest to run on windows
   rather
   Fixed: Allow ComponentContainerTest to run on windows (OFBIZ-11331)

   Then the commit/s would contain the explanations.

I just fear we will have sometimes to explain, and ask contributors to edit 
their comments or titles...

I'll sleep on it and wait for comments before doing any additions or changes in our documentation about that, in relation with the "Github PRs and 
Jira" thread


Thanks

Jacques
[1] 
https://stackoverflow.com/questions/253055/how-do-i-push-amended-commit-to-the-remote-git-repository
[2] 
https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;a=commit;h=6d194cf8c363435e212282e31f575ca93f14d72d


Le 28/01/2020 à 15:58, jler...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a change to branch trunk
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git.


 from 6f39741  Fixed: Fixed the issue on party page that will upload the 
data each time after refreshing the page. (OFBIZ-11325)
  add 0c2124a  Get Path from URI than a string representation of a file 
path when building Path to test resources.
  add 259f71d  Removed unused test imports.
  new 6d194cf  OFBIZ-11331: Allow ComponentContainerTest to run on windows 
(#8)

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
  .../apache/ofbiz/base/container/ComponentContainerTest.java  | 12 +++-
  1 file changed, 7 insertions(+), 5 deletions(-)

Re: Removing the ‘:terminateOfbiz’ Gradle task

[jler...@apache.org]

+1

This is currently also used by the demos because "ofbiz --shutdown" does not 
work with multiple instances

https://svn.apache.org/repos/asf/ofbiz/tools/demo-backup/trunk.sh

Of course resolving "ofbiz --shutdown" issue would be better. But I guess few 
people use multiple instances in production on the same server.

Jacques

Le 17/03/2019 à 22:39, Taher Alkhateeb a écrit :

I think I might prefer to keep it. Perhaps adjusting the ps command might
better solve the issue. I use this feature regularly myself.

On Sun, Mar 17, 2019, 11:59 PM Mathieu Lirzin 
wrote:


Hello,

The ‘:terminateOfbiz’ Gradle task is meant to be run when ‘./gradlew
ofbiz --shutdown’ doesn't work.  Unfortunately this task is not working
on my GNU/linux system because the output of ‘ps ax’ cuts long lines.
As a consequence Gradle is not able to grep
"org.apache.ofbiz.base.start.Start" even if it is actually part of the
process command line as seen by the operating system.  As a reminder,
here is the implementation of that task:

 task terminateOfbiz(group: ofbizServer,
 description: 'Force termination of any running OFBiz servers, only
use if \"--shutdown\" command fails') {
 doLast {
 if (os.contains('windows')) {
 Runtime.getRuntime().exec("wmic process where
\"CommandLine Like \'%org.apache.ofbiz.base.start.Start%\'\" Call
Terminate")
 } else {
 def processOutput = new ByteArrayOutputStream()
 exec {
 commandLine 'ps', 'ax'
 standardOutput = processOutput
 }

processOutput.toString().split(System.lineSeparator()).each { line ->
 if (line ==~
/.*org\.apache\.ofbiz\.base\.start\.Start.*/) {
 exec { commandLine 'kill', '-9',
line.tokenize().first() }
 }
 }
 }
 }
 }

While it might be considered a bug at first hand, I personnally think
this failure is more a symptom of a desperate endeavour which is to
guess how the system of a user is managing its processes.  As a
consequence I will suggest to simply remove this task to not make false
promises to users and let them manage the processes on their system by
themselves. :-)

What do people think?

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [DISCUSSION] Remove mask feature for date-time fields

[jler...@apache.org]

This is also related: https://issues.apache.org/jira/browse/OFBIZ-7532

Jacques

Le 16/12/2018 à 12:47, Jacques Le Roux a écrit :

Yes it is somehow related, but not the same.

Jacques

Le 16/12/2018 à 11:25, Pierre Smits a écrit :

Hey Jacques,

Is this, in a way, connected (or relevant to)
https://issues.apache.org/jira/browse/OFBIZ-10152 ?

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Sun, Dec 16, 2018 at 11:18 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Yes we could open a Jira for that

Jacques

Le 15/12/2018 à 14:35, Taher Alkhateeb a écrit :

why not resolve conflicts?

On Sat, Dec 15, 2018 at 3:48 PM Jacques Le Roux
 wrote:

Hi,

I was looking at https://issues.apache.org/jira/browse/OFBIZ-6734 and

specifically the comment I made there about mask feature for date-time
fields.

The masked input for date-time fields does not work as it should

(compare behaviour of the 1st field of

https://demo-trunk.ofbiz.apache.org/example/control/FormWidgetExamples

and https://igorescobar.github.io/jQuery-Mask-Plugin/)

I think there is a conflict between the calendar which is used by

default with date-time fields and the masked input feature. So masked input
feature

is ignored and adds nothing to date-time fields which is confusing.

I propose to remove this feature, what do you think?

Also the // is demonstrated there, and only

used there, but does nothing.

As it ever working or is /
replacement/?

/Should we not clear that also (ie remove this demonstrating field and

the feature at large)?

//

Thanks

Jacques

Re: AsciiDoc generated online documentation and releases

[jler...@apache.org]

Thanks all,

It seems nobody is against backporting, so I'll continue with OFBIZ-10651 and 
OFBIZ-10652

I already generate the documentation from the trunk under https://ci.apache.org/projects/ofbiz/site/. I'll  swap to R17 after backporting necessary, 
as the documentation should preferably be provided for users, developers can always generate it locally.


Note: After upgrading asciidoctor-gradle-plugin this message shows when 
generating the documentation

   Implicit attributes projectdir and rootdir are deprecated and will no longer 
be set in 2.0. Please migrate your documents to use gradle-projectdir
   and gradle-rootdir instead.

It's a known issue and will be fixed soon: 
https://github.com/asciidoctor/asciidoctor-gradle-plugin/issues/270

Also, so far in Buildbot log only (not locally) I saw a message saying

   asciidoctor: WARNING: could not embed image:
   
/home/buildslave/slave/ofbizTrunkFrameworkPlugins/build/plugins/birt/src/docs/asciidoc/images/Report-Master.png;
 PNG uses unsupported interlace
   method

Anyway, despite that the image is embedded even in 
https://ci.apache.org/projects/ofbiz/site/pluginsdoc/birt/html5/birt.html

Also at r1847177  I formatted too long lines in wa-cross-domains-SSO.adoc. I'll do the same later to the Birt Flexible Reports doc that I imported 
from text files.


I noticed that AsciidocFX wraps line by default (only view, no formatting option[1]) but there is no option for that in Eclipse Asciidoc Editor 
plugin. I don't know for IntelliJ.


[1] https://github.com/asciidocfx/AsciidocFX/issues/205

Jacques


Le 22/11/2018 à 05:29, Aditya Sharma a écrit :

+1 for backport

Thanks and Regards,

*Aditya Sharma* | Enterprise Software Engineer
HotWax Commerce  by HotWax Systems

[image: https://www.linkedin.com/in/aditya-p-sharma/]



On Thu, Nov 22, 2018 at 9:53 AM Arun Patidar 
wrote:


+1 for backport

On Fri, Nov 16, 2018, 2:53 PM Rishi Solanki 
wrote:


+1 for backport.

--
Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co


On Thu, Nov 15, 2018 at 10:56 PM Pierre Smits 
wrote:


Hi Jacques,

I support the suggestion made by Sharan. It should not be too

difficult,

when a release has been made available (this should be part of the

release

activities), to generate the 'release' related documents and hook it

into

the website. Our (potential) adopters will benefit.


Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without

privileges)

since 2008*
Apache Steve , committer


On Thu, Nov 15, 2018 at 12:59 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


At


https://cwiki.apache.org/confluence/display/OFBIZ/Draft+Documentation+Roadmap

Sharan already suggested to "Backport to releases where possible"

I think we should do that and not way R18 to use the AsciiDoc

generation

even if it's not complete

Opinions before I get ahead?

Jacques


Le 14/11/2018 à 08:41, Jacques Le Roux a écrit :

Hi,

So start this discussion, currently our main documents in

docs\asciidoc

refer to the R17 release. But those document don't exist in R17

branch.

I think it's not too late to backport them, but do we want to do

so?

Also I suggested to have an easy access to the documentation from

the

site documentation page.

Do we also want to use the AsciiDoc generated documentation as we

did

to

provide an online help from the applications?

Do we want to provide something like

https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML?

For me the answers to these questions is NO! We should have a sole

entry

point for the documentation and it should be from the site

documentation

page. It's then easy to provide links from there (using anchors

going

to

automatically generated IDs sections)

What are your opinions? (I know I should re-read this thread

https://markmail.org/message/35ak34fpzlyjiopt and I started...)

Jacques

"rememberMe" is not used

[jler...@apache.org]

Hi,

While working on OFBIZ-10635 I noticed this block of code in 
LoginEvents::storeLogin

    if ("Y".equals(request.getParameter("rememberMe"))) {
    setUsername(request, response);
    }

It was added by Andrew long ago: https://markmail.org/message/dmqqxse65inh6amr

But rememberMe is never created  in code so LoginEvents::setUsername is never 
used.

I think we should remove this  block of code and the 2 related methods below.

I will do in a week w/o opinions.

--
Jacques

Re: Shipping data duplicated

[jler...@apache.org]

Hi Rishi,

Inline...


Le 22/09/2018 à 12:34, Rishi Solanki a écrit :

Jacques,
Thanks for more insights.
IMO, we should rename the files as you suggested and also add some
description in the file so that we won't confuse by this in future. And
also we should keep the duplicate data as well, because when ofbizsetup app
set the data for store I assume we don't load the demo data.
About the ofbizsetup app uses, right now I could not think of it. But will
get back on it soon with details and get the inputs from community. For now
my understanding is to rename the setup files and let duplicate data exists
in the setup files.
Let me know if we can proceed with the above plan then will rename the
files and do the needful changes in the setup code.

Agreed, I created OFBIZ-10598 for that


On ofbizsetup app we
will discuss once I come with more details.

Yes no hurry, I think it needs a bit more review, love and 
documentation/information
Maybe starting by completing 
https://cwiki.apache.org/confluence/display/OFBENDUSER/How+to+Install+OFBiz+without+the+Demo+Data
 ?

Jacques



Thanks!

--
Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co


On Sat, Sep 22, 2018 at 2:10 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Rishi,

Thanks for your feedback.

Looking closely at history, ShippingData.xml was put in 9 years ago with
http://svn.apache.org/viewvc?view=revision=816083, so for the
ofbizsetup app, which is a bit weirdo in OFBiz.

Then was modified with OFBIZ-5890 and OFBIZ-7673

Rest inline...


Le 22/09/2018 à 09:27, Rishi Solanki a écrit :

Hi Jacques,
I dig into it today and found that the data exists in the
"applications/datamodel/data/demo/OrderDemoData.xml" was moved from
"applications/order/data/DemoShipping.xml"
Also the data claimed as duplicate in
"applications/commonext/data/ShippingData.xml" is similar but not exact
matches with OrderDemoData.xml.

Yes, I was only speaking about "Shipping data", ie:
ShipmentMethodType
CarrierShipmentMethod
QuantityBreak
ShipmentBoxType

Those are real duplicate

The ShippingData.xml  file has no entry in
any ofbiz-component.xml.

Indeed, they are only used by the setup app. In SetupEvents.xml there is

 
 

Reading that, now I think we should not only keep the "Shipping data" in
ShippingData.xml but also the file. I would rather rename this file and
other ofbizsetup related files (at least data files) with a Setup prefix
to clearly signal they are  part of this app.
But I also wonder if the ofbizsetup app is still alive, maintained and
used by users. Last time I tried I crossed issues (not biggie IIRW). I
found
this https://issues.apache.org/jira/issues/?filter=12344840

What do you think?

Jacques

So here we can decide weather we should keep that data in

ShippingData.xml

(if someone introduce the file intentionally) or we can remove it from
trunk. In case no objection I would like to remove it as most data is
duplicate.

--
Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co


On Sat, Aug 18, 2018 at 1:17 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Rishi!

Jacques


Le 17/08/2018 à 15:19, Rishi Solanki a écrit :

This should be part of effort when we were moving all the seed, ext,

demo

data to datamodel component. I see there is no entry to load the
ShippingData.xml.
I will check this in next week and fix the duplicate data exists in the
system, or share the the reason of having this.

Probably, data moved but not removed from commonext. But I'll confirm

and

get back.

Thanks!



Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co

On Wed, Aug 15, 2018 at 10:10 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

Is there a reason why Shipping data are now duplicated in trunk at

   applications/commonext/data/ShippingData.xml

and

   /applications/datamodel/data/demo/OrderDemoData.xml

This is not the case with current stable

Jacques

Re: Missing Security Headers in CMS Events

[jler...@apache.org]

Good catch Deepak,

A Jira fits

Jacques


Le 08/10/2018 à 07:02, Deepak Nigam a écrit :

Hello All,

While rendering the view through the controller request we set the
important security headers like x-frame-options, strict-transport-security,
x-content-type-options, X-XSS-Protection and Referrer-Policy etc. in the
response object. (Please see the 'rendervView' method of RequestHandler
class.) But these security headers are missing in the pages rendered
through CMS. (Please visit the CmsEvents class).

These headers are very crucial for the security of the application as they
help to prevent various security threats like cross-site scripting,
cross-site request forgery, clickjacking etc.

IMO, we should add these security headers in the response object prepared
through the CMS also. WDYT?

Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd.

Re: Missing Security Headers in CMS Events

[jler...@apache.org]

They are put in in RequesHandler. There is a "Security header" block

Jacques


Le 08/10/2018 à 09:17, Taher Alkhateeb a écrit :

Hi Deepak,

Sounds good. Are these headers applied everywhere except CMS? If no then
why not apply them everywhere?


On Mon, Oct 8, 2018, 9:03 AM Deepak Nigam 
wrote:


Hello All,

While rendering the view through the controller request we set the
important security headers like x-frame-options, strict-transport-security,
x-content-type-options, X-XSS-Protection and Referrer-Policy etc. in the
response object. (Please see the 'rendervView' method of RequestHandler
class.) But these security headers are missing in the pages rendered
through CMS. (Please visit the CmsEvents class).

These headers are very crucial for the security of the application as they
help to prevent various security threats like cross-site scripting,
cross-site request forgery, clickjacking etc.

IMO, we should add these security headers in the response object prepared
through the CMS also. WDYT?

Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd.

Re: svn commit: r1842921 - /ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/ical/WEB-INF/web.xml

[jler...@apache.org]

Please feel free if you see a better way

Jacques


Le 05/10/2018 à 16:25, Taher Alkhateeb a écrit :

This workaround looks ugly, can't we relocate this URL?
On Fri, Oct 5, 2018 at 5:22 PM  wrote:

Author: jleroux
Date: Fri Oct  5 14:22:15 2018
New Revision: 1842921

URL: http://svn.apache.org/viewvc?rev=1842921=rev
Log:
Fixed: The query iCalendar/CALENDAR_PUB_DEMO/ no longer work
(OFBIZ-10595)

ControlFilter does not allow the untypical iCalendar/CALENDAR_PUB_DEMO/ query
to pass.
I have not checked deep, but since R13 works I believe it's due to OFBIZ-6760
where ControlFilter was added. Then CALENDAR_PUB_DEMO/ is considered a
[Filtered request] and the whole iCalendar process in Thunderbird Calendar is
broken

Thanks:  Jyri Sillanpaa for the detailled report

Modified:
 
ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/ical/WEB-INF/web.xml

Modified: 
ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/ical/WEB-INF/web.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/ical/WEB-INF/web.xml?rev=1842921=1842920=1842921=diff
==
--- 
ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/ical/WEB-INF/web.xml 
(original)
+++ 
ofbiz/ofbiz-framework/trunk/applications/workeffort/webapp/ical/WEB-INF/web.xml 
Fri Oct  5 14:22:15 2018
@@ -44,7 +44,7 @@ under the License.
  
org.apache.ofbiz.webapp.control.ControlFilter
  
  allowedPaths
-
/error:/control:/select:/index.html:/index.jsp:/default.html:/default.jsp:/images
+
/error:/control:/select:/index.html:/index.jsp:/default.html:/default.jsp:/images:/CALENDAR_PUB_DEMO
  
  
  redirectPath

Re: [jira] [Commented] (OFBIZ-8230) Disentangle platform specific entity engine schemas

[jler...@apache.org]

Le 07/01/2018 à 11:43, Jacques Le Roux a écrit :

My answer to your question is: we should keep them of course, except if a 
better way would be proposed, I see none for now...

I must have said: I see none PROVIDED for now...

We could consider a modular solution which would include split parts of the 
file in the remaining main, but  I'm not sure it's worth it

Remove unused labels?

[jler...@apache.org]

Hi,

While working on OFBIZ-8154 I noticed that the labels beginning by 
"HumanResServices." are never used.

So, it's a pity, but I think they should be removed. Actually my question is 
more if we agree about removing all unused labels, not only those ones.

Thanks

Re: Jars in LICENCE?

[jler...@apache.org]

Also forgot to report that Ant has lib\optional folder with 3 not documented 
jars there.
So as long as it's optional you don't need to reference it in the LICENSE file.
We use OPTIONAL_LIBRARIES for that as a convenience to users.

Jacques

Le 24/08/2016 à 15:04, Jacques Le Roux a écrit :

OK, I did my homework and here is what I found. I looked at 3 TLPs: Tomcat, Ant 
& JMeter last releases.

Globally they all document in their LICENSE files the external libs they use in 
their source releases; but don't to so in their binary LICENSE files.

For instance Tomcat uses
org.apache.taglibs.standard.tlv and
org.apache.commons.daemon.support
in its binary release (not in source) but does not document it (same LICENSE file than in source release). I guess both class are used an optional 
component (did not check).


Same for Ant about Ivy. I though did not find any reference to the libs referenced in their lib/libraries.properties file which it is a bit like 
OFBiz using Gradle...


JMeter gives much references, a bit the way we currently do, but without paths since the libs are of course not in its source release. Paths are 
given for JavaScript files or other not Java types (in their bin folder)


To summarize, it seems that we still need to put jars references in our LICENSE file. But since the libs are not in OFBiz source release anymore but 
are downloaded by Gradle we can't use file paths.


2 things I still wonder about are:

1. Why Ant does not document the libs referenced in their 
lib/libraries.properties file. It could be that they are not used OOTB (ie 
optional) I did
   not check that yet
2. If we need to document all the externals libs used by OFBiz or only the one 
directly reference in build.gradle.

HTH

Jacques

Le 23/08/2016 à 11:42, Jacques Le Roux a écrit :

Right, it seems those days I'm working either too late or too early. I'll 
double check all my assertions.

I'm though quite happy with what I have found. Notably how jMeter organises 
external libs and documents it.
A such thing is mandatory when you use a tool like Maven or Gradle and want to 
deliver binary releases.

Thanks for the review!

Jacques


Le 23/08/2016 à 11:23, Jacopo Cappellato a écrit :

Specifically I have checked the binary release of Tomcat 8.5.4

Jacopo

On Tue, Aug 23, 2016 at 11:22 AM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:


Jacques,

see my comments inline:

On Tue, Aug 23, 2016 at 11:06 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


[...] So it should have been

"Tomcat nothing on ecj jar (Eclipse.org) in binary release" same for
JMeter



Please double check: I have checked the binary release as well and the
license is there too.

Regards,

Jacopo

Re: Taking a decision on remaining Jars in OFBiz

[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 

Sharing the burden of maintaining documentation

[jler...@apache.org]

Hi,

Not so long ago Jacopo suggested that we use our versionning system (ie currently Subversion) to maintain the documentation. Or at least the most 
important or entry points of the documentation which will still stay on our wiki (ie Confluence)


I think that by creating MarkDown files (or other types but we already started with README.ME for Gradle) and implementing 
https://issues.apache.org/jira/browse/OFBIZ-7723 "Use Pandoc to integrate our README.MD from repo to Confluence" we could not only easily share the 
burden of maintaining documentation but also have an easier and more reliable way for it (believe me Confluence has still its quirks when updating big 
pages)


So we would create .MD files and locally relies to transform them in .HTML files still in the svn repo, and then they should be automatically 
integrated and updated in Confluence by its  HTML connector plugin


These files would be in the trunk branch or the website one.

Opinions?

Re: Wiki documentation update with respect to Gradle

[jler...@apache.org]

Indirectly it was the repository, they should not accept things breaking other 
things down the flow ;)

This said I agree it's totally unrelated to exposing our users to Java.

Jacques


Le 19/08/2016 à 22:38, Taher Alkhateeb a écrit :

I would also like to mention that the issue you reported on the thread you
mentioned ( http://markmail.org/message/livdricudqdj6tmi ) turned out not
to have anything todo with repositories or Gradle. Instead it was an
exposed version of a library with a wrong header. Gradle was very stable
before and after fixing this issue that was transient only for a few days
until we discovered what was wrong (apache shiro exposed wrong version due
to change in dependencies).

So I would exclude that thread as a necessary reason for exposing our users
directly to Java.

On Fri, Aug 19, 2016 at 11:34 PM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:


Hi Jacques,

Okay based on your feedback I would suggest to create a special page /
section in the documentation that has the title "Deploying OFBiz on offline
servers" or something like that. I would rather hide this information from
a "standard" normal system setup and keep the corner cases away. What you
are mentioning is less common scenarios that are rather rare in this age
where cloud computing is the norm. This way, you keep things easy for our
new users while providing more information for those with special
deployment needs.

Regards,

Taher Alkhateeb

On Fri, Aug 19, 2016 at 11:10 PM, jler...@apache.org <jler...@apache.org>
wrote:


Taher

Actually I though more about it, we really need something like that.

Actually we need to help our users when they are in a situation like I
crossed once and reported here http://markmail.org/message/li
vdricudqdj6tmi :

"Also, as Pierre outlined, there are situations were you can't use Gradle
but on dev machines. I experienced that, no servers were allowed to connect
to the Internet at all..."

When I say that we need to help our users I mean that we need to lead
them to a solution, and even if possible provide an easy way for them to
build one.

In other words, if you have no access to Internet on production servers,
and still want to use Gradle as it comes OOTB, you need to create an use
your own repository.

This is what we are currently missing in the documentation. We don't need
to provide the mean, but at least to document how to do it. If we could
facilitate the needed work in this case it would be even better...

Jacques



Le 19/08/2016 à 18:22, Taher Alkhateeb a écrit :


Hi Jacques,

I think there should be an added value beyond "because it used to be
there". What is the purpose of keeping it with disclaimers in your
opinion?

Regards,

Taher Alkhateeb

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

Hi Taher,

I'd not be against (still in the lean way), but should we not keep at
least "java -jar build/libs/ofbiz.jar ?" (with disclaimer words of
precaution)?

What are other opinions?

Jacques



Le 19/08/2016 à 17:50, Taher Alkhateeb a écrit :

Hi Jacques,

On a quick skim through, I highly recommend removing completely any
traces
of "java -jar". The reason for my recommendation is that gradle
automates
the build process. Exposing end-users to how things happen means
exposing
them to implementation details. This has the following negative
outcomes:

- Users need to be aware of JVM arguments to properly execute commands
- Changes we might decide to do in the future would break existing
systems
because users are exposed to the details of how the system is
constructed.
- The ofbiz.jar which is constructed from gradle has hardcoded library
paths that depend on each user's computer setup. Any changes to the
setup
would not be reflected correctly using raw java commands. This would
probably confuse people a lot and debugging would be a pain. If you let
Gradle take over the whole thing then you minimize the confusion.
- The syntax for java -jar is more complex

So my recommendation is to replace every occurence of java -jar with
./gradlew "ofbiz --whatever-commands-here".

Taher Alkhateeb

On Fri, Aug 19, 2016 at 6:40 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi,


I have done some wiki documentation update with respect to Gradle
recently. Today I got issues with Confluence which broke my working
flow
on
the Apache OFBiz Technical Production Setup Guide <
https://cwiki.apache.org/confluence/display/OFBIZ/Apache+
OFBiz+Technical+Production+Setup+Guide> page more than once. So I'd
appreciate reviews, not only on this page but on all recently changed
pages. If you follow Confluence changes, you should be aware of them.

Thanks

Jacques

Re: Wiki documentation update with respect to Gradle

[jler...@apache.org]

Agreed, good idea

Jacques


Le 19/08/2016 à 22:34, Taher Alkhateeb a écrit :

Hi Jacques,

Okay based on your feedback I would suggest to create a special page /
section in the documentation that has the title "Deploying OFBiz on offline
servers" or something like that. I would rather hide this information from
a "standard" normal system setup and keep the corner cases away. What you
are mentioning is less common scenarios that are rather rare in this age
where cloud computing is the norm. This way, you keep things easy for our
new users while providing more information for those with special
deployment needs.

Regards,

Taher Alkhateeb

On Fri, Aug 19, 2016 at 11:10 PM, jler...@apache.org <jler...@apache.org>
wrote:


Taher

Actually I though more about it, we really need something like that.

Actually we need to help our users when they are in a situation like I
crossed once and reported here http://markmail.org/message/li
vdricudqdj6tmi :

"Also, as Pierre outlined, there are situations were you can't use Gradle
but on dev machines. I experienced that, no servers were allowed to connect
to the Internet at all..."

When I say that we need to help our users I mean that we need to lead them
to a solution, and even if possible provide an easy way for them to build
one.

In other words, if you have no access to Internet on production servers,
and still want to use Gradle as it comes OOTB, you need to create an use
your own repository.

This is what we are currently missing in the documentation. We don't need
to provide the mean, but at least to document how to do it. If we could
facilitate the needed work in this case it would be even better...

Jacques



Le 19/08/2016 à 18:22, Taher Alkhateeb a écrit :


Hi Jacques,

I think there should be an added value beyond "because it used to be
there". What is the purpose of keeping it with disclaimers in your
opinion?

Regards,

Taher Alkhateeb

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

Hi Taher,

I'd not be against (still in the lean way), but should we not keep at
least "java -jar build/libs/ofbiz.jar ?" (with disclaimer words of
precaution)?

What are other opinions?

Jacques



Le 19/08/2016 à 17:50, Taher Alkhateeb a écrit :

Hi Jacques,

On a quick skim through, I highly recommend removing completely any
traces
of "java -jar". The reason for my recommendation is that gradle
automates
the build process. Exposing end-users to how things happen means
exposing
them to implementation details. This has the following negative
outcomes:

- Users need to be aware of JVM arguments to properly execute commands
- Changes we might decide to do in the future would break existing
systems
because users are exposed to the details of how the system is
constructed.
- The ofbiz.jar which is constructed from gradle has hardcoded library
paths that depend on each user's computer setup. Any changes to the
setup
would not be reflected correctly using raw java commands. This would
probably confuse people a lot and debugging would be a pain. If you let
Gradle take over the whole thing then you minimize the confusion.
- The syntax for java -jar is more complex

So my recommendation is to replace every occurence of java -jar with
./gradlew "ofbiz --whatever-commands-here".

Taher Alkhateeb

On Fri, Aug 19, 2016 at 6:40 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi,


I have done some wiki documentation update with respect to Gradle
recently. Today I got issues with Confluence which broke my working
flow
on
the Apache OFBiz Technical Production Setup Guide <
https://cwiki.apache.org/confluence/display/OFBIZ/Apache+
OFBiz+Technical+Production+Setup+Guide> page more than once. So I'd
appreciate reviews, not only on this page but on all recently changed
pages. If you follow Confluence changes, you should be aware of them.

Thanks

Jacques

Re: Wiki documentation update with respect to Gradle

[jler...@apache.org]

Taher

Actually I though more about it, we really need something like that.

Actually we need to help our users when they are in a situation like I crossed 
once and reported here http://markmail.org/message/livdricudqdj6tmi :

"Also, as Pierre outlined, there are situations were you can't use Gradle but on dev machines. I experienced that, no servers were allowed to connect 
to the Internet at all..."


When I say that we need to help our users I mean that we need to lead them to a 
solution, and even if possible provide an easy way for them to build one.

In other words, if you have no access to Internet on production servers, and still want to use Gradle as it comes OOTB, you need to create an use your 
own repository.


This is what we are currently missing in the documentation. We don't need to provide the mean, but at least to document how to do it. If we could 
facilitate the needed work in this case it would be even better...


Jacques


Le 19/08/2016 à 18:22, Taher Alkhateeb a écrit :

Hi Jacques,

I think there should be an added value beyond "because it used to be
there". What is the purpose of keeping it with disclaimers in your opinion?

Regards,

Taher Alkhateeb

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


Hi Taher,

I'd not be against (still in the lean way), but should we not keep at
least "java -jar build/libs/ofbiz.jar ?" (with disclaimer words of
precaution)?

What are other opinions?

Jacques



Le 19/08/2016 à 17:50, Taher Alkhateeb a écrit :


Hi Jacques,

On a quick skim through, I highly recommend removing completely any traces
of "java -jar". The reason for my recommendation is that gradle automates
the build process. Exposing end-users to how things happen means exposing
them to implementation details. This has the following negative outcomes:

- Users need to be aware of JVM arguments to properly execute commands
- Changes we might decide to do in the future would break existing systems
because users are exposed to the details of how the system is constructed.
- The ofbiz.jar which is constructed from gradle has hardcoded library
paths that depend on each user's computer setup. Any changes to the setup
would not be reflected correctly using raw java commands. This would
probably confuse people a lot and debugging would be a pain. If you let
Gradle take over the whole thing then you minimize the confusion.
- The syntax for java -jar is more complex

So my recommendation is to replace every occurence of java -jar with
./gradlew "ofbiz --whatever-commands-here".

Taher Alkhateeb

On Fri, Aug 19, 2016 at 6:40 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi,

I have done some wiki documentation update with respect to Gradle
recently. Today I got issues with Confluence which broke my working flow
on
the Apache OFBiz Technical Production Setup Guide <
https://cwiki.apache.org/confluence/display/OFBIZ/Apache+
OFBiz+Technical+Production+Setup+Guide> page more than once. So I'd
appreciate reviews, not only on this page but on all recently changed
pages. If you follow Confluence changes, you should be aware of them.

Thanks

Jacques

Re: Product base promotion calculation

[jler...@apache.org]

At 99.99% you have no chances that an image get through ANY ASF ML. If you need to share you must find another way, easiest are Jira (if you need to 
create an issue anyway), then Nabble, else a lot of other options ;)


Jacques


Le 15/06/2016 à 15:59, Arvind singh tomar a écrit :

Hi Mridul

I have attached the screenshots but it seems like attachments are being omitted on the mailing list. Sending them again as inline images in case if 
it works.





​

On 15 June 2016 at 19:19, Mridul Pathak > wrote:

Hi Arvind,

Seems like you missed attaching the screenshot.

--
Thanks & Regards,
Mridul Pathak
Senior Manager
HotWax Systems
http://www.hotwaxsystems.com

> On Jun 15, 2016, at 7:16 PM, Arvind singh tomar > wrote:
>
> Hi Everyone,
>
> I found the behavior of product base promotion calculation a bit strange. 
Need your advice on whether it is correct behaviour or need some
improvement in promotion calculation.
>
> The promotion which I used was to give 30% discount for the item (i.e. 
RAM1GB_BRAND). I created a sales order with 10 quantity of the product.
During the promotion calculation, OFBiz created 10 OrderAdjustments, one 
for each quantity for the same promotion type.
>
> I was expecting that in the case if same Promotion is applicable for more 
than one quantity of a product then a single OrderAdjustment should
be created instead of creating one for each quantity. It is also messing up 
the UI.
>
> Attached the screenshots for the same.
>
>
> Thanks and Regards
> --
> Arvind Singh Tomar

CVE-2016-2170: Apache OFBiz information disclosure vulnerability

[jler...@apache.org]

==
CVE-2016-2170: Apache OFBiz information disclosure vulnerability

Severity: Important

Vendor:
The Apache Software Foundation

Versions Affected:
Apache OFBiz 13.07.02 and 13.07.01
Apache OFBiz 12.04.05 and earlier releases in the series (12.04.*)
The unsupported releases 11.04.*,  10.04.*  and 09.04 versions are also 
affected but not fixed.

Description:
The infamous Java serialization vulnerability

Mitigation:
13.07.* users should upgrade to 13.07.03
12.04.05 users should upgrade to 12.04.06 (Note though that in 12.04.06 RMI is 
not deactivated so you should use the recommended remediation: notsoserial)

Credit:
This infamous issue was confirmed to be an issue in OFBiz by the OFBiz team, 
due to two external Java libraries and RMI usage.

Remediation:
Apart when using RMI with 12.04.03 version nothing is needed. But with any version, if you use  JNDI, JMX or Spring and maybe other Java classes, 
please check the references (hint: use notsoserial with your own whitelist)


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

==

Fwd: Groovy at Apache

[jler...@apache.org]

Forwarded FYI

Jacques

 Message transféré 
Sujet : Groovy at Apache
Date :  Tue, 3 Mar 2015 12:16:52 +0100
De :Cédric Champeau cedric.champ...@gmail.com
Pour : 	elecha...@apache.org, bdelacre...@apache.org, Guillaume Laforge glafo...@gmail.com, Jochen Theodorou blackd...@gmx.org, Paul King 
pa...@asert.com.au

Copie à :   amania...@apache.org, r...@apache.org, ebo...@apache.org, 
jler...@apache.org



Hi everyone!

On behalf of the Groovy team, I am pleased to announce that we are going to submit a proposal to join the ASF. Thank you very much for the time you 
spent to answer our questions or concerns, and who knows maybe some of you will be willing to become mentors for the project?


The decision will be made public soon, we wanted to let you know before the 
news goes out.

Best regards,

Cédric

Re: FreeMarker 2.3.21 was released

[jler...@apache.org]

Thanks Daniel, Jacopo!

Good news for both projects

Jacques

Le 13/10/2014 10:03, Jacopo Cappellato a écrit :

Congratulations Daniel, to you and to the Freemarker community!
A few minutes ago I have upgraded the OFBiz trunk and the OFBiz 13.07 release 
branch to the new release.

Kind regards,

Jacopo


On Oct 12, 2014, at 10:07 PM, Daniel Dekany ddek...@freemail.hu wrote:


This version comes with, among many others, further improved error
messages, new range operators, streamlined conversions between XML
Schema formats and FTL types, possibility of using ISO 8601 or XML
Schema date/time/dateTime format as the default, improved overloaded
method selection (has to be explicitly enabled), setting for dealing
with JDBC date-only an time-only value zone issues, safer and more
memory-efficient way of managing object wrapper singletons, more
flexible configuring via string values (such as .properties file),
etc. See all the changes here:
http://freemarker.org/docs/versions_2_3_21.html

Note that with this release we have changed our proprietary BSD-style
license to the more familiar Apache License, Version 2.0.

You can download FreeMarker 2.3.21 here:
http://sourceforge.net/projects/freemarker/files/freemarker/2.3.21/freemarker-2.3.21.tar.gz/download

(Binary for Google App Engine:
http://sourceforge.net/projects/freemarker/files/freemarker/2.3.21/freemarker-gae-2.3.21.jar/download)

--
Thanks,
Daniel Dekany