Lucee Stable Release 5.3.8.201

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

Issues Addressed

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

Debugging

LDEV-3622 Compile errors in 5.3.8.189 (added extra logging for debugging)
Added trace level debugging for classloader issues
add a hidden warning when the homepage webroot is incorrect by zspitzer · Pull Request #1 · lucee/lucee-installer · GitHub Added a warning to the Lucee Welcome page when css/js mappings are incorrect
LDEV-3554 Added a redirect to the Lucee Welcome page to trigger mod_cfml

5 Likes

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

@Zackster isn’t LDEV-3632 missing from this list?

You merged the pull 2 weeks ago, but the ticket is still in QA?

I was also really hoping

and

would also make it since they were related fixes I did at the same time at your and Pothy’s request for this release.

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 https://luceeserver.atlassian.net/browse/LDEV-3659 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

3 Likes

@Zackster hello, how can i report security issues ? i’ve reported LDEV-3673, but seems to be deleted =/ could u help me ? or someone

The Lucee team has a designated email address for reporting security issues, which can be found here:

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

2 Likes

@bdw429s thank you :smiley:

i’ve sent a email to security@lucee.org.

many thanks :smile:

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

Thanks,
Pete Freitag
Foundeo Inc.

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 ?

1 Like

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.

Thanks @bdw429s . There is a ticket for the cfpdf issue here: https://luceeserver.atlassian.net/browse/LDEV-3575

@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: https://luceeserver.atlassian.net/browse/LDEV-3687

@pfreitag This line of code worked in 5.3.7:

local.system.weightKG += local.systemWeightKG.weight

But we had to add Val() in 5.3.8:

local.system.weightKG += Val(local.systemWeightKG.weight)

The error we were getting on 5.3.8 was: can’t cast empty string to a number

local.systemWeightKG.weight was an empty string?

local.systemWeightKG.weight was an empty string?

Yes, evidently.

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.