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