Updates released for ColdFusion 2023/2021, Mar 12 2024, possible breaking change, solutions
It's very important that people read the technote before "just applying this update". There is a very important (and fundamental) change in how CFML processes variables, with regard to searching for scopes when no scope is indicated on a variable name. It's NOT that you "must scope all your variables", as some are asserting. But it's still almost certainly a BREAKING change in many CF apps, if they use unscoped variables under certain conditions (that I discuss below). The change is for the sake of security, but it's just one aspect of the security fixes in this update.
Anyway, there are 3 things you can consider doing to rectify/work-around this breaking change, as I discuss below (or see the update technote, for this and more). And you may reasonably wonder what the implications would be of using the workarounds. You may also wonder if this scope matter relates to the CVE listed in the APSB (linked to below). That's currently unclear. It does not. As well, note that the Adobe security bulletin (link below) shows the security fix to be only a P3 (priority 3, the lowest severity), not a P1 (priority 1, the highest), though it IS regarded as "critical".1
But then there are still other aspects of the update beyond this scope matter, and you should be aware of those also.
For more, read on.
- Finding (and finding more about) the update
- Particulars about this latest update
- Other changes besides the scope search issue
- Important change to CF behavior of searching through certain scopes implicitly
- What code with "unscoped variables" might break? Not ALL, but some (perhaps much)
- You don't NEED to wait for the update, to start testing for this impact
- Feature added by Adobe a month later, to help identify code that would fail
- Three ways to address the change in implicit scope searching
- Implications of using searchimplicitscopes=true1
- If I set searchimplicitscopes=true, am I opening myself to the 'Arbitrary file system read' CVE?1
- Possible ongoing impact of this scope search default change for years to come
- What about folks using Lucee?
Before getting to the issue above, let's talk about the updates in general (as I try to do for each update).
Finding (and finding more about) the update
While you should see the update appear in your CF Admin when you login (and if you don't, give it time as there may be a caching issue), Adobe has announced it via their CF Community Forums:
NOW LIVE! Adobe ColdFusion 2023 and 2021 March 2024 security updates
You will see I have already started engaging in discussions there, sharing some of what I share here.
And that points to the (very important) technote for each version's update, as well to the Adobe Product Security Bulletin (APSB) related to it, with (just a little) more about security issues identified and addressed:
- ColdFusion (2023 release) Update 7
- ColdFusion (2021 release) Update 13
- Security updates available for Adobe ColdFusion | APSB24-14
Given that the update includes security fixes, it would seem in your interest to get them applied ASAP. (I have no further info about the vulns to share than what is in these two pages, and since they were just posted I don't have news yet of any challenges anyone may have had. I can report I installed both updates without incident--though with a caveat below.)
As with all CF updated, possible need to upgrade web server connector
Don't miss also that if you're skipping to this update without updating the previous one from October, there is an indication in that update's technote of our needing to upgrade the web server connector for CF (if you use CF with IIS or Apache).While the technote offers a table at the bottom reporting which updates did require such connector updating, not it refers to "recreating" the connector (which implies removing and re-adding it). But since cf2016 we've been able to "upgrade" the connector using the wsconfig UI (or command line). I have a blog post with more on that here.
As with all CF updates, possible error you may experience applying update in CF Admin
If you apply the update in the CF Admin and find that CF starts but the admin and your code fail (such as with a 500 error, or perhaps in more detail starting with "java.lang.NullPointerException" or other errant behaviors), this may be due to a problem that can be solved. Read on.
I had written back in October about a problem folks could hit (which I first found in July) when applying CF updates via the CF Admin. The issue happened if you had updated the java underlying CF to a version released in July 2023 or later (that's update 11.0.20 or later for CF2021, or 17.0.8 or later for CF2023). I explained in that Oct post how you would need to run the CF update from the command line, adding a needed new JVM argument (offered by Oracle).
I shared then also how Adobe planned to resolve the problem for us, with the "next update"--and that would be this update. I can report that it seems that problem is solved--at least if you are on the most recent CF updates (CF2021 u11 and CF2023 u5) before applying THIS update. The update will work fine from within the CF Admin. If you are still on update CF2021 update 10 or earlier (not 11) or CF2023 update 4 or earlier (not 5), then you may still got the failure (where CF started but the admin would not load and requests failed, as discussed more in that Oct post). It seems that (even though the CF updates are cumulative), there's something about skipping the last update that seems to still allow the problem to happen. I've not seen any clarification from Adobe.
Again, if this hits you, the simple solution is to just run the CF update from the command line, with a special JVM arg (no need to "uninstall" the current update, as it failed). See the post from October for details.
Particulars about this latest update
Now, on to the specifics of this update. Before I get to that one really important issue, this update addresses still otehr matters, which may be important to understand.
Other changes besides the scope search issue
If you view the technotes for the update to either CF2023 or CF2021, you will see that it's got its own table of contents, covering a few other issues. I'll leave you to read about them, but they include:
- Changes to prevent unauthorized file access using cfdocument
- A change about what file uploads are blocked by default
- Upgrades to certain libraries (especially an update to Tomcat 9.0.85, but there are still others)
- And the deletion of certain old, no longer used folders
Again, see the update technote for whichever CF version you're on, for more details (the details are essentially the same, but it's why I can't link to any one document here.)
Important change to CF behavior of searching through certain scopes implicitly
Now finally let's move on to the very important (and fundamental) change in how CFML processes variables, with regard to searching for scopes when no scope is indicated on a variable name (at least in many cases)
This update changes CF's default behavior for an application setting called searchimplicitscopes. While that setting was introduced in CF2016, it has defaulted ever since to true (it was introduced then as way to get a performance benefit by setting it to false, to save time looking up certain implicit scopes--which required that you identify such scopes (more on "what scopes" below).
This update changes the default of that to false--now requiring that we identify such scopes, where needed (see below). This is almost certainly a BREAKING change in many CF apps--and it's a change Adobe has implemented for the sake of security, it seems. For more on that, see the technote. For more on what apps might break, see more below.
Again, there's much more to the update beyond this one issue, so again READ the update technote. But I call this issue out here as it's likely to be of most concern to folks.
What code with "unscoped variables" might break? Not ALL, but some (perhaps much)
To be clear, it's NOT as simple as some may read it: that "any code using non-scoped variables" will break. (In fact, the technotes for the update, linked to above, even make this mistake, which I've pointed out to Adobe.)
For example, this simple example WOULD continue to work:
<!--- the unscoped variable above will NOT fail when referred to in the line below, even with this update --->
<cfoutput>#x#</cfoutput>
Indeed, from my testing so far, code that WILL continue to work (WITH unscoped variables) is code where that unscoped variable would be found in any of these scopes:
- variables
- local
- query
- arguments
Code with unscoped variables that will NOT work is when the variable would be found implicitly by within any of these scopes:
- cgi
- url
- form
- cookie
- file
- client
I have found this list both from the CF docs on implicit searching and through my own testing.
I plan to do another post where I show some actual examples, if that may help folks. But I wanted to at least get this info out ASAP.
In the meantime, Pete Freitag has a helpful discussion and examples in his security guide on this topic which he called, "scope injection". Pete has also come out with a blog post on this recent update, and in it he offers still another example of the scope injection problem addressed by this change. Finally, he's also now updated his Fixinator tool to optionally search for unscoped variables.1
Three ways to address the change in implicit scope searching
If you DO have apps that WOULD break, there are three available solutions to the problem. The first is the more "secure", while the other two help with "compatibility"--at the cost of security". You can either:
- change your code (to scope variables as needed--again, see above how not ALL unscoped variables need to change)
- consider changing your application.cfc or cfm to enable searchimplicitscopes=TRUE (which opens you to the security concern this change is trying to protect against)
- change ALL CF processing by adding instead a JVM argument to CF's startup -Dcoldfusion.searchimplicitscopes=true(which also opens you to the security concern this change is trying to protect against)
These are discussed further in the technote. And note that the new JVM arg will NOT be supported in the next and future releases, so you will NOT be able to rely on that 3rd option beyond CF2023. You will instead need to consider either of the first two options.
As for that second option, so far it does NOT seem that Adobe plans to change whether that works beyond CF2023--but again there are reasons you should be careful about enabling it, as I discuss further below.1
(I'm just a messenger here. I have nothing to do with the change or how it was implemented. I just help people solve problems, and this is going to be one for many as they deal with it, and for a long time to come as they move to CF2023 and later releases in the future.)
As for implementing that 3rd option, I want to stress as always that you be VERY careful when adding such a JVM arg to CF's startup (whether in the CF admin or in the jvm.config file which it modifies). It should be added to what is the single line of jvm args, not as a new line. And don't forget the opening dash, nor fail to leave a space between this new arg and any before or after it. Indeed, I would recommend you save a copy of your jvm.config file (found in your CF instance's cfusion/bin folder, or instancename/bin for those running multiple instances.) If you make a mistake and CF won't start, you won't be able to correct the mistake in the CF Admin.
You don't NEED to wait for the update, to start testing for this impact
Here's more good news: you need not wait for applying this update to determine such things as what may break, and whether the second fix above may suffice.
Again, the searchimplicitscopes was added as an app-level configurable setting in CF2016. So you could create a test app in which you set as a property in the this scope of your application.cfc:
<cfset this.searchimplicitscopes=false> <!--- if writing in tags--->
Or if using application.cfm, you can set this on your cfapplication tag, as in:
After making the change, then test such sample code (or of course, you could just change this setting in your existing apps to test its impact on those apps). this way, you'll know what WOULD happen if you moved to this update (which changes the default for that), or you could leave the change in place (as the application-level setting is honored, even after the update).
When I create my post with samples, I'll more clearly demonstrate doing that. But I hope that what I've shared so far may be enough to help most folks.
Feature added by Adobe a month later, to help identify code that would fail1
In the weeks after this update was released, Adobe came out with a helpful "patch" providing an optional means to cause logging of code that would fail if the implicitscopesearch change (that's made the default in this update) was implemented. Some good news is that you can use that after applying this or subsequent updates (where you might use the above options to revert the behavior), but even better you can apply it BEFORE even attempting this or subsequent updates.
Adobe's technote about the "patch" is a bit spartan, so I have created a blog post discussing it in more detail.
Implications of using searchimplicitscopes=true1
As I noted above, changing searchimplicitscopes to TRUE will revert CF to the default it was using before this update--but in doing that workaround, you are opening yourself to the very issue that this change is trying to protect you against.
It's a lot to keep track of, I appreciate. And perhaps there will be more info offered by Adobe or others (or myself), but for now let me say at least that with CF allowing search of implicit scopes, your cf code referring to variables without a scope causes CF to need to "find" whatever scope that variable is in. Again, prior to this update, CF searched through ALL the scopes shown above in both lists. And after this change CF BY DEFAULT no longer searches through the scopes in the second list.
What's the problem with CF searching through those other scopes? If you have unscoped variables, and they're not resolved by (found in) a search of those first scopes (variables, local, query, arguments--all local to your request), then if CF is allowed to proceed to seeking to resolve the variable in those other scopes, those could be manipulated from the outside (cgi, url, form, cookie, file, client).
So if you change this searchimplicitscopes to true, then with regard to wherever you have unscoped variables, you're telling CF to again let it search through that second set of scopes. The safer choice is to change your code to NAME the scope you want to use, then there's no longer ANY implicit searching.
If you leave it as false (this new default), then CF won't search through that second list. That's the security aspect of this change.
If I set searchimplicitscopes=true, am I opening myself to the 'Arbitrary file system read' CVE?1
Finally, some may reasonably wonder, "would setting this to true open me to the 'Arbitrary file system read' CVE that is indicated in the APSB/security bulletin?" Naturally, if it would, that would be ANOTHER concern.
For now I can at least report (newly since I created this post) that Adobe has clarified (in a comment in their forum thread) that this change regarding implicit scope searching is NOT related to that security issue. Here's the key point:
The vulnerability "Arbitrary file system read" that you see in the bulletin is different from the one in Implicit searching of unscoped variables.
But you should read the full comment for context.
All that said, don't just think you're therefore "safe to set searchimplicitscopes=true". See the previous section here for more on the implications of making that choice.
Possible ongoing impact of this scope search default change for years to come
Before wrapping up, I do want to reiterate that point above about the 3rd of those three possible solutions: the jvm arg. Note again that Adobe WILL NOT be supporting that in future releases after CF2023.
That means that people who move to that release and beyond (or even now to CF2023 or CF2021, with these updates applied) will experience this breaking change--and their migration efforts may be seriously hampered, even though this is indeed a change for the better, from a security perspective.
We in the CF support community will have to point out this information literally for years to come. That's another reason I'm spelling things out in detail here and the other post with examples that I plan to do.
What about folks using Lucee?1
Those using Lucee may wonder how this matter is addressed there. Actually, by default they're in the same situation as CF had always been--and there's provision to change things similar to in CF.
First, note that Lucee refers to the concept (indeed, Railo referred to it originally) as "scope cascading", and there's a setting to control it on the Lucee Admin, under the "Scopes" link within "Settings", where it shows as a setting called simply "Cascading", with values of "strict", "small", and "standard" (explained there). The default is "standard", so that again it runs the same way CF always did--and you can change it there if you like.
And while CF has had the app-level searchimplicitscopes setting (since CF2016), there's no setting in the CF Admin to control it. As such, the Lucee Server admin-level change would be similar to (and easier to use than) the JVM-arg approach CF added with this update.
Finally, Lucee also offers their own app-level setting for this, called scopeCascading, as might be set in an application.cfc as: this.scopeCascading = "standard". Again, this is a reflection of that capability being introduced in Lucee's predecessor, Railo--as can be seen in any docs online for Railo, such as here.
Anyway, the current Lucee docs clarify how they do support the "newer" searchimplicitscopes app-level setting (again, "new" since CF2016) and Lucee regard that to be an 'alias to the attribute "scopecascading", in that they describe searchimplicitscopes being an "alias [which] takes a boolean value where true is equal to "standard" and false is equal to "strict" scope cascading mode.'
So someone setting searchimplicitscopes at the app level in CFML will get the same resulting behavior in CF or Lucee. But only CF has (for now) changed the default to be more strict. So this whole discussion raising the concern about unexpected scope search vulnerabilities is indeed a topic worth considering for Lucee folks, though it's not a"new" one.
On getting help with the update(s)
Finally, if you may want help with considering, installing, or troubleshooting anything related to these updates (or indeed anything related to CF), I'm available for online remote consulting. More at carehart.org/consulting. Or you can certainly reach out to the CF community (I list several of the online CF communities here.)
1 (Where I use this footnote "1" above on some paragraphs or sections, it's to indicate that's new content I've added or updated since the original posting. I'm doing this to help those who may have read the post originally and have come back to view it again. BTW, if you clicked the link for the footnote indicator to bring you here, note that you should be able to just hit the back button in your browser to return to where you clicked that link. :-)
For more content like this from Charlie Arehart:Need more help with problems?
- Signup to get his blog posts by email:
- Follow his blog RSS feed
- View the rest of his blog posts
- View his blog posts on the Adobe CF portal
- If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
- See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
But to be clear, in my pointing to these workarounds, I'm not saying anything the technote doesn't also.
Those with the concern you raise should ask Adobe. They don't necessarily (and don't see to) read my blog, so we should not necessarily expect them to see this and offer an answer here.
If anyone finds an answer or more detail elsewhere, please do share.
I use CommandBox to do my local development, and it looks like they haven't pushed a new image yet for their `adobe2021` tag. I want to be able to test my sites locally first before I have Hostek apply the update. I suppose I could YOLO it, and just have them update (since I have `searchImplicitScopes` set to `false` everywhere already. But, I see there are Tomcat updates and what not that I would feel better about verifying first.
As always, I'm just a messenger, one person trying help others, as indeed you so ably (and frequently) do. And we appreciate it!
As for Commandbox I can only say that they're always on the ball and a new one may already be in the oven. I don't see an update yet on Docker hub for them or Adobe (Adobe's forum thread said new images were in process).
Until then, yes, folks can just update their images like other folks using cf would (even if it feels icky on a container). Or yep, as I'd noted above, anyone can get a head start BEFORE doing the update by setting searchimplicitscopes=false in their application.cfc/cfm, to force the change in behavior that will become the default with the update. That will help them see if/when unscoped vars would be a problem (again, not ALWAYS).
While they could start updating their apps to use searchimplicitscopes=true as a "workaround", that should be carefully considered. First, the new jvm arg could be used instead (after the update). But EITHER workaround should be weighed against unlocking the very door Adobe was locking for the sake of security.
Here again, convenience (compatibility) vs security needs to be weighed carefully. This is the new reality (secure by default) being imposed on us from many directions: in CF, in IT generally, on our devices, and even in our daily lives.
For now, I'm going to just wait for CommandBox to release an update. I tried to update via the CF Admin (within my Docker container) and it said that this particular update can't be done via the Admin since it changes the underlying engine (I forget the exact wording).
Yep, Commandbox is itself its own environment, and just as doing cf updates might be frowned on in containers, it seems there are times when they're precluded by Commandbox.
Perhaps soon we may hear from Brad or Jon, on either or both matters (issues updating cf ourselves within Commandbox, or news on a new image).
I wasn't sure from the technote which "workaround" would go away so if I read your assessment correctly I will probably try setting "searchimplicitscopes=true" in our main Application.cfc since it seems that that will be support even when the JVM switch is no longer supported.
Thanks again! Always grateful that you have such a great place for CF information since it sometimes feels like a lonely CF world.
Does anyone know of such a tool like that, that could be used now?
Finally, as for your feeling like you're in a "lonely cf world", PLEASE see that last link I offered at the end to several available community help resources: you will find issues like this and many more discussed every day, whether you prefer email lists, web forums, slack channels, facebook discussions, linkedin discussions, and more.
You are definitely NOT alone. You are rarely the only experiencing some problem. And you need NOT rely solely on google searches or AI engines to find answers. And of course, some simply prefer talking to real people (flawed though they may be, in their knowledge and sometimes even in their online personalities!)
So first, yep, for those who pay for Pete's Fixinator tool, that will be a great addition (and certainly yet another reason for folks to consider it).
And FWIW, I can confirm that Adobe's Security Code Analyzer does not currently flag code with unscoped variables. (I just proved it with a test.) We can hope they will consider adding that, if they are not perhaps already working on it. And I've just filed a feature request on it: https://tracker.adob... Interested users of that tool should add a vote there. I'll also update my post to reflect this.
Finally, sure, someone could take the old varscoper (which was looking for a very specific problem) and try to modify it.
But let me note (as I do in that tracker ticket, and above in my post): it's not that ALL unscoped variables will fail with this change in behavior (or by setting searchimplicitscopes=false yourself). Any tool that flags ALL unscoped variables will produce MANY false positives (just like many are overreacting to this change, thinking they must change ALL unscoped variables).
Instead, it's that unscoped variables are still ALLOWED: they will only search those scopes in that first list I gave above (like variables, local, arguments, etc.). The change in behavior (searchimplicitscopes=false) will NO LONGER ALSO SEARCH scopes that can be manipulated from outside the request (like url, form, cookie, etc.)
And a tool deciding to flag that distinction is going to have to be pretty smart. But sure, some will accept just being told of ANY unscoped variables. That's just overkill. Again, lots to juggle here.
That's my current take on things, at least.
And I assume you mean you're setting it to true on the jvm arg, then you're trying to set it to false in an application.cfc, perhaps to tighten things down in apps that don't need to be loosemed?
If so, are you finding that despite being set to false, it acts as if it's true?
As for the setting of this searchimplicitscopes, are you doing that inside or outside of any method in application.cfc? It should be outside.
I plan to do a post tomorrow with more on that. It's not new or unique to this setting, that it does not take affect except when set OUTSIDE of any methods in the application.cfc (the"pseudo-constructor" of the cfc).
But let's have you clarify more before I go further with guesses and solutions. :-)
I also noticed when viewing the Update 13 URL from any other region than US (uk for example), the links to the hotfix installer and zip repository go to hotfix version 12.
UK page - https://helpx.adobe....
When viewed from the US, the links go to version 13 as they should.
US page - https://helpx.adobe....
And sure, it could happen with the package updates specifically since they are a separate file (and url). Something interesting is that they only change in some but not all cf updates; which means the issue of an "old"/stale/cached package update jar happens LESS FREQUENTLY and isn't noticed by as many as the same problem with the primary update jar.
Not sure what any of us can do, as users. Perhaps Adobe could implement some sort of additional checking for/protection against the package jar being found to be out of sync with the version of the update jar when the latter is run.
Until then at least they DO report in the technote what version number to check was implemented, both for the update and the packages (when an update introduces package changes). But most people don't pay attention. So again, good for you to spot it, and good of you to bring it to attention here.
Would you consider opening a ticket at tracker.adobe.com, to report the problem and suggest the possible solution? If you do, please share the link here so folks can add a vote.
Anyway, Adobe has responded there (looking into things). Here's the direct link to his comment there, and the threaded replies from Adobe follow it:
https://tinyurl.com/...
BTW, some may notice he's listed there as Adam36099131ak4s, but the message is the same, so I'll assume he just had that existing Adobe account name but uses a different pseudonym in other places, like this.
By the way, thank you for producing this fantastic CF resource, its helped me greatly over the years!
If I compare the 'bundlesdependency.json' file downloaded on my local server and my live server, the live one has no reference at all to any update 13 packages (searching for "2012.0.13") whereas the local one does.
When viewing the following URL about update 13 (uk version of the page):
https://helpx.adobe....
The manual installation instructions seem to be instructions for installing update 12.
If I view the US version of this page:
https://helpx.adobe....
The links in the manual installation instructions correctly link to files for update 13.
But about the first problem, help us out: did you apply the update via the cf admin, on both servers? Or this manual update?
And in the update install log (within hf-updates), does it show having applied update 12 or 13? With 0 "fatalerrors" reported in that log?
And then in the coldfusion-out.log and coldfusion-error.log, what errors are shown during the first startup of cf after having applied the update? That's when updates to the packages actually happen.
I applied the update on both my local and live copy via the CF admin. Locally it worked fine, on live the CF admin refreshed and then displayed a message about the adminapi module being missing.
After enabling this manually my site still wasn't working, the coldfusion error log showing errors about the 'document' and 'pdf' modules not being enabled.
I apologise for the lack of supporting information in my previous post. If I look at the install log for the update, it shows the following (I think these are the relevant bits of information):
java.class.path:
/opt/ColdFusion/bundles/updateinstallers/hotfix-013-330286.jar
Installed Feature(s) Standard, J2EE of Adobe ColdFusion 2021 Update 13
Install Begin: MARCH 18, 2024 6:15:46 AM GMT
Install End: MARCH 18, 2024 6:16:28 AM GMT
Summary
-------
Installation: Successful.
1625 Successes
0 Warnings
0 NonFatalErrors
0 FatalErrors
If I look at the 'bundlesdependency.json' that was downloaded and used for this update, it contains no mention of "2021.0.13".
The errors shown in my coldfusion-error.log for the first startup of cf afterwards are:
SEVERE: Servlet.service() for servlet [CfmServlet] in context with path [] threw exception [Servlet execution threw an exception] with root cause
coldfusion.server.ServiceFactory$ModuleNotAvailableException: The document package is not installed.
In coldfusion.out I only see this:
Mar 18, 2024 06:16:42 AM Information [main] - ColdFusion started
Mar 18, 2024 06:16:42 AM Information [main] - ColdFusion: application services are now available
Mar 18, 2024 06:16:44 AM Error [ajp-nio-0:0:0:0:0:0:0:1-8120-exec-10] - '' The specific sequence of files included or processed is: /var/www/*redacted*/htdocs/index.cfm, line: 615
Frist, let me note that I have NOT seen it on all the servers I've applied updates to--except one, yesterday. And for them, we did not take time to dig into WHY it happened (they just needed the update applied and their site working ASAP).
Like you, we dropped to the command line (as admin) and went to the cfusion/bin folder and ran cfpm install administrator. With that, despite an message suggesting we'd need to restart, we were able to get into the CF Admin.
Then we went in, and we saw that in the "Package Manager" page (second to last on the bottom left), in its "available packages", there was several which were not installed--including document and pdf, like you. To be clear, all packages should have been installed, since this was a typical full install which includes all of them.
We clicked "install all" and that solved it for them. Their app now worked. (Knowing this now, you could also just do a "cfpm install all" from the command line, instead of just "cfpm install administrator".)
Let us know how it goes. If you struggle and don't want to await back and forth here, I can certainly meet with you via a remote screenshare consulting session (as I mention in the post: more at carehart.org/consulting), and we should be able to get the update in place and working quickly.
Then if you want, we could do more digging into what it is about your setup (and those of some others) that makes things not "just work" as they should. There must be some explanation--especially of how it happens to some but not all of us.
Attempted the update again this morning on our live server - as before just doing it via CF Admin, this time everything worked as expected and we're now happily running Update 13.
This may be an over simplistic view, but it seems to me like the entire problem is that when my server tried to get a copy of 'bundlesdependency.json' during the update process, sometimes it was presented with the correct file and sometimes it was served something completely different.
The day that my server broke, doing a request from my server directly to 'https://www.adobe.co...' resulted in a json file with no mention of update 13 packages. Doing the same request today resulted in the file I was expecting.
To be honest, this is a sufficient enough explanation for me as to why things didn't work first time around. Some kind of caching issue/load balancing issue at the adobe end meant that my server was given a dependencies file that instructed it to uninstall certain packages. This caused my website to stop working. Once the relevant packages were put back in, everything seems fine.
As one of the affected parties, if there is anything you would like from me to help debug/understand the issue then do let me know. Otherwise I think we're happy to press on!
Andrew
I'll note that I've recommended the manual install as an option in both the post and other comments (like to Andrew, most recently), so again yep, I'm with you. :-)
Our live server which had the trouble is located in a Redstation datacentre in Gosport, UK. Our test server which had no issues is located in our offices in Exeter, UK.
Regards,
Charlie, not sure if you'd consider updating your blog post to mention this, but it might be useful for those that don't make it all the way down here to the depths of the comments :-)
Also, we've seen some confusion on if setting searchimplicitscopes key to TRUE in Application.cfc or Application.cfm will continue to be supported once the JVM flag -Dcoldfusion.searchimplicitscopes is removed?
We're trying to understand the timing implications to budget development time to work on this and knowing some deadlines would be good for making that happen.
Your questions are understandable, and I do already address/answer them above after mentioning those two options. See the section above, "Three ways to address the change in implicit scope searching", and the few paragraphs after the 3 bullet points there. The direct link to that section is:
https://www.carehart...
I realize my post here is large, and many will only scan rather than read it, and won't see every word. I've done what I could with sections, bolding, and a summary, to help such folks. But some points simply must be read. :-) I'm always open to feedback.
https://www.carehart...
1) So as Steve notes, I blogged on this problem (which started with CF2021 and remains) when I found it back in Nov 2020 when CF2021 first came out. That first post Steve offered does discuss it in detail. And as that post indicates, I did another when when Adobe offered a solution a couple of weeks later. In that post (https://www.carehart...), I explain how they created a JVM arg that we must add to make CF treat a capital D like in a dateformat mast the way it always did. Again, those using CF2023 and beyond also will need to use that, to get that backward compatibility.
Or see how I mention (in both posts) that some kind souls offered regex searches that one could use to find and correct such uses of D, in many possible variants of dateformat and related functions.
2) Of course, you're bringing this up here on this post about yet ANOTHER breaking change, both of which are surely frustrating. And as in that case, Adobe opted to go with the breaking change and a jvm arg to REVERSE it, rather than the other way around.
And though these happened 40 months apart, you're not alone in only experiencing the first one only now...which is like how I concluded THIS post with how THIS new problem will ALSO plague us as future folks move to CF2021 or 2023 and apply this update, or move to CF2024 and beyond, which will include this change to the default for searchimplicitscopes as a built-in change. A difference is that while Adobe is choosing (for security reasons) to NOT allow the jvm arg reverting that to work in CF2024 and beyond, again this JVM arg for the dateformat issue IS still supported in CF2023 and beyond.
3) Finally, back to the issue in THIS post and since I suspect my comment here may lead someone to ask: no, I can't see any possible regex that could reliably "find all unscoped variables". There are just WAY too many ways that code could name/use variables: with or without pound signs, with or without spaces around it, with or without parens around it, within quotes (as in isdefined), and on and on. More than that, not ALL unscoped vars MUST be changed, as I elaborate on in the post.
But as I noted in a previous comment and an update to the post, Pete Freitag has done the community a solid in having added to his Fixinator tool such scanning (as effectively as possible) for potentially risky unscoped variables.
And maybe someone will offer here or elsewhere a regex they work on which they think helps do the job. If it works well, I will certainly highlight it! :-)
https://community.ad...
2) I am DELIGHTED that one of the sites I inherited in 2007 was very much affected by this breaking change! Budgets are tight so I finally received approval to take it down. Who-hooo!
3)FYI: I found that I can always update via the Admin IF I manually control the server restart. Get the admin page up, get service panel up, stop any extra CF services, kick off the update, stop CF Application service, Start CF Application service, start other CF services, success.
Lastly, on your point of how you can't run the CF updates from the CF Admin, your approach is fine--but there's another solution, which again I've been meaning to blog about. And now I feel compelled to ASAP, lest discussion of the matter here takes us too far off-topic. :-)
And as I noted in the post, this problem may cause trouble for years to come, as people may jump to these or later versions from earlier ones. Oh, well.
Bottom line, it supports the same searchimplicitscopes app-level setting--as well as a related and older scopeCascading setting, which goes back to Railo days and is offered as a setting in the Lucee Server or Web Admin. But it defaults to the relaxed mode CF had before this update, so Lucee folks need to consider this matter as well. It's just that the changed default has not been forced on them as Adobe did with this update.
I may break that discussion into its own post, as I fear many will not see it here, 2 months after the update when I released this post. But I welcome comments from any interested Lucee folks, to refine anything I'd need to before doing that.
https://www.carehart...
And that can be done BEFORE one would apply the update from March or later.
I'd not remembered to post that link in. Here, as a comment let alone an update. I hope to do that also.