Mailing-List: contact dev-help@tomee.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@tomee.apache.org
MIME-Version: 1.0
In-Reply-To: <CAGRgoZgvdCHnJL-8QO1SUVDTGQb6WcSt0HZmYBkCo3G++ke1uw@mail.gmail.com>
References: <CAGRgoZgediTOHmr7d3Vx6U+UTEs71+HTko_Bw=UrfqKUUUAD6A@mail.gmail.com>
 <CAPkio3HdwQA2h+sVynSFphYHbu09XEegeVtaudcOAm=oXxLO+g@mail.gmail.com>
 <CAGRgoZhAVbMXZVZWVKUs2w2hxbUoSYAN8Mresk1wyoycZbcPVQ@mail.gmail.com>
 <CAGRgoZiTiM0qs1JuM0t7A1TAgaJtWTOM2b_SxigbzwFhJHvnDw@mail.gmail.com>
 <CACLE=7NWsXsSn8yUW-VgqWOhrec1JzZ55b9UKHt_F8A5sCxm5Q@mail.gmail.com>
 <CAGRgoZiJ8v7e1Vn0z39wawTHfEQLy6LjbCW_cLqooqv4MD6=1Q@mail.gmail.com>
 <CACLE=7M=EN1KG4QnxBS3wioP4tV0hMss9eos-8zxtQ6NdfzzXA@mail.gmail.com>
 <7819854C-261B-4169-9AAE-AA6943854E7F@yahoo.de> <CAGRgoZj9zhstjgydVYy6Yvq0FEqGXYR+dou4ZYi3RbnRf9457w@mail.gmail.com>
 <9b481801-9f8a-bd26-e92d-64a883c83f18@tomitribe.com> <CAGRgoZgvdCHnJL-8QO1SUVDTGQb6WcSt0HZmYBkCo3G++ke1uw@mail.gmail.com>
From: Jonathan Gallimore <jonathan.gallimore@gmail.com>
Date: Mon, 18 Sep 2017 22:40:50 +0100
Message-ID: <CAGRgoZg5dVmBZo5KHwFTQpc0ED7rthjP22xVKMGYZ_LOJPrr6w@mail.gmail.com>
Subject: Re: JSTL
To: "dev@tomee.apache.org" <dev@tomee.apache.org>
Content-Type: multipart/alternative; boundary="001a113deaf4affce705597d983c"
archived-at: Mon, 18 Sep 2017 21:41:00 -0000

--001a113deaf4affce705597d983c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I took another look at the whole Tomcat Taglibs / Xalan thing today, and
have uncovered a few things:

