Adobe should consider a different model for handling ColdFusion security fixes
Note: This blog post is from 2019. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.I would like to publicly propose a new model that Adobe should consider following for handling CF updates, specifically allowing for one to implement security fixes as soon as possible, without being ill-effected by possible problems introduced by other bug fixes/new features.
There is precedent for the proposal I am making, in the way Oracle has in the past handled this problem with Java updates. Let me explain.
If you just want to see the proposal (skipping the context), jump to here.
And if you want to add your vote (or comment) to a feature request I have made for this, please do so here: https://tracker.adobe.com/#/view/CF-4205334.
What's the issue, and why is it of concern again?
As background, the trouble with this week's (Sep 2019) CF updates (as I discussed here) has raised this concern again. Problems with the update are in some cases breaking existing break code or causing pages to fail to load.
If those turn out to be due to one or more of the many bug fixes or new features included in the update, rather than the security fixes (also included in the update), then people who are concerned about security (as everyone should be) are stuck, not being able to (or not willing to take the chance) of applying the update, thus leaving their servers vulnerable--especially when now the Adobe security bulletins document publicly that there are known vulnerabilities, that should be fixed by applying the latest update.
At the end of my last post, I commented about how many folks have wished Adobe would somehow split off security updates into their "own channel". For now, there's no way to get them and not the rest of the updates.
And it's been done before, which did not go so well, but I do think there's a good model Adobe could follow.
How things worked, before CF10
So first, some may recall that back in CF9 and earlier, security updates were in fact separate from other "hot fixes" and "cumulative hotfixes".
A problem with that, though, was that folks had to know a) that they existed, b) where to go get them and then c) manually apply them.
Then in about 2012, Adobe started folding the security updates into the cumulative updates (which rolled up individual bug fixes/new features). The noble goal was to make sure "everyone" would get the security fixes without needing to get them separately.
They did maintain also the separate security updates, so someone could get JUST those, but then they would NOT get any bug fixes or new features that updates might have offered. It was just not a good situation. It's not clear if they would have continued with that course.
How things work, since CF10
But right then (in 2012) CF10 was released, and it offered the new automatic update mechanism (which we have today), and the approach Adobe followed then was to have only one update (roughly per quarter, though sometimes the gap was longer).
And that update could have either security updates or bug fixes or new features. Sometimes there was only one kind, but usually there at least two if not all three kinds. And that's where we are today, that someone wanting "just the latest security updates" really can't get "just those".
How Oracle handled this with Java updates
The way Oracle handled this challenge for years with Java updates is interesting. And it's a model I think CF could follow.
Until very recently, when a new update would come out--which again were typically quarterly and typically had both security updates and bug fixes/new features, they would instead offer two variations of that one update. (Sometimes there was only one variation, but usually there two.) What they were doing is clever, I think.
- The lower (or "odd") number update (let's use 1.8.0_211 for example) had JUST the latest security fixes (AND it had any bug fixes/new features from the PREVIOUS update--202, from some months ago). This variant of the update would be used by those who "just wanted the latest security updates and NOT the latest bug fixes/new features".
- The higher (or "even") number (say, 1.8.0_212) had both the latest security fixes AND the latest bug fixes/new features. This was the update that would be used by people who prefer simply to "get the latest update", trusting that all should go well.
Why this seems to work better
What's clever is that those who just wanted the security fixes (and were in no hurry to be guinea pigs on bug fixes and new features) could effectively JUST get those latest security fixes...well, at least until the next update (again, usually a few months later), when even the lower numbered one WOULD bring in any of those bug fixes/new features which they "skipped" before.
Of course, the thinking is that by time that later update rolls around, any issues with the earlier "bug fixes/new features" will have been worked out by the vendor (and the "guinea pigs").
It's an interesting solution to this problem, and one that it seems to me Adobe should really consider, especially after the issues with these Sep 2019 updates and the ones that were pulled in Feb 2019 (see the "Note" at the top of that page).
A bit more on this Oracle update model
This Oracle Java update model is explained in various resources, but the most "official" one seems this, but beware that some genius chose to use the terms CPU and PSU as the way to distinguish the two types of updates. That's "Critical Patch Update" (CPU) and "Patch Set Update" (PSU). Right, clear as mud. Curiously, that phrase didn't appear on typical updates that came in pairs
(There is yet another distinction that Oracle uses, of "BPR" (bundled patch release) and GA ("general availability") releases. But that has more to do with licensing matters, and a given numbered update could be made available in a BPR and GA variant.)
Finally, I am aware that after Java 8 updates 211/212, Java seems to have gone back to a single number per update. I've not yet found why this is so. If anyone knows, please do share it. Even so, I still think it's a model Adobe could benefit following, unless there was some grave problem this raised that I'm not aware of.
A tweak worth considering: don't differ by "number" alone
Besides that curious CPU/PSU nomenclature, there's still one other negative to the Oracle Java update model that perhaps Adobe could tweak, to their benefit: this distinction by the lower/higher (or odd/even) number. That was just too subtle.
Indeed, I suspect most people never really understood what those two differently-numbered updates were really about. I help people daily with doing things (like updates to CF, the JVM, FusionReactor, etc., in addition to general troubleshooting, tuning, and so on), so I can confirm that nearly always when I'd help people do a JVM update and we'd see the two options, they would ask what it was about. Again, the JVM update download pages from Oracle were never really clear about it.
So I don't know if Adobe should adopt a different NUMBERING scheme, per se. I'm just proposing here that they should consider adopting the concept somehow, and they can then use their update user interface (or some other nomenclature for the underlying update jar files) to convey to people that there would be these two options: a) get the latest security updates and the previous update's bug fixes/new features, or b) get the latest security updates AND latest bug fixes/new features.
I'm sure some will argue that giving people choices "makes things hard", or that it makes things hard on Adobe. But I just think it's time that something be done, to ensure people can at least make a server more secure as soon as possible--with the least risk of unrelated problems hurting their server.
What do folks think? Again, I have filed a feature request here, where you can add your votes/comments: https://tracker.adobe.com/#/view/CF-4205334
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
Hopefully Adobe can see why this is a good idea, even though it might create some more work to create two builds. The benefit to them is that they have a lot more time to address issues caused by new features / non-security fixes. Hoping it sticks this time.
My point is it seems even in their selection of Java to use mirrors their releases... Use the feature updates whether you need them or not.... And now we're all beholden to that decision because they're our Java supplier.
I've always used the Security Fixes only track, because if all the features are working for me, why introduce more risk?
The problems I ran into with this installer, and others ran into, some were caused by changes to their parser - things like => functions and the queryloop stuff, if you need that to fix a specific bug in your environment you should be able to make that decision. As someone not USING =>, I'd rather not introduce the risk of an update that changes the CORE LANGUAGE PARSER, because why? If everything I'm using is compiling properly, why take the risk?
I would LOVE to be able to selectively ignore the "fixes" to the elvis operator. To apply the security updates without the rest. To NOT update the macromedia_drivers.jar... I'm not even USING their drivers. Any one of these things introduces risk.
The only reason to shell out $10k for an Enterprise license of ACF when we have other, free options, is because we're prioritizing and paying for a stable product that Adobe is verifying is stable when it goes out the door. If we can't rely on that.... What value are we getting? I'd fully expect a company of Adobe's size to have automated testing for the parser. It's the core of the CF business. If it's wrong, you're in BIG trouble. And it's EASY to automate, any parse error can be found by cfcompile - you don't even need to fire up the J2ee server. (Arguably cfcompile's error handling and verbosity leaves a lot to be desired, so fix that too while you're at it) Unfortunately I suspect a large portion of their testing to be manual, and certainly with incomplete coverage.
If Adobe were REALLY smart... (or it were me)... I'd Open Source chunks of ACF. I'd Open Source the parser, the tag support, large amounts of the tag library. Obviously they can't open source EVERYTHING... The DataDirect drivers are OEM, as are other parts of their codebase I'm sure. They're not going to open source their licensing checks. Maybe keep cfdocument, and cfhtml2pdf and such closed. But CF DOES have a community of people who can help with writing this stuff, making sure it's right, forming consensus, and helping to test both before and after release. Plus it could cause other developments in the community - using ACF's parser in Linting tools, to find and enforce best practices, for trans-piling... etc.
If they choose not to leverage the community and the resources at their disposal, they're just making it harder for themselves, and everyone else.
Further, on this matter of that downloads page offer of "some but not all" versions of a given jvm installer, I know some people are under the impression that they MUST get those from there. I don't agree.
I have been comparing the installers offered there to those offered at Oracle's site, and I have found them to binary identical. I have asked this question in the various Adobe portal discussions where the matter of that downloads page has been raised, asking why one should "have to" get the JVM installers from there (if there is something not listed there), when those in both places are binary identical. No one has answered, and I will presume for now that really, there is no difference, and so it shouldn't matter.
(To be clear, at least with regard to the exe installer, the Oracle licensed agreed to is within that installer, so if the exe's are identical, so too must be the license agreement.)
But we are getting off-track here, as indeed is much of what you share. I understand that some people want to tell Adobe about all kinds of things they feel Adobe should be doing and changing. I get it.
But mine here is one simple proposal. Thanks for you and Pete concurring so far (to the principle).
Let's see if Adobe may. And I just realized I should have made this a feature request, and pointed back to this for more detail. I will do that, then I will come back here and offer a link to that, so folks can vote it up if interested.
Those who like the idea, please add your votes (and/or comments).