The Lucee team is proud to announce the second Stable Release of 5.3.8, available for download (including both Linux and Windows installers) https://download.lucee.org or via the Lucee Admin.
This is a maintenance release addressing regressions since the 5.3.7 release
Java and Tomcat versions are the same as the 5.3.8.189 release
LDEV-1530 - Update Apache Tika to 1.27 LDEV-1564 - Strange problem when using Transaction with ormEnable=true LDEV-2954 - Calling CFTHREAD Creates New JSESSIONID Cookie Even When Session Management Is Disabled LDEV-3532 - REFind/NoCase(scope=āALLā) returns an empty array instead an empty match set when no match is not found LDEV-3588 - docker build trigger isnāt working LDEV-3590 - OnApplicationStart Application scope race condition LDEV-3606 - extensions are sorted into type based only the latest release from the provider LDEV-3611 - Scheduled Task List crashing in Lucee Admin LDEV-3632 - Aggregates donāt return empty row for empty set with where clause LDEV-3627 - Calling component using relative path in thread fails
Really great to see the installer being enhaced with the static file warning. This will help newcomers a lot to understand how tomcat and webservers interact together!
LDEV-3632 Aggregates donāt return empty row for empty set with where clause
Is now marked deployed and added to the release notes.
This change [LDEV-3659] - Lucee is looking like itās causing a regression and will need to be addressed ASAP, weāll follow up with another minor release with those two other PRs as well
@incogbyt3 your ticket is not deleted. I changed the security permissions so only developers could see it. I left a comment on the ticket telling you that, but perhaps jira didnāt notify you. This has been reported to our internal security channels so it can be dealt with.
@bdw429s@incogbyt3 I closed the ticket LDEV-3673 as a duplicate of LDEV-3027. And also updates the security level and priority of the ticket LDEV-3027.
LDEV-3027 is publicly available in various caches already, so bit pointless hiding it.
So, based on reading that, I think changing to auto remove on* (etc ? in any rendered template ?) is a massive move, bound to cause headaches. Just correctly escape where you need to. This is a code issue, not a framework issue, if you see what I mean.
@thefalken You are 100% correct. Those XSS issues need to be remediated directly in the CFM templates via the EASPI encodeForXXX() functions. Relying on script protect is not a valid replacement for XSS best practices. Iāve started an internal thread at LAS to discuss.
Thats true, but i also think we should improve the scriptProtect.
Its really outdated and the current version is hard coded.
I think we should do a config file (like coldfusion does) for the regex and improve/extend the current one.
If we leave it like this, people may think it protects them, but the current system has too many security vulnerabilities.
Weāve attempted to upgrade twice now, and had to roll back both times (weāre in the middle of the 2nd time right now). Sending email does not work anymore if there are CC recipients.
the first time we had issues where we had to go wrap Val()s around things that didnāt need it. And we had crashes on PDF generation until we switched the order of the attributes on the tag.
This release is not ready for release. It has caused a lot of issues for our customers. And yes of course we ran it on dev for a while first.
Edit - one of the exceptions says: Attribute [cc] of the tag [mail] is invalid
Iām sure the issue is in our code somewhere, something the with the way we are using the tag. That doesnāt change the fact that weāve had a number of of production-breaking problems with this update.
Hey Ryan, Iāve been running it on dev as well and I havenāt seen any issues yet (so far). For the sake of others that might be reading this, can you go into some more detail on some of the issues you encountered. For example Iām wondering why you had to wrap values in val().
Second you mentioned that PDF generation crashed until you switched the order of attributes on the tag. It doesnāt make a difference what order you specify attributes in, so I think perhaps the issue there was that you were forcing a recompile of the CFML by switching the order, and perhaps that is what actually fixed it?
I know one thing that was changed a few versions ago was CFMAIL now validates to/cc/bcc email address at send time, not in the background like it used too. So you might have hit that ?
Do you have logs of what the value was when it failed ?
Sorry to hear youāre having issues. Can you please ensure there are tickets in the ticket tracker for each of your issues? Iām fairly certain all regressions that were logged were fixed prior to this release.
@thefalken The email issue was not related to validating at send instead of in the background. The issue was with a trailing comma in our list of recipients, which I guess Lucee must have been fixing for us but no longer does in 5.3.8. We were able to fix it in our code. But there is a ticket here for it here: [LDEV-3687] - Lucee
The breaking change in 5.3.8 could have been in QoQ, rather than directly related to the string/casting. I see this code further up that sets local.systemWeightKG.weight
<cfquery name="local.systemWeightKG" dbtype="query">
SELECT SUM(weight*quantity) AS weight
FROM linesQuery_lucee
WHERE systemID = <cfqueryparam cfsqltype="cf_sql_integer" value="#local.system.systemID#" />
AND weightUnit = 'KG'
</cfquery>
My guess is the error happens when this query returns 0 records. But somehow it worked in 5.3.7.