* Xalan 2.7.1 has a CVE (https://nvd.nist.gov/vuln/detail/CVE-2014-0107),
and including a library with a CVE isn't ideal
* Using Xalan 2.7.2 seems to have a couple of issues where things don't
work quite right (happy to try and dig a bit deeper and try and provide an
example)
* Switching the Tomcat taglibs to not use Xalan really isn't terribly
straightforward. We switched over on master for performance reasons, so I
think some performance testing to get some numbers is probably merited in
order to double check that and compare, and also to ensure that changing it
doesn't negatively impact performance.

On the 1.7.x branch I previously noted that I switched back to
OpenEJB-JSTL. I have pushed a patch for CVE-2015-0254
<http://web.nvd.nist.gov/view/vuln/detail?vulnId=3DCVE-2015-0254> for that.

Jon

On Thu, Sep 14, 2017 at 8:36 PM, Jonathan Gallimore <
jonathan.gallimore@gmail.com> wrote:

> I'm +1. This feels like a reasonable approach to get the release going
> sooner rather than later, without a breaking change from 7.0.3. I am also
> in favour of coming back to this soon after release to try use the
> functionality in the JDK.
>
> Jon
>
> On Thu, Sep 14, 2017 at 8:31 PM, Andy Gumbrecht <agumbrecht@tomitribe.com=
>
> wrote:
>
>> Yes it's just xalan-2.7.2, and this solution seems to be/is painless
>> regarding the build and TCK. The Apache Standard Taglib requires it, alo=
ng
>> with serializer-2.7.2. What makes adding this a breaking issue Mark? If =
it
>> helps get a release out now to resolve a known CVE then it's +1 from me
>> (hmm that rhymes). Once it is out then we can spend several weeks workin=
g
>> on a better solution.
>>
>> Andy.
>>
>>
>>
>> On 14/09/17 21:00, Jonathan Gallimore wrote:
>>
>>> I believe its only xalan required, and not xerces as well.
>>>
>>> What's the rationale for the -1?
>>>
>>> We'd like to release 7.0.4, and the community appears to want a release
>>> based on feedback we have seen on the users list.
>>>
>>> Changing the jstlel library appears to be not-entirely-trivial (unless
>>> someone better than me wants to give some pointers). I'd like to try it=
,
>>> but I don't want it to drag on for ages and hold up a release.
>>>
>>> We already established that we'd like this to work out the box without
>>> requiring the user to add anything earlier in this thread.
>>>
>>> So, how do we want to proceed? The other option appears to be picking u=
p
>>> an
>>> updated version of the glassfish library we had before.
>>>
>>> Jon
>>>
>>> On 14 Sep 2017 13:26, "Mark Struberg" <struberg@yahoo.de.invalid> wrote=
:
>>>
>>> +1 to NOT have a hard xalan and xerces dependency.
>>>> Usually we don't need it but use the version which is packaged within
>>>> the
>>>> JRE.
>>>> It should really remain optional pretty please.
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>> Am 31.08.2017 um 16:25 schrieb Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com
>>>>> :
>>>>>
>>>>> Hmm, shout if wrong but think you misunderstood the "optional" in my
>>>>> sentence. I meant we patch trunk to remove the adherence to xalan.
>>>>>
>>>>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>>>>>
>>>> rmannibucau> |
>>>>
>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>>>>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>>>>
>>>>> 2017-08-31 15:41 GMT+02:00 Jonathan Gallimore <
>>>>>
>>>> jonathan.gallimore@gmail.com>
>>>>
>>>>> :
>>>>>
>>>>> Thanks Romain. That is definitely the simplest path - xalan is alread=
y
>>>>>> marked as an optional dependency, so we wouldn't need to do anything=
.
>>>>>>
>>>>> From
>>>>
>>>>> a compliance perspective, where would this leave us? Wouldn't we need
>>>>>>
>>>>> this
>>>>
>>>>> to work out of the box without adding libraries to be compliant? If i=
t
>>>>>> doesn't affect us in that respect, then I think we're probably good =
to
>>>>>>
>>>>> go.
>>>>
>>>>> Jon
>>>>>>
>>>>>> On Thu, Aug 31, 2017 at 1:57 PM, Romain Manni-Bucau <
>>>>>>
>>>>> rmannibucau@gmail.com
>>>>
>>>>> wrote:
>>>>>>
>>>>>> Hi Jon
>>>>>>>
>>>>>>> there is another thread on it (probably on user@)
>>>>>>>
>>>>>>> I think we should just make xalan optional in the lib and upgrade.
>>>>>>>
>>>>>>>
>>>>>>> Romain Manni-Bucau
>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>>>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>>>>>>> rmannibucau> |
>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>>>>>>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>>>>>>
>>>>>>> 2017-08-31 13:19 GMT+02:00 Jonathan Gallimore <
>>>>>>> jonathan.gallimore@gmail.com>
>>>>>>> :
>>>>>>>
>>>>>>> Correction - that should be: "CDDL or GPL with classpath exception"=
.
>>>>>>>>
>>>>>>>> On Thu, Aug 31, 2017 at 12:16 PM, Jonathan Gallimore <
>>>>>>>> jonathan.gallimore@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Great question. CDDL _or_ GPL, by the look of it.
>>>>>>>>> https://github.com/javaee/jstl-api/blob/master/LICENSE - same as
>>>>>>>>>
>>>>>>>> JAXB
>>>>>>
>>>>>>> I
>>>>>>>
>>>>>>>> believe.
>>>>>>>>>
>>>>>>>>> Jon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Aug 31, 2017 at 11:55 AM, Jean-Louis Monteiro <
>>>>>>>>> jlmonteiro@tomitribe.com> wrote:
>>>>>>>>>
>>>>>>>>> What is the licence for GlassFish one?
>>>>>>>>>>
>>>>>>>>>> Le 31 ao=C3=BBt 2017 12:38, "Jonathan Gallimore" <
>>>>>>>>>>
>>>>>>>>> jonathan.gallimore@gmail.com
>>>>>>>>
>>>>>>>>> a =C3=A9crit :
>>>>>>>>>>
>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> On master we shifted from openejb-jstl to
>>>>>>>>>>>
>>>>>>>>>> taglibs-standard-jstlel. I
>>>>>>
>>>>>>> have
>>>>>>>>>>
>>>>>>>>>>> done the same on the 1.7.x branch, specifically to move on from
>>>>>>>>>>>
>>>>>>>>>> the
>>>>>>
>>>>>>> old
>>>>>>>>
>>>>>>>>> openejb-jstl (looking at
>>>>>>>>>>> https://nvd.nist.gov/vuln/detail/CVE-2015-0254). The
>>>>>>>>>>> taglibs-standard-jstlel
>>>>>>>>>>> library does seem to depend on xalan, which we currently do not
>>>>>>>>>>>
>>>>>>>>>> include
>>>>>>>>
>>>>>>>>> in
>>>>>>>>>>
>>>>>>>>>>> TomEE.
>>>>>>>>>>>
>>>>>>>>>>> The impact is that some XML functions in JSP code does not work=
,
>>>>>>>>>>>
>>>>>>>>>> for
>>>>>>
>>>>>>> example:
>>>>>>>>>>>
>>>>>>>>>>> <%@ taglib prefix=3D"x" uri=3D"http://java.sun.com/jstl/xml" %>
>>>>>>>>>>>
>>>>>>>>>>> <x:parse var=3D"movies">
>>>>>>>>>>>     <movies>
>>>>>>>>>>>       <movie id=3D"1" name=3D"Wedding Crashers" director=3D"Dav=
id
>>>>>>>>>>>
>>>>>>>>>> Dobkin"
>>>>>>
>>>>>>> genre=3D"Comedy" rating=3D"7" year=3D"2005" />
>>>>>>>>>>>       <movie id=3D"2" name=3D"Starsky &amp; Hutch" director=3D"=
Todd
>>>>>>>>>>>
>>>>>>>>>> Phillips"
>>>>>>>>
>>>>>>>>> genre=3D"Action" rating=3D"6" year=3D"2004" />
>>>>>>>>>>>       <movie id=3D"3" name=3D"Shanghai Knights" director=3D"Dav=
id
>>>>>>>>>>>
>>>>>>>>>> Dobkin"
>>>>>>
>>>>>>> genre=3D"Action" rating=3D"6" year=3D"2003" />
>>>>>>>>>>>       <movie id=3D"4" name=3D"I-Spy" director=3D"Betty Thomas"
>>>>>>>>>>>
>>>>>>>>>> genre=3D"Adventure"
>>>>>>>>>>
>>>>>>>>>>> rating=3D"5" year=3D"2002" />
>>>>>>>>>>>       <movie id=3D"5" name=3D"The Royal Tenenbaums" director=3D=
"Wes
>>>>>>>>>>>
>>>>>>>>>> Anderson"
>>>>>>>>
>>>>>>>>> genre=3D"Comedy" rating=3D"8" year=3D"2001" />
>>>>>>>>>>>       <movie id=3D"6" name=3D"Zoolander" director=3D"Ben Stille=
r"
>>>>>>>>>>>
>>>>>>>>>> genre=3D"Comedy"
>>>>>>>>>>
>>>>>>>>>>> rating=3D"6" year=3D"2001" />
>>>>>>>>>>>       <movie id=3D"7" name=3D"Shanghai Noon" director=3D"Tom De=
y"
>>>>>>>>>>>
>>>>>>>>>> genre=3D"Comedy"
>>>>>>>>>>
>>>>>>>>>>> rating=3D"7" year=3D"2000" />
>>>>>>>>>>>     </movies>
>>>>>>>>>>> </x:parse>
>>>>>>>>>>>
>>>>>>>>>>> Movie 1 Genre: <x:out select=3D"$movies//movie[@id=3D'1']/@genr=
e"
>>>>>>>>>>>
>>>>>>>>>> /><br
>>>>>>
>>>>>>> />
>>>>>>>>
>>>>>>>>> fails with java.lang.NoClassDefFoundError: org/apache/xpath/XPath
>>>>>>>>>>>
>>>>>>>>>> (this on
>>>>>>>>>>
>>>>>>>>>>> both 1.7.x and master)
>>>>>>>>>>>
>>>>>>>>>>> Including Xalan does fix this, but its a 3MB dependency.
>>>>>>>>>>>
>>>>>>>>>>> The alternative is to use org.glassfish.web:javax.
>>>>>>>>>>>
>>>>>>>>>> servlet.jsp.jstl
>>>>>>
>>>>>>> instead,
>>>>>>>>>>> which I have tested and seems to work. Anyone have any thoughts=
?
>>>>>>>>>>>
>>>>>>>>>>> Jon
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>> .
>>>>
>>>>
>>
>

--001a113deaf4affce705597d983c--